Optimizing OpenGL calls from Processing
in
Core Library Questions
•
2 years ago
Can anyone help me understand how to use a displayList inside processing to decrease the total number of buffer flushes/method calls etc so I can get my graphics running at a reasonable speed? (I'm not an OpenGL expert)
I'm in the process of writing a 2d game. For a while I was using P2D for rendering. But, some of my special effects (in particular smoke effects) require writing a LOT of pixels and I really need some hardware acceleration. So, I'm switching to OpenGL.
When I render in OpenGL what I find is that the frame rate is determined almost entirely by the number of images/lines/points drawn and has almost nothing to do with the total number of pixels written. On the other hand P2D speed is determined primarily by the total number of pixels written. The result: in OpenGL I'm getting a pretty consistent 30fps (too slow for my tastes) whereas with P2D I'm getting 100+fps usually, but it plummets to 10-15fps when large portions of the screen have to be repeatedly rewritten (e.g. smoke effects).
My conclusion (and I'm not alone, see the link) is that this has to do with the overhead involved in communicating with OpenGL and unnecessary buffer flushing.
http://processing.org/discourse/yabb2/YaBB.pl?num=1235056546
What I want is to be able to queue up a LOT of OpenGL calls (basically I need to draw rectangular images and lines and that's about it). Then, I want OpenGL to "go to town" drawing these ALL AT ONCE. I'm convinced that if I can do this correctly, my FPS should jump enormously (probably 200+fps).
Can anyone tell me how to pull this off?
I'm in the process of writing a 2d game. For a while I was using P2D for rendering. But, some of my special effects (in particular smoke effects) require writing a LOT of pixels and I really need some hardware acceleration. So, I'm switching to OpenGL.
When I render in OpenGL what I find is that the frame rate is determined almost entirely by the number of images/lines/points drawn and has almost nothing to do with the total number of pixels written. On the other hand P2D speed is determined primarily by the total number of pixels written. The result: in OpenGL I'm getting a pretty consistent 30fps (too slow for my tastes) whereas with P2D I'm getting 100+fps usually, but it plummets to 10-15fps when large portions of the screen have to be repeatedly rewritten (e.g. smoke effects).
My conclusion (and I'm not alone, see the link) is that this has to do with the overhead involved in communicating with OpenGL and unnecessary buffer flushing.
http://processing.org/discourse/yabb2/YaBB.pl?num=1235056546
What I want is to be able to queue up a LOT of OpenGL calls (basically I need to draw rectangular images and lines and that's about it). Then, I want OpenGL to "go to town" drawing these ALL AT ONCE. I'm convinced that if I can do this correctly, my FPS should jump enormously (probably 200+fps).
Can anyone tell me how to pull this off?
1
