Board index » delphi » Graphics unrelated to CPU speed & video speed

Graphics unrelated to CPU speed & video speed

Bonjour All,

Can someone tell me what I have to do to about the following problem?

I programed a simple game (boresome!) on a 80486-66 MHz or something.
But when I run it on my own computer (Pentium-150) it goes a LOT faster.

I tried to compute the video speed and correct the delay function to
that video speed. It doesn't work (perhaps my way of computing the
v.speed is incorrect, but I don't think so).

I don't program graphics/games much so if someone could give a solution
to this problem...

Au Revoir,
    Bateau AKA Steven Boot,
    S.J.B...@CPEdu.RuG.Nl

 

Re:Graphics unrelated to CPU speed & video speed


In article <330E0B40.1...@cpedu.rug.nl>, S.J.B...@cpedu.rug.nl says:

Quote

>Bonjour All,

>Can someone tell me what I have to do to about the following problem?

>I programed a simple game (boresome!) on a 80486-66 MHz or something.
>But when I run it on my own computer (Pentium-150) it goes a LOT faster.

>I tried to compute the video speed and correct the delay function to
>that video speed. It doesn't work (perhaps my way of computing the
>v.speed is incorrect, but I don't think so).

A simple way to get a fixed (on a fast enough computer) rate is to
poll the lowest byte of the system time kept at the constant memory
address of [$0040:$006c] (or [Seg0040:$006c] if you target also
protected mode). Something like

var
  old_time:byte;  

...
  repeat
    old_time:=mem[Seg0040:$006c];
    do one cycle of the game  
    repeat until old_time<>mem[Seg0040:$006c]
{* This last line will procduse CPU-speed independent delay,
also takes into account the difference in time spent on computing
one cycle of the game *}
  until game_ends;

A more popular method seems to be to synchronize your game with the
vertical retrace. I don't know how to achieve that, as I have had
satisfactorily little flicker in my simple games simply by using
an offscreen buffer and doing all rendering there and copying the
entire buffer to video mem once every 55 milliseconds (= the frame
rate you get with the above code). Probably the game programmer's
encyclopedia (available e.g. from x2ftp.oulu.fi) will tell you how
to do that.

Hope this helps,

        Jyrki

Re:Graphics unrelated to CPU speed & video speed


Quote
Jyrki Lahtonen wrote:

> In article <330E0B40.1...@cpedu.rug.nl>, S.J.B...@cpedu.rug.nl says:

> >Bonjour All,

> >Can someone tell me what I have to do to about the following problem?

> >I programed a simple game (boresome!) on a 80486-66 MHz or something.
> >But when I run it on my own computer (Pentium-150) it goes a LOT faster.

> >I tried to compute the video speed and correct the delay function to
> >that video speed. It doesn't work (perhaps my way of computing the
> >v.speed is incorrect, but I don't think so).

> A simple way to get a fixed (on a fast enough computer) rate is to
> poll the lowest byte of the system time kept at the constant memory
> address of [$0040:$006c] (or [Seg0040:$006c] if you target also
> protected mode). Something like

> var
>   old_time:byte;

> ...
>   repeat
>     old_time:=mem[Seg0040:$006c];
>     do one cycle of the game
>     repeat until old_time<>mem[Seg0040:$006c]
> {* This last line will procduse CPU-speed independent delay,
> also takes into account the difference in time spent on computing
> one cycle of the game *}
>   until game_ends;

> A more popular method seems to be to synchronize your game with the
> vertical retrace. I don't know how to achieve that, as I have had
> satisfactorily little flicker in my simple games simply by using
> an offscreen buffer and doing all rendering there and copying the
> entire buffer to video mem once every 55 milliseconds (= the frame
> rate you get with the above code). Probably the game programmer's
> encyclopedia (available e.g. from x2ftp.oulu.fi) will tell you how
> to do that.

> Hope this helps,

>         Jyrki

procedure waitretrace;assembler;

label
        l1, l2;
asm
                mov dx,3DAh
l1:
                in al,dx
    and al,08h
                jnz l1
l2:
                in al,dx
                and al,08h
                jz  l2
end;

Remco de Korte
Soft Machine
Nederland
http://www.xs4all.nl/~remcodek/softmach.html

Re:Graphics unrelated to CPU speed & video speed


Quote
Remco de Korte wrote:
> procedure waitretrace;assembler;

> label
>         l1, l2;
> asm
>                 mov dx,3DAh
> l1:
>                 in al,dx
>     and al,08h
>                 jnz l1
> l2:
>                 in al,dx
>                 and al,08h
>                 jz  l2
> end;

Just one stupid question: Why don't you use local labels?

procedure waitretrace;assembler;
asm
   mov dx,3DAh
@@l1:
   in al,dx
   and al,08h
   jnz @@l1
@@l2:
   in al,dx
   and al,08h
   jz @@l2
end;

Looks alot better to me, and it can't be "missused".

- Asbj?rn

Re:Graphics unrelated to CPU speed & video speed


Quote
Asbj=F8rn wrote:
> Just one stupid question: Why don't you use local labels?

> procedure waitretrace;assembler;
> asm
>    mov dx,3DAh
> @@l1:
>    in al,dx
>    and al,08h
>    jnz @@l1
> @@l2:
>    in al,dx
>    and al,08h
>    jz @@l2
> end;
> =
> Looks alot better to me, and it can't be "missused".

Just one stupid question:  Why use @@ when @ to precede a label should
be sufficient?  Is there really any difference there?  If so, I've never
noticed one.  (Okay, so maybe that's *two* stupid questions.  :-)

Also, it doesn't matter *quite* so much here, but remember that "1" and
"l" don't go well together.  (On my screen, I can't tell them apart in
this courier font.)

Quote
> - Asbj=F8rn

-- =

Scott Earnest        | We now return you to our regularly |
set...@ix.netcom.com | scheduled chaos and mayhem. . . .  |

Re:Graphics unrelated to CPU speed & video speed


Quote
Scott Earnest wrote:

> Asbj?rn wrote:

> > Just one stupid question: Why don't you use local labels?

> > procedure waitretrace;assembler;
> > asm
> >    mov dx,3DAh
> > @@l1:
> >    in al,dx
> >    and al,08h
> >    jnz @@l1
> > @@l2:
> >    in al,dx
> >    and al,08h
> >    jz @@l2
> > end;

> > Looks alot better to me, and it can't be "missused".

> Just one stupid question:  Why use @@ when @ to precede a label should
> be sufficient?  Is there really any difference there?  If so, I've never
> noticed one.  (Okay, so maybe that's *two* stupid questions.  :-)

I don't think there's a diffrence, but all the examples that I learned asm
from used @@, so I've sort of got used to it. And, somehow, many people seem
to use @@ instead of @ when writing asm in pascal. At least, every asm in
pascal code I have uses @@.

Quote
> Also, it doesn't matter *quite* so much here, but remember that "1" and
> "l" don't go well together.  (On my screen, I can't tell them apart in
> this courier font.)

I can't either. I use something like "@@wait_retrace" and "@@be_sure"

- Asbj?rn

Re:Graphics unrelated to CPU speed & video speed


In article <330EF6B0.5...@ix.netcom.com>,
Scott Earnest  <set...@ix.netcom.com> wrote:

Quote
>Asbj=F8rn wrote:

>> Just one stupid question: Why don't you use local labels?

>> procedure waitretrace;assembler;
>> asm
>>    mov dx,3DAh
>> @@l1:
>>    in al,dx
>>    and al,08h
>>    jnz @@l1
>> @@l2:
>>    in al,dx
>>    and al,08h
>>    jz @@l2
>> end;

>Just one stupid question:  Why use @@ when @ to precede a label should
>be sufficient?  Is there really any difference there?  If so, I've never
>noticed one.  (Okay, so maybe that's *two* stupid questions.  :-)

By using the @@label, one can cut and paste the above procedure into
an asm file which uses the LOCALS statment.  It has no effect in BASM, but
it allows one to reuse labels in external assembly files, and makes importing/
exporting asm snippets much easier.

Quote
>Also, it doesn't matter *quite* so much here, but remember that "1" and
>"l" don't go well together.  (On my screen, I can't tell them apart in
>this courier font.)

Same here under OpenStep 4.0.

--Mark Iuzzolino
One of the monst...@monstersoft.com  |  "The worst part about working here
http://www.monstersoft.com           |   is coughing up the furballs."

Other Threads