Basic performance tips.
Author
Oh.. and yes, I made sure Vsync was off. I even rebooted and double checked just for you. It is OFF.
Author
G2 MX 400. The amount of ram on the video card is 32mb (just checked the settings). As for my computer itself, it has 256mb.
Then I think that 70-80 FPS on such a crappy card, in 1024x768 is good enough, you should settle for it and go on with your game.
hmmmm I'd lay money on you being CPU limited, the as you said, you spend 50% of your time in a rendering loop, in that time you make (13*2500) 32,500 API calls,all with function over head.
You've got no state changes, which is good at least [wink]
You are hand feeding the GPU data, which is never fun, a vertex array might well help IF you put all your data in the array and send it all at once, the CPU will be much faster at memory filling and calling a couple of functions than it will at making 32,500 API calls, that will shift the load from the CPU in your code to the GPU and driver time processing.
I'll go on a limb and say VBOs wont help your card.
If you are redrawing the whole screen you can loose the glClear, on newer cards it wont matter (and its probably better to keep it in) but on a card like yours thats just wasted time.
Make sure you've got no extra testing turned on you dont want, such as z-testing, alpha testing or scissor testing, these all waste time on the GPU and for something like this arent needed.
The fact you are running in windowed mode wont help, the GPU has to do a copy on buffer flip rather than a straight exchange of the buffers in ram (this even hurts a 9800xt, to give you an idea of difference, i've a simple program which spins two cubes, one inside each other, while scrolling the textures, with vsync off in full screen its just a blur, in windowed its still fast but you can see the cubes, no problem)
Dont worry about the colors being blocky, whats important is the code test, either run in full screen at a lower screen size (start @ 800*600 and work up) or resize the windows desktop to the same size as the window is gonna be and try again starting @ 800*600 and working up (while it wont be perfect, it should take the load of the gfx card, even when copying... erm.. in theory, i've never tested this idea i should point out [smile])
You've got no state changes, which is good at least [wink]
You are hand feeding the GPU data, which is never fun, a vertex array might well help IF you put all your data in the array and send it all at once, the CPU will be much faster at memory filling and calling a couple of functions than it will at making 32,500 API calls, that will shift the load from the CPU in your code to the GPU and driver time processing.
I'll go on a limb and say VBOs wont help your card.
If you are redrawing the whole screen you can loose the glClear, on newer cards it wont matter (and its probably better to keep it in) but on a card like yours thats just wasted time.
Make sure you've got no extra testing turned on you dont want, such as z-testing, alpha testing or scissor testing, these all waste time on the GPU and for something like this arent needed.
The fact you are running in windowed mode wont help, the GPU has to do a copy on buffer flip rather than a straight exchange of the buffers in ram (this even hurts a 9800xt, to give you an idea of difference, i've a simple program which spins two cubes, one inside each other, while scrolling the textures, with vsync off in full screen its just a blur, in windowed its still fast but you can see the cubes, no problem)
Dont worry about the colors being blocky, whats important is the code test, either run in full screen at a lower screen size (start @ 800*600 and work up) or resize the windows desktop to the same size as the window is gonna be and try again starting @ 800*600 and working up (while it wont be perfect, it should take the load of the gfx card, even when copying... erm.. in theory, i've never tested this idea i should point out [smile])
Quote:Original post by _the_phantom_
You are hand feeding the GPU data, which is never fun, a vertex array might well help IF you put all your data in the array and send it all at once, the CPU will be much faster at memory filling and calling a couple of functions than it will at making 32,500 API calls, that will shift the load from the CPU in your code to the GPU and driver time processing.
Let's not forget that he is just testing stuff.
In a real life situation, VA won't help, because the sprites in a 2D game are not exactly static (some are, but a lot aren't).
Besides, if the game world scrolls (in most of the 2d games it does) then VA might become even less efficient, since it eneds to be manually rebuild every few frames.
BTW, do you use the Z buffer?
Also, I think that you should also clear the Z buffer (if you have one) even if you don't use it. It's faster.
Author
_the_phantom_:
That was someone else who said 50% of their time is spent in the rendering loop. My app is nothing but rendering, there is nothing else going on except a few other glut* calls (like clearing the screen and swapping the buffer).
Building a vertex array every frame (instead of doing 1 array per quad) would probably take some time, and I'd have to totally redo the way I'm currently rendering my graphics (I have classes built that keep track of 2D animations and draws their appropriate frames). I think it may help, but at this point nothing seems certain. I'll probably end up messing with that when I get an actual game engine built, and I can get a better idea of my overall performance and not just the graphics (I imagine AI is going to suck some cpu time, and I may end up drawing less quads per frame than I'm currently predicting).
Raduprv:
I don't believe I'm using a Z-buffer, I'll have to go check my code real quick for that. Should I be using it?
And yes you are correct that I am just testing stuff based off of what I'd be doing in my actual game. It'll be rare that I'll be drawing the same frame twice for a specific sprite, and it'd be rare for them to not be moving. The background will most definitely scroll. Thinking of how I'd batch all of this information into a vertex array effectively (having to rebuild it every frame) will take some thinking. Perhaps it's easier than I think, but something about building two arrays (vertex + texture) with 20,000 elements EVERY FRAME just doesn't sit well (yes, that's right, 2500 quads each having 4 vertices, which in turn each have an x and y coordinate). Perhaps I could just preallocate the 20k elements and reuse the same array (replacing data). Regardless of the approach, I'd have to think about how I'd want to handle it.
That was someone else who said 50% of their time is spent in the rendering loop. My app is nothing but rendering, there is nothing else going on except a few other glut* calls (like clearing the screen and swapping the buffer).
Building a vertex array every frame (instead of doing 1 array per quad) would probably take some time, and I'd have to totally redo the way I'm currently rendering my graphics (I have classes built that keep track of 2D animations and draws their appropriate frames). I think it may help, but at this point nothing seems certain. I'll probably end up messing with that when I get an actual game engine built, and I can get a better idea of my overall performance and not just the graphics (I imagine AI is going to suck some cpu time, and I may end up drawing less quads per frame than I'm currently predicting).
Raduprv:
I don't believe I'm using a Z-buffer, I'll have to go check my code real quick for that. Should I be using it?
And yes you are correct that I am just testing stuff based off of what I'd be doing in my actual game. It'll be rare that I'll be drawing the same frame twice for a specific sprite, and it'd be rare for them to not be moving. The background will most definitely scroll. Thinking of how I'd batch all of this information into a vertex array effectively (having to rebuild it every frame) will take some thinking. Perhaps it's easier than I think, but something about building two arrays (vertex + texture) with 20,000 elements EVERY FRAME just doesn't sit well (yes, that's right, 2500 quads each having 4 vertices, which in turn each have an x and y coordinate). Perhaps I could just preallocate the 20k elements and reuse the same array (replacing data). Regardless of the approach, I'd have to think about how I'd want to handle it.
Don't optimize now.
Finish the game, optimize later. Besides, there is not much you can do.
However, using a z buffer migth speed up some stuff (for example it would speed up your test a LOT), but even in real life situatins it will help, since it decreases the penalty of overdrawing.
Finish the game, optimize later. Besides, there is not much you can do.
However, using a z buffer migth speed up some stuff (for example it would speed up your test a LOT), but even in real life situatins it will help, since it decreases the penalty of overdrawing.
Author
Right.. optimizing after is always best. But I at least wanted to try the basics to make sure there wasn't something significant I was missing (it's fairly easy to switch between immediate mode, draw lists, and vertex/buffer arrays). But you have to admit, 30 fps with only 2500 quads isn't very pleasing.
Trying simple changes doesn't hurt, and certainly doesn't take much time, and on top of that it's a learning experience for me to see what can work and what might not since I'm very new to OpenGL. But obviously if I'm going to have to go through a significant change to how I currently render my scene, then I'll save that possible optimization for later. Perhaps, in the end, I may not need it, so there's no reason wasting time now.
I'll read up on the z-buffer to see if it might be of some use.
Trying simple changes doesn't hurt, and certainly doesn't take much time, and on top of that it's a learning experience for me to see what can work and what might not since I'm very new to OpenGL. But obviously if I'm going to have to go through a significant change to how I currently render my scene, then I'll save that possible optimization for later. Perhaps, in the end, I may not need it, so there's no reason wasting time now.
I'll read up on the z-buffer to see if it might be of some use.
Author
Quote:
Well, you got 70-80 FPS in 16 BPP, so what do you want?
GF2 MX is a crappy old card.
70-80 @ 32 :D
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
