Which ones faster - display lists or saving picture
Author
I am developing a 2d game (see web page in signature) and most of the time, there are only 2 polygons moving (the "cannon" at the bottom and the moving bubble). I was previously rerendering all of the bubbles in the background every single frame (which partially accounts for the horrible speeds I''m currently getting). I realised that I should probably store the background, and every frame just draw the background and then draw the two moving objects.
However, I''m not sure what the fastest way to "store" the background is. The first thing that came to mind was display lists, which are easy to program and supposed to really speed up rendering. However, I realised that even with display lists, it has to perform projections and mipmapping every frame, something which is unnecessary in the immobile background. Is there some way I can render the background somewhere, blit it on to the screen every frame, and then draw my mobile objects?
The official zorx website
create a pbuffer, render the background to it and then use that as a texture with a quad stretched across the screen to render your background.
Author
Is that really more efficient than using display lists? From what little I found about the subject on the Internet, it doesn''t work well on many video cards. Also, there doesn''t seem to be a good cross-platform way of using pbuffers as textures and I hesitate to use anything like extensions in a cross-platform game.
The official zorx website
The official zorx website
quote:Original post by clum
I am developing a 2d game (see web page in signature) and most of the time, there are only 2 polygons moving (the "cannon" at the bottom and the moving bubble). I was previously rerendering all of the bubbles in the background every single frame (which partially accounts for the horrible speeds I''m currently getting). I realised that I should probably store the background, and every frame just draw the background and then draw the two moving objects.
However, I''m not sure what the fastest way to "store" the background is. The first thing that came to mind was display lists, which are easy to program and supposed to really speed up rendering. However, I realised that even with display lists, it has to perform projections and mipmapping every frame, something which is unnecessary in the immobile background. Is there some way I can render the background somewhere, blit it on to the screen every frame, and then draw my mobile objects?
The official zorx website
In 2D it will have one solution : dirty rectangles!
In OpenGL my suggestions are
- render your background first using ortho projection (you can eliminate mapping noise)
- if you are using quad mapping to draw the background I think that display list will not help you : you have not thousands vertices ! Your bottleneck is fill-rate!
- bind your texture so you have not to reload them every frame : this is the most important thing!
- mipmagging/linear filter are used only if you want: if you dont need them dont use them! So simple...
- dont clear color/zbuffer : instead use the background filling for this job.
You can set ''depth_function: always'' when you draw it and use a ''far'' z coordinate for quad vertices.
- I dont see any gain in using pbuffer because you have to render twice: to pbuffer and then texture map the pbuffer itself! Render directly your background texture(s) is not better ???
Hold on. This is silly.
How many bubbles in the background? If it''s less than 10,000, you should be getting perfectly good framerates, even on a cheapass video card. Unless you''re actually rendering spheres, in which case you should not - you should make a bitmap of a bubble, and render that on a single polygon.
If you''re only rendering 10,000 polys and the application is running slowly, you have a bug somewhere. You could find it by profiling.
- Josh
How many bubbles in the background? If it''s less than 10,000, you should be getting perfectly good framerates, even on a cheapass video card. Unless you''re actually rendering spheres, in which case you should not - you should make a bitmap of a bubble, and render that on a single polygon.
If you''re only rendering 10,000 polys and the application is running slowly, you have a bug somewhere. You could find it by profiling.
- Josh
Sorry! I have not read carefully that to draw your background you must re-render a lot of bubbles!!! Render once than use glReadPixels() to save background in a buffer and optionally in a file.
When you have your buffer apply texture on a quad.
When you have your buffer apply texture on a quad.
Author
I am getting pretty decent frame-rates - at low resolutions. At 640X480 I get over 100 fps. By the time I try 1024X768, though, it only goes at fifty-something frames. I''d say that there are about 100 quads drawn every frame. I will try using a pixel buffer as suggested, though I''m still not sure about a cross-platform method of using a pixel buffer as a texture.
The official zorx website
The official zorx website
quote:Original post by clum
I am getting pretty decent frame-rates - at low resolutions. At 640X480 I get over 100 fps. By the time I try 1024X768, though, it only goes at fifty-something frames. I''d say that there are about 100 quads drawn every frame. I will try using a pixel buffer as suggested, though I''m still not sure about a cross-platform method of using a pixel buffer as a texture.
The official zorx website
I hope you will implement an Image class for this however the method is
Create a BYTE buffer of size [num.cmp]x[width]x[height] where num.cmp can be 3 (RGB) or 4 (RGBA) or something else.
Then use glReadPixels with the proper format to fill the buffer.
Then use the buffer as a texture as you know.
Author
I''m resorting to trying this pbuffer thing everyone''s suggesting. I tried out display lists and it only improved it by like 3 fps.
The official zorx website
The official zorx website
A simple render to texture with mip mapping disabled should work pretty well no? I''ll admit that I really have to read up on pBuffers but it sounds relatively similar.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
