views:

183

answers:

1

hi,

I'm using OpenGL as the bottom end for a 2D tiling engine. When everything is 2D, it is simple to optimize certain issues. For example, scrolling. If I know a certain section of the screen needs to scroll off the bottom, then I can just blit over that portion. I'm evening moving more than 1 pixel at a time. Without explicit hardware support (think old nintendo hw), this requires a lot of pixel writes. An on chip bitblt would be the next best thing.

Essentially, I'm looking at how I can optimize my GL calls to use VRAM texture renders as efficient hardware blits.

Is it possible to have GL scroll the framebuffer, or should I just resign myself to double-buffering and re-rendering an entire scene for each frame?

Thx

A: 

I don't see how you will get around, at the very least, doing a fullscreen rect render with a texture every frame (when it's actually scrolling). I haven't seen the ability to move the frame buffer pointer on graphics cards for a while now.

However, you can limit how much of the scene you need to render every frame. If you keep your scrolling scene as a texture, you can bind to an offscreen frame buffer and render over the invalidated part of it. Then, you just use UV manipulation to do your final full screen rectangle blit.

Jose
thx. the goal was to avoid double buffering.
drudru