I personally don’t use deprecated code. I’m just explaining I’m not against it if it works for you.
Its kinda interesting…
I have done my spritebatch with glvertexattribpointer and with custom attributes and the performance is worse than immediate mode by 10 fps or so.(really small difference)
Does that mean that VBO is faster than glvertexattribpointer?
Give us frame times in milliseconds. Comparing FPS values like that says absolutely nothing. For all we know, the difference could be 11 —> 1 FPS or 10000 —> 9990 FPS. The first one is a huge difference while the second one might as well be a random spike 0.1 millisecond spike.
These two are not mutually exclusive. You can use glVertexAttribPointer() to refer to data in a VBO or pass in a ***Buffer directly with data.
If you are talking about having multiple buffers that you are switching from then changing, someone posted a little hack about how to do it before. I think kappa was refering to it. However it kind of seems like overkill for what you are doing, and uses a ton of memory.
Interleaving data does increase speed and whenever possible it should be used; however its not a make or break situation. It not necessary.
Since you seem to be just starting out. This is how i suggest you go about making your vbos and doing your buffering.
store all of the static geometry, interleaved, in one buffer. store your dynamic geometry in another buffer, without interleaving. use glBufferSubData to change your dynamic geom. This means just 2 draw calls and 2 bind buffer calls per game loop.
A common misconception about 2D games is that they don’t need enormous amounts of processing power… turns out they do. I’m having trouble getting just 10k sprites rendering at an acceptable framerate on a lower-end system.
Cas 
But those are your games princec 
Most other people do not create such graphically intensive games!
I’m not trying to argue for immediate mode here, I am just saying if the tool fits the job then use it!
All it takes is a few particles and a zoom function and the next thing you know…
Cas
What does 10k mean? 10k sprites each frame?
Oh don’t worry, I know the struggles
Good luck to you!
Troll, technically there are 10k sprites every frame, so yes. I think he meant though that there are 10k visible sprites every frame though.
Yes, 10,000 sprites animating and drawing every frame at 60Hz. I’d really prefer to have 25k but we’re already dropping to 45fps.
Cas
I can only imagine why you would need 10K sprites visible at one time! I would think a few hundred would be a lot already.
Anything with particle effects? Come on, it’s easy to get to 10K sprites.
I have never managed to reach that many. That would probably look very cool though, all those particles floating around!
Well, when the battlefield is zoomed out, there are 1,000 units on each side alone. Each unit is made up from 3 sprites (a shadow, a body, and some lights). There’s 6,000 sprites.
Each unit then starts shooting… that’s a sprite per bullet. And we haven’t even done any particles yet!
… and this is without rendering any terrain sprites like trees, rocks, buildings, etc. yet either.
Cas
Ah I see, that makes much more sense now
I could definitely see how that could get very… complicated very quickly!
Ow cmon… You know what I meant… I meant its really almost very small… Was like 1500 and dropped to 1490
I agree with Kappa and I disagree with you. VBOs are in the worst case as slow as vertex arrays, for example on their very early implementations (ARB VBOs in OpenGL 1.3 graphics cards like mine). VBOs are the way to go if you want to support at least OpenGL 1.5. If you want to support OpenGL 1.2, you can use a second code path relying on vertex arrays. When I render my MD3 models in immediate mode, the frame rate is lower than with vertex arrays and VBOs whereas I modify the data every frame. I can hardly find a particular case justifying the use of the immediate mode and some APIs provide a way of emulating it with VBOs, it’s nice to quickly port some very old code (just as a temporary solution).
gouessej, see above where I specifically said I wasn’t supporting the use of old deprecated functions, I just don’t get ticked off when people do use them.
opiop65, the retained mode and the immediate mode were both already in OpenGL 1.2. The choice of VBOs (or not) is mostly independent from the choice of the fixed pipeline or the programmable pipeline.
Tip on answering questions about opengl: Unless you REALLY know what you are talking about, do not say anything as you may confuse the person asking the question more then they already are.
Simple: Fixed Function/immediate mode should never be used. Especially because you can toss together a vertex array batcher for many types of data in a matter of minutes. The performance gain is at least an order of 10.
@pricec
I think you are hitting fillrate issues more than anything else. Even on lowend POS systems I can very easily get 10k+ sprites going at it. Problem is fillrate…its always fillrate.
I am sure you are doing culling when a sprite is outside the camera. Could use polygon meshes instead of quads/triangles_strips. Reduce overdraw via less composited stuff. Instead have the shadow part of the sprite or something similar. Just tossing ideas out.