Hi,
I just happen to be writing an engine myself and that currently works as
follows (it is a ms-windows app btw) I simplify it a lot though since the
internals are much more complex
Windows loop
Put key/mouse events in queues
Check if alt-f4 or close etc is pressed
Call game processor
Game processor
Call graphics subsystem
Call sound subsystem
Call scripting subsystem
Distribute mouse/key to objects listening for them. If an object has
an
event handler it will be added to the runlist see later.
Graphics subsystem
(has a list of all graphic objects)
Call every object to see if it has changed (a 'static' animation might
return changed and update its internal state, depending on gameclock)
if there was a change call drawing routine in every object (i.e.
refresh
screen with current state)
Sound subsystem
Works almost the same as the graphics subsystem
Scripting
Will call objects Execute metod on the 'runlist' (which will run a
part
of the script) if an object returns eSleep move it to the sleeplist. If it
returns eFinished remove it from the runlist
(objects can be created or removed from the runlist while
executing
the scripts)
Will check the sleeplist for any objects no longer 'sleeping' and move
them to the runlist
This is sort of what I got now. Currently I use 2D graphics but I am
replacing it with directx.
As miss elaine eos pointed out, don't worry to much about optimizing yet
(todays computers are pretty fast) you might want to spend optimization on
the graphics, my experience it that those take most of the time.
Anton" <anton.txt@[EMAIL PROTECTED]
> wrote in message
news:Xns99DEDAD89B6F9antontxtgmailcom@[EMAIL PROTECTED]
> Hello all.
>
> I have a somewhat general question about game architecture. I'm gonna
> make a squad-level isometric game. I have tiles, unit animations,..
> e.t.c. And the question is, how I should design the graphical subsystem.
>
> Options:
>
> I. The game screen is updated tile-by-tile, only changed tiles
> (including characters moving thereon) at a specified rate (anomation
> speed).
>
> GUIis treated separately. Once animation has stoppped, I poll input
> events and handle them until a unit has received an order. Then I call
> the animation loop.
>
> Such things as burning things, smoke e.t.c. should be animated only
> during this "interface" loop. Same go to scrolling.
>
> BTW: Remember, in XCOM all smoke and fire tiles freezed when units were
> acting, and came back alive after they had accomplished thier orders. I
> suppose they used this approach.
>
> II. Doing everithing synchronously.
> There's one main loop, which never stops polling, handling events (Game
> screen then GUI), and immediately updating the whole screen without any
> delay. The game mechnics is synchronised by virtue of some game-event
> queue wherein events are bound to their times, so that GFX (frames per
> second) are independant of the game speed.
>
> This latter method seems easier and more versatile, but is't too
> CPU-heavy (like using an oscilloscope to drive nails in, or to shoot at
> birds from a mortar)?
>
> Thanks in advance for feedback,
> Anton
Regards, Ron AF Greve
http://www.InformationSuperHighway.eu
|
