Does that mean we will have to make a function pointer wrapper for each api call and call into it from the independent layer similar to the way we have the load file api now?
We will be some function pointer writing mofos!
Perhaps there is another way that I am missing?
Not that it bothers me that much just some typing that well have to do.
We will be some function pointer writing mofos!
Perhaps there is another way that I am missing?
Not that it bothers me that much just some typing that well have to do.
Edited by Ray Garner
on
I doubt there will be any function pointer writing. It'll just be two or three switch statements at the head ends (rendering, texture submission, etc.), probably, that's like switch(renderer) case GL: case D3D: etc. Maybe there will be a little more cruft because of crappy Windows API design, like resync'ing surfaces or who knows what, but for the actually rendering part of things, it should be straightforward.
- Casey
- Casey
Thanks for the explanations Casey. So you're saying you'll just continue to pass all render data through the game memory/buffer structs using GameUpdateAndRender()?
I found that for my purposes it seemed easier to have the game communicate directly with the renderer. I'm thinking like for openGL, for instance, you might want to create a static VBO for the tile map on loading and then have dynamic ones for other purposes that get updated every frame. This is just an example I could think of, but it just seems like it would be a pain to communicate this type of stuff to the platform through the game memory/buffer structs each frame, and easier to make calls to the renderer to tell it specifically what you want.
I guess it can be done either way. In my case, I have the platform (using SDL) creating the openGL context, but the renderer is compiled into the game compilation unit. All works smoothly and the platform can handle its stuff and the game can communicate in a non-coupled way with the renderer. Is there a downside to doing it the way I'm doing it (if what I said makes sense)?
Maybe me using SDL for the platform layer changes the situation, as I'll only need one platform layer ever.
Sorry for the novel :)
I found that for my purposes it seemed easier to have the game communicate directly with the renderer. I'm thinking like for openGL, for instance, you might want to create a static VBO for the tile map on loading and then have dynamic ones for other purposes that get updated every frame. This is just an example I could think of, but it just seems like it would be a pain to communicate this type of stuff to the platform through the game memory/buffer structs each frame, and easier to make calls to the renderer to tell it specifically what you want.
I guess it can be done either way. In my case, I have the platform (using SDL) creating the openGL context, but the renderer is compiled into the game compilation unit. All works smoothly and the platform can handle its stuff and the game can communicate in a non-coupled way with the renderer. Is there a downside to doing it the way I'm doing it (if what I said makes sense)?
Maybe me using SDL for the platform layer changes the situation, as I'll only need one platform layer ever.
Sorry for the novel :)
Edited by Don S.
on
Reason: Meant GameMemory/Offscreen buffer structs instead of GameState
It depends a lot on the circumstances, but yeah, generally you don't need to talk to the renderer because most renderer work these days just involves putting stuff into memory buffers anyway, so the renderer can just forward these buffers to the game without the game knowing where they came from, etc.
- Casey
- Casey