The way casey architected the game layer gives a lot of power. Because it only uses the passed in memory, writes to the passed in buffer and is completely stateless itself we can do all the fun things like the live updating and looping stuff.

I'm wondering how you keep that same separation when you're using a very stateful library like opengl for the rendering. Do you aggregate up all the opengl calls you want to make and pass them back to the platform layer? Do you have another separate system just for the rendering? I'm sure casey will cover this like a year from now when he gets to optimizing the graphics with the gpu but I was wondering if anybody has a good way to do this now.

Yes, as you suspected, I will be showing how to do this when we get to hardware acceleration later in the series...

- Casey

Just my guess, but Casey will have to write its own render and rasterizer functions (CGL) that are going to be interleaved with the rest of the game, I assume that in the middle of the GUAR we'll have a blitting function, scaling, rotation, etc.

From that scenario if CGL is everywhere in the GUAR and you want to port it to OGL you will have to change all the calls from one API to another.

I don't think the render will be separated from the game as the win32 platform is. But, as I said before... I'm only guessing :)

The shipping game will run on both software and hardware interchangeably. The renderer will be fully modular in that respect.

- Casey

If you want to do a straight GDI->OpenGL replacement right now, I found it pretty easy to setup using Pixel Buffer Objects. You can map the buffers and write to them in the same way game side and the platform layer handles all the actual OpenGL code.