Wednesday, March 21, 2012

Render System Thoughts

I couldn't sleep, so I thought I'd jot some render system thoughts down.

I need to generate a render system that lives independently of my math system, but my math system has the power to dump data into the render system. I can't imagine a situation where my render system would need MathGraph logic, but it might happen.

The RenderSys I have in mind would have a list of things it is expected to do during a render cycle. Some of these commands might be:
DrawLine(  point , point , color );
DrawBox( point , point , color );
DrawSprite( string ObjectName , int SpriteFrame  );  [for now, my engine can remain vector-based, so sprites aren't strictly necessary]
To name a few. Every time something needs to be put on the screen from the main loop, what really happens  is a command is called that adds one of these to a queue. When the Render() function is called, it analyzes the render window, decides the dimensions of the that window, based on the it's location in the world and zoom, and then begins to dequeue the commands lined up during the rest of the program.

The main advantage to a system like this, is that rendering and game speed can run independently.  If the game should run at 200 cycles per second, then that is easily possible. The main loop would loop until a stopwatch function (called throughout the program, or after every main loop) says it's time to render again, and it takes the most recently completed RenderQueue, and then begins to operate on it.

This could also be used as a first step in multithreaded code. The main, more "mathy", loop (all the math of the game, with none of the graphics), could run on one thread, while the RenderSystem could run on a completely different thread. This would, again, mean that the main thread would run at exactly it's expected speed, but RenderSystem, would run as fast as it possibly can, taking the most recently completed RenderBuffer every time it runs. If the render system gets behind (ie, less than max frame rate), it doesn't hurt the main gameplay speed (if you aren't getting max frame rate, your game still appears to run at normal speed).

Finally, as a disclaimer, I've never done anything like this before (or even of this magnitude)... so I'm not even 100% sure I know if it would work they way I think it should or even how to create such a machine... we'll see...

1 comment:

  1. I've been thinking about this since I woke up. I think the best way to do all this is to create a group of classes, stemming from a parent class. Then create a Queue of the Parent class, and pop them off during render time. Each child will have a redefinition of Parent.Draw(), so each child will draw something different based on it's type

    ReplyDelete