I?m creating a simple engine that uses SDL, but I
don?t know how to fix the problem of the things
working too fast. I don?t know how to control
framerate so things aways go in diversified speed and
I don?t want it. How can I adjust the speed of the
engine? I mean, so people (and me) will be able to run
my simple demo?s/test progs at the speed I wanted it
to show at the refresh rate they want. Is that a
simple way of doing it?
You can restrict the rendering (and logic) frame rate to some
arbitrary value, but I’d recommend against it for three reasons:
1) It eliminates all chances of utilizing "spare"
rendering power for smoother animation.
2) The resulting frame rate is likely to interfere
with the refresh rate of the display, which
cannot safely or reliably be changed.
3) It doesn't solve the situation where rendering
is too slow, so your game logic may run too
slow on slower machines, unless you deal with
that specifically.
The best and most robust solution is to separate the game logic from
the rendering frame rate. There are some different approaches to
this, including:
* Fixed logic frame rate with timer driven thread. (Game
logic is handled in a separate thread that is driven at
a fixed rate - say 100 Hz - by a timer of some sort.)
+ Simple - at least in theory.
+ Easy to design exact (repeatable) game logic.
+ Fixed frame rate ==> simple and robust game logic.
- Depends totally on OS scheduling accuracy and
granularity for smooth animation.
- Threading issues complicates the code.
- Threading overhead. (Virtually zero on some
platforms, though.)
- Needs interpolation for smooth animation at all
rendering frame rates.
- Interpolation is hard to get right, since there
is no hard synchronization between the logic and
rendering threads.
* Fixed logic frame rate with frameskipping and/or
interpolation. (Game logic runs in the rendering thread,
but is throttled so that it runs at the correct average
frame rate.)
+ Fixed frame rate ==> simple and robust game logic.
+ Easy to design exact (repeatable) game logic.
+ No multithreading complexity
+ Interpolation is easy to implement, since there
are no asyncronous buffering issues.
+ A very high logic frame rate (say 1 kHz) is an
easy hack if you want to avoid interpolation.
- Needs interpolation or very high logic frame rates
for smooth animation at all rendering frame rates.
* Time based logic. (Logic frame rate == rendering frame
rate, but speed, acceleration etc is scaled based on the
delta times between frames.)
+ Accurate positions and smooth animation,
regardless of frame rate.
+ No need for interpolation for perfectly smooth
(even sub-pixel accurate) rendering.
- Exact/repeatable game logic is hard to implement.
- Special measures must be taken to ensure that
collision detection works properly at low frame
rates.
- Game logic is complicated by extra math for the
time scaling.
(Note: My personal favvourite for 2D action games is the second one;
fixed logic frame rate + interpolation. That’s what I use in Kobo
Deluxe and Fixed Rate Pig, both found on my site.)
How can it be incorporated
with a graphic engine?
That depends on how you deal with the game logic timing. It’s rather
trivial as long as you keep the game logic in the same thread as the
rendering engine. It gets a bit trickier with interpolation (need to
buffer some old coordinates for each object and do the actual
interpolation to get the graphics coordinates for each frame), and
perhaps even worse with a multithreaded approach, due to the sync
issues. (Can’t just share variables. At best, you’ll get occasional
jittering.)
Is it a good idea for an engine
to have something like a “sprite warehouse” where all
the sprites are putted in?
Why not? I have something like that in Kobo Deluxe and Fixed Rate Pig,
and it’s turned out to be rather handy when dealing with groups of
related sprite images, animations and stuff. (Integer indices rather
than pointers, so all you need is start and count.)
Anyway, it depends on the rest of your design. For example, a script
driven engine wouldn’t really need any centralized bank like that, as
you can just manage images on a per-object basis, in whatever way
suits each object. High level languages usually do a good job of
making that easy anyway, so why second guess your scripting engine?
Thanks alot! I need to say
this timer thing will need to work with the sound
system too latter.
Yeah, another tricky detail… The easy way is to just send
asynchronous messages from the game logic to the sound engine
(perhaps using a lock-free FIFO, as I do in Kobo Deluxe) - but that
obviously means that sound timing is quantized to the physical logic
frame rate (same as the rendering frame rate unless you have a
separate logic thread) and/or audio buffer size.
In recent (not officially released) versions of Kobo Deluxe, I’ve
introduced a timestamped interface that keeps a “constant” latency,
rather than the random jittering and quantization effects of previous
versions. Very simple stuff in theory, but things are complicated by
the timing jitter caused by OS scheduling granularity, rendering time
fluctuations and stuff. That’s handled by a slowly decreasing time
offset that’s adjusted slightly whenever the engine realizes the
delay is smaller than the minimal latency.
Do you think I?m the right path for etting anything
done?
The single most important factor is motivation; if you really want
to get something done, you will, one way or another. Anyway, your
thinking makes sense, so chances are good, I think. 
Sometimes I think it is better to plan
everything before start, than making things work and
slowly improve them.
What do you think about it? The Design of engines?
Well, there are different “scools”. Some say you should definitely
design everything before coding anything, whereas others say you
should basically start coding as soon as you know the set of problems
to solve.
Personally, I think the former approach is most suitable for low level
languages (C or asm) and/or environments or situations where
incremental coding and testing is hard. It may also have some
relevance to high level design (APIs and stuff) in large projects
with many developers. As for my own personal and work related
projects, I’ve realized that I’ve drifted more and more towards a way
of working that resembles Extreme Programming a great deal.
Any
good tip about a book or online material?
There are some SDL examples, tutorials and articles around. You can
find some of them on the SDL site, but there’s probably more out
there.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 05 August 2004 18.27, Romulo Gnomo wrote: