Pixel dilemma: Choosing the right graphics API

Question

I want to make a sidescrolling 2D game with destructible terrain. My approach is having the terrain as a BMP and having access to each pixel.

However I have a problem with choosing the right graphics API for my game.

I have already considered several options:

• SDL

I started writing the game in SDL, I had the terrain as surface which I blitted onto the screen every frame. Unfortunately it was very slow, and it became even slower when more of the terrain was visible. I had 30 FPS when drawing only one bitmap on the screen.

• GDI

I have seen a game similar to the one I want to make. It uses GDI and can manipulate pixel by pixel. The speed seems O.K. but as SDL uses GDI as backend on Windows, why can I not just use SDL?

• SDL + OpenGL

Speed is very good, altough I have technical problems - I can't manipulate the texture anymore when it is loaded into OpenGL, and that breaks my whole plan

As mentioned before: I need to have access to every pixel of the image that is drawed, and drawing itself should be fast enough for a 1280 * 500 pixel terrain to be rendered smoothly.

Answer 1

I'd recommend OpenGL as you can offload work to the GPU. However, what you describe sounds like you want to do a lot of the manipulation on the client side (CPU) so you'll probably still have the bottleneck of all the throughput between CPU and GPU.

The best way to accomplish what you want using OpenGL is probably with PBOs (Pixel Buffer Objects). AFAIK it's the most efficient way of accessing/modifying pixel data on the server side (GPU) from the client side (CPU).