A89: Re: Scroller Engine
[Prev][Next][Index][Thread]
A89: Re: Scroller Engine
Hi!
| All Characters, Enemies, Turrets, Bosses are inside an object structure
Hehe, OOP. Please download the source to my syntax editor if you want to
see some _real_ OOP. :-) But on calculators, it would probably just be some
structure definitions and variable-sized arrays.
| All Projectiles like bullets and powerups are in their own objects to save
| space(they don't need as much data).
I guess here's where the object-oriented concept would go, if there was one:
You'd have a hierarchy like:
TVisualObject
|
TFlyingObject
| |
TBullet TCharacter ... and so on ...
I can only make suggestions, since I've never programmed such a game, but
there is a technique I've seen in Macs in my computer science class, and I
thought it was pretty neat: Each of these is, of course, a structure type.
Let's say the first byte of TVisualObject tells what kind of object this is,
and there is also an x and y coordinate, size, maybe a pointer to a sprite,
etc. Then TFlyingObject needs the same things as well. What you can do is
let the _first_ field of TFlyingObject be something of type TVisualObject.
That way you can cast a pointer to a TFlyingObject to a pointer to a
TVisualObject, and pass it to your drawing function, for example. Tell me
if you need more info.
| All objects are organized into a variable pointer 'database'(char* or
void*
| not sure)that has the addresses where all the character objects are
located.
For the database, I would have a pointer to a variable-sized array.
| An Integer variable would say how many objects are active(on screen)at a
| time, ditto for projectiles.
You don't need information about how _many_ there are, but which object is
on the screen and which isn't. In fact, you may either go through the
entire array, or you can make a second array that tells which ones are on
the screen.
The problem with this is that there have to be a lot of reallocation
functions. Maybe someone should make a system similar to Delphi's, where
space is allocated on a specific alignment (e.g. always four or eight array
elements are allocated at once).
| Object Database will be cleaned every level,
| projectiles dynamically(when they leave the screen)
Sounds good to me, but again, I can only guess.
| I'm thinking of using a frame based system running at about 30fps... every
x
| milliseconds a function is ran which draws the background, reads the
| database for objects, runs code based on that(AI, etc.), updates
projectile
| data, and garbage collects projectiles if needed.
That seems much too complicated for me. You can be sure that the
calculators always run at about the same speed, unless they're overclocked
or the batteries are almost empty. Therefore I would rather leave all
timing out completely. You have to see, though, what happens if a lot of
objects are on the screen. If you do it in grayscale, and have your screen
additionally double-buffered, the flipping of buffers should take much more
time that the updating of objects, I think. But I might be completely wrong
here.
| What do you guys think of this? I'm not sure because I borrow alot of
ideas
| >from more advanced engines(QuakeIII comes to mind).
How do you know about the engines used in that game?
One question to all: Why does _everyone_ put a '>' in front of every 'from'?
Just curious.
Bye,
Sebastian Reichelt
Follow-Ups:
References: