Quote:
Originally Posted by hellrazor
The improvement that it would introduce is abstraction.
|
Some things don't need to be abstracted. I think I understand what you're trying to get at. Graphics don't need to be abstract because once you choose a graphics library to handle all of your 3d rendering, it's extremely unlikely that you will need to support a second plug-able renderer.
I think we need to be perfectly clear about one thing: The game computes everything, not the renderer.
The graphics are strictly OUTPUT. The game creates the information that tells the graphics what to put out to the screen. So you look for the user input inside the game and when it comes you have the game update the graphics to change what the user sees, the graphics doesn't work independent of the game. The graphics doesn't handle input or entities as complex as your describing. When anything "happens" in the game, it's not the graphics processing it.
So tell me one thing. If the graphics/render handles the input, how the heck is the game going to know about it?
Quote:
Originally Posted by hellrazor
Yeah, something like that but I don't want to write a whole bunch of game logic if I can't use it because the graphisc isn't giving me a menu to tell the game to run that part of the logic.
I guess maybe I could just write a simple terminal thing to tell me what the game would tell the graphics, and then just write back what the graphics would have told the game or something.
|
I do not recommend doing this. You need a renderer because you only want to tie up the graphics device when you're ready to render. Prepare everything ahead of time and then tell the Renderer, which knows how to ouput graphics, to do it all at once. This can't be done in parallel (not efficiently if done safely,) where other parts of your program can. By doing them together your obfuscating your code, making it harder to read, and taking more time to render each frame.