1
votes

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

1

1 Answers

0
votes

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.