game data and rendering mechanism

[ericlangedijk]

I'm not using a rendering thread. I'm just painting after each gametick (which is fired 17 times per second).
My current idea is something about this (without the user interaction yet).
Indeed the renderer needs access to TGame as well as TLevelData (as well as user interface state) in my simple perception

TLevelData.Load(); // loads all needed graphics
TGame.Init(TLevelData); // prepare
TRenderer.Init(TLevelData, TGame); // prepare

The application loop:

if TGame.Tick then
begin
   TRenderer.Render;
end;

[laggyluk]

i'd just make TRenderer and TLevelData global vars

[ericlangedijk]

They are - more or less - global.
I have difficulty seperating and getting together all functionality: which objects 'know' or 'are responsible for' what...

[User137]

I have a reasonably clear separation in game template, that's what should be used as a base for new nxPascal games. I admit it's not multithreaded. If one wants to use threading, he must understand the risks involved, and program alot of things accordingly. I didn't intend such to be a "default". Most games will not, and never should utilize over 30% of cpu power. Unless you're doing some scientific simulation, or just want to run empty loop to fill the gaps...
http://code.google.com/p/nxpascal/so...2Fgametemplate

There is few classes:
nxGame.TGameHandler
-> GameUnit.TGame(inherits TGameHandler)
-> -> GraphicsUnit.TGraphicalGame(inherits TGame)

TGameHandler is core class in nxPascal, sorting out the framerate, input and so on invisibly. TGame class stores and handles all game data, and what happens in physics or otherwise in the game. TGraphicalGame finally holds the graphical data and does rendering. TGameHandler decides when to do game events and when to render, based on settings. For example, frameskipping can be 1 such setting. If game events take longer than intended, it can skip rendering on that frame, and do just game-loop until it catches up.