Message-Id: <199806282324.AAA17259@sable.ox.ac.uk>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: "Daniel Faur" <dano AT dynaguy DOT demon DOT nl>
Date: Mon, 29 Jun 1998 00:19:45 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Using timer to control sprite movement
Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk
CC: djgpp AT delorie DOT com
Precedence: bulk

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