Mail Archives: djgpp/1998/06/28/19:25:13
On 26 Jun 98 at 16:30, Daniel Faur wrote:
> I'm new to programming in DJGPP and Allegro. I used to program C/C++ in
> TurboC, real mode. My problem is that I used to put a lot of funtions which
> control the movement of sprites in an interrupt-handler, but Allegro says
> you should lock the functions and variables before using them in an
> protected-mode interrupt-handler. How do I go about that with all the
> functions I use?!? The reason I used this method was to let the sprites
> always move 25 or 50 times a second even on computers which do not get a
> framerate of 25/50, but what other way is there to achieve this?
It's generally best to make your interrupt handlers do as little as
possible. Locking complicated arrangements is rather awkward, unless
you just lock everything (using the crt0 flag), which basically
disables virtual memory.
The simplest thing to do to achieve what you want in general is to
just increment a global variable in the timer handler. This is your
target game cycle. In your game loop, you draw the graphics, then
while your actual game cycle has not caught up with the target cycle
you perform more game cycles. In code this looks something like this
(untested):
| volatile int target_game_cycle;
| void game_cycle_timer()
| {
| target_game_cycle++;
| }
| END_OF_FUNCTION(game_cycle_timer);
|
| void game_loop()
| {
| int actual_game_cycle = 0, dirty = 0;
|
| LOCK_VARIABLE(target_game_cycle);
| LOCK_FUNCTION(game_cycle_timer);
|
| target_game_cycle = 0;
| install_int_ex (game_cycle_timer, BPS_TO_TIMER(50));
|
| do {
| if (dirty) do_graphics(); /* no point in doing graphics if not dirty */
| dirty = 0;
| while (actual_game_cycle < target_game_cycle) {
| dirty = 1;
| do_one_game_cycle();
| actual_game_cycle++;
| }
| } while (!end_of_game());
| remove_int (game_cycle_timer);
| }
I hope that's reasonably clear. You'll probably need to fiddle with
the timer rate a bit; IMHO it's generally better to have the timer
going very quickly, so that several game cycles get scheduled each
time through the game loop. I find that if the rate is too low
things look rather jerky on slower computers.
References:
Allegro Vivace, chapter 9, particularly the example in 9.4.3.
The new Allegro FAQ also addresses this topic in some depth.
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
t again. Having said that, you'll never get around it whatever method you
> use - it's the nature of the system.
If a person is dedicated enough, they'll break through any
encryption. Using djp will deter the casual cracker, but anyone
with a copy of djp can decompress your executable and read off the
strings. If you use a modified version of course they won't be able
to do this so easily -- but then you must use the stubless
technique, which means that they can still load the program into a
debugger and read the strings from there once it's uncompressed. You
can't win.
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -