0
\$\begingroup\$

I am writing a simple 3D pacman using c++ and OpenGL. I'm new in OpenGL development, I wanted to make a small project before learning next concepts.

For now I can't have more than 55fps when rendering every objects.

These are my objects is the game :

After commenting my code to see which objects was causing problems, I know that the grid ( that is oly a plane, so 6 vertices ) and the walls ( 17k vertices, 1 draw call ) are causing the problems. ( By commenting all other elements, like foods, player and ghosts I only win 5 fps )

Which leads me to this question : What really matters with frame rate? The number of draw calls? The number or indices it has to render? the number of pixel that will be visible in the screen? Everything?

It seems that vertices outside the screen are ignored, but if that's true, how can I improve my fps count?

Or maybe I am just worrying for nothing and that's a normal thing with the first projects and should just continue?

Thanks for the help.

\$\endgroup\$
5
  • \$\begingroup\$ Generally speaking, all activities you perform will have some impact on your final framerate. Draw calls can be quite expensive so it is usually best to batch them. Additionally, while vertices outside the viewport is not rendered, they will still be processed if you pass them to the render system. In this case you could use some form of spatial partitioning to figure out what is not visible and completely ignore them while rendering (so they don't even require basic rejection by the pipeline). \$\endgroup\$
    – free3dom
    Commented Jul 23, 2014 at 7:54
  • \$\begingroup\$ So instead of render a complete 6 vertices grid, it would be more efficient to render only a part of a grid with more vertices? On the screen we can see only 1/10 part of the grid, so with more vertices less pixels would be processed? \$\endgroup\$
    – Aulaulz
    Commented Jul 26, 2014 at 12:56
  • \$\begingroup\$ It depends, each vertex you add will need processing. But since vertices are processed once and textures are processed per pixel it can actually be faster with more vertices, depending on the situation. I wouldn't recommend it though, culling vertices usually don't yield a big performance gain. Rather cull entire objects (i.e. don't process any vertices of objects which are completely outside the view) - but for partially visible objects you can usually just render them as is (unless they are very complex). \$\endgroup\$
    – free3dom
    Commented Jul 26, 2014 at 13:02
  • \$\begingroup\$ Interesting, thanks for the help. PS: To be sure, by "it is best to batch them" you mean instancing? \$\endgroup\$
    – Aulaulz
    Commented Jul 26, 2014 at 16:11
  • \$\begingroup\$ By batching I'm refering to placing as many as possible primitives/vertices using the same texture into a buffer and then rendering the entire buffer after setting the texture once. Texture swapping is a very time consuming operation so minimzing it is preferred. It is not always possible, so don't break your head over it..but also don't go changing the texture for every triangle :) \$\endgroup\$
    – free3dom
    Commented Jul 26, 2014 at 16:23

2 Answers 2

Reset to default
2
\$\begingroup\$

It might sound dumb, but make sure V-Sync is not enabled. And yes, reduce the draw calls to gain fps. If you have multipled shaders and textures, make sure you don't make unnecessary switches between them, like first draw all objects which use texture0 and not one object with texture0, then another one with texture1 and then back to texture0 etc. really try order these things. Also use VBOs, don't use glBegin and that deprecated stuff. For shaders you should also use uniform buffers instead of just uniforms.

\$\endgroup\$
3
  • \$\begingroup\$ I always disable vsync for tests. Textures are bound only once, but shader wasn't. I bound him each frame instead of once, but it didn't changed the framerate. I don't use deprecated stuff, and will check for uniform buffers. Thanks \$\endgroup\$
    – Aulaulz
    Commented Jul 26, 2014 at 12:59
  • \$\begingroup\$ Alright, no problem! Without some code I can't really help much more I think. Just a few other things to check: * don't calculate the MVP Matrix completely in the vertex shader, provide a complete one in a uniform, or at least the MV part. * make sure to not make draw calls for objects that aren't in the view frustum. * if you have any branching or loops in the shader, try to get rid of them if possible * iirc models should be made out of triangle strips, apparently it's faster \$\endgroup\$
    – rfreytag
    Commented Jul 26, 2014 at 15:24
  • \$\begingroup\$ Don't worry for that, you already gave me more than expected. I will check theses advices as soon as possible, thanks! \$\endgroup\$
    – Aulaulz
    Commented Jul 26, 2014 at 16:01
1
\$\begingroup\$

Are you dynamically creating the buffer for the draw call each frame? If the walls never (or rarely) change then a vbo will be a good optimization.

\$\endgroup\$
1
  • \$\begingroup\$ I already use vbo with all my meshes. I create them once. \$\endgroup\$
    – Aulaulz
    Commented Jul 26, 2014 at 12:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .