flat assembler
Message board for the users of flat assembler.

Index > DOS > I'm building a game and could use some help

Author
Thread Post new topic Reply to topic
Cas



Joined: 26 Feb 2004
Posts: 82
Location: Argentina
Cas
Hi! Rolling Eyes

I'm working on a spacecraft game. It is not fully made in assembly language, but the code so far IS. I mean, I've written the whole blitter in Flat Assembler and the ISRs for the Keyboard and the Timer. They work OK. The problem I'm having now is how to synchronize with the vertical retrace. I know how to do this if it's the only thing to be done, but I don't get it to work well when I have to move the ships at the same time.
What happened is this: I make a program in QuickBasic to try the Assembly routines. I change things until it works OK on my Pentium 200MHz. But, as I want this game to work even on a 486DX2, I try the code in my other two little PCs: a 486DX4 100MHz and a 486DX2 66MHz and I find out that it does not synchronize there. It's like the timings are different.

The final question: Can anybody send me an example (in any language) about which steps I should take to make a main loop at about 200Hz synchronize with the VGA at 60Hz? Question
Maybe you didn't even understand what I'm asking... I haven't been very clear Confused Well, if you think you can help me, but are not sure, tell me and maybe we can chat, I explain you and show you the code. (Whoever you are Razz )

_________________
«Earth is my country; science is my religion» - Christian Huygens
Post 05 Apr 2004, 04:50
View user's profile Send private message Yahoo Messenger MSN Messenger Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
AFAIK, you can program the video card to make interrupt on the vertical sync pulse. IMHO, this is the only proper way to make real synchronization.

Regards
Post 05 Apr 2004, 05:56
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
why do you need 200Hz, i coded few games already and 40 was always enough for me.
Post 05 Apr 2004, 18:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
If you do hardcoded "timeloops", the game will run very bad on other computers (too slow, too fast).

If you limit your gamespeed solely by synchronizing to the refresh rate, you will have problems if the user overrides the refresh rate - use a time-based approach instead (yes, it's more work).

Making the graphics card generate an IRQ is cute, but not all boards support this, and you cannot use the feature if you want your game to be compatible with windows - better to use the old method:
Code:
vret:    mov     dx,3dah
.v1:     in      al,dx
       test    al,8
        jz      .v1
.v2: in      al,dx
       test    al,8
        jnz     .v2
    
Post 05 Apr 2004, 20:41
View user's profile Send private message Visit poster's website Reply with quote
Cas



Joined: 26 Feb 2004
Posts: 82
Location: Argentina
Cas
Thanks. Anyway, I already know how to detect the vertical retrace and what I am trying to do is precisely using timer instead of VR synchronization. I am doing something like this:

wait for one vertical retrace
set timer to zero
start:
set minitimer to zero
check if timer is near one sixtieth of a second
if it is:
wait for VR
set timer to zero
refresh
endif
check input
exchange packets
wait until minitimer exceeds "cycleduration" (e.g.: 1/200 seconds)
loop to start

For some reason, when I adjust the values for my Pentium, this does not work well at all on my 486s. Sad

_________________
«Earth is my country; science is my religion» - Christian Huygens
Post 08 Apr 2004, 04:54
View user's profile Send private message Yahoo Messenger MSN Messenger Reply with quote
Cas



Joined: 26 Feb 2004
Posts: 82
Location: Argentina
Cas
Ah... sorry... one more thing.
I use 200Hz, because sometimes I want the objects on the screen to move at different speeds in fraction. That makes me have to invent virtual pixels, for example, the speed of one object can be 20 pixels per second and another one might have one of 20.3 pixels per second. But one second is a very long time. And because I will not refresh in every cycle, 200Hz is not too heavy. But yes, you're right, it makes things much harder to perform.
Post 08 Apr 2004, 04:58
View user's profile Send private message Yahoo Messenger MSN Messenger Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
You will need a military machine to achieve that 200 fps on your game.
and your display frequency shouldn't be higher than 100 Hz, for example its the max in 800x600 of my 15" monitor.

But in assembly you may wanna try to make an optimized code.
I whould suggest you to think a little more on that 20.8 pixel things, cause' if you wait for a vertical sync in a loop, you will not do anything but waiting.

MATRIX
Post 18 Sep 2004, 20:40
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
Cas, you can look at a dos game i make when i first started in asm, full tasm code and only 4k.
you can get it here: http://www.falconrybells.co.uk/

called "pong.zip" it's pong game set in space!.

\\\\||////
(@@)
ASHLEY4.
Post 19 Sep 2004, 01:02
View user's profile Send private message Reply with quote
DuLac



Joined: 13 Sep 2004
Posts: 8
Location: Portugal (EU)
DuLac
Just curious... isn't 1/40 seconds more than enough? Confused
The eye see things as continuous with more than 16 frames/sec.
Few people catch diferences between 16 and 30 frames.

Anyway the focus should be on correct behaviour instead of attempeted frames that may, or not, be available which seems to be the case.

Cas wrote:

<...>
wait until minitimer exceeds "cycleduration" (e.g.: 1/200 seconds)
<...>

For some reason, when I adjust the values for my Pentium, this does not work well at all on my 486s. Sad


Just Guessing : Incorrect draws and/or speed going up and down.
In other words: de-synchronization on more heavy calculations and/or slower CPUs...

If so: You are spending too much time with useless draws in expense of movement calculation... And have no actual control on the syncronization of movements... But you don't have to... Neither one...


Idea

Just invert your aproach:

repeat
{
Check_Controls

// Prepare for critical sequence
New_moment <- Get time
delta_time <- New_moment - last_moment
Last_Moment <- new_moment
Check Behaviour rules (Controls)

// More Critical part
Movement calculations (delta_time) // Delta correction

// Less critical part as will not influence the real critical one
Process_image (Movements ; Behaviour)
wait_for_sync
Draw_image
}
until EndOf


Exclamation
This should make frames auto-adapted (actualy CPUxCode dependent) and should work with slow CPUs and/or heavy code... On too slow CPUs or too heavy code frames frames will go down 'per si' ... on faster CPUs they will go up to the video sync limit.

The hard part will be to calculate movements and events adapted to the time slice in between... Just determine what happens between slices of time and it will be shown correctly...

Smile The behaviour will follow the CPU instead of you following both Razz

Cheers
DuLac.

_________________
Just clean patterns under the junky surface...
---
Le$$ nicotin: Smoke more to get the same dose.
New tabaco: Less nicotine, Same tar (cancerous).
Balance: Profit$ up, Population down
Post 19 Sep 2004, 03:13
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
Most people's monitor are more closely mached then there pc speed. 60hz-100hz
By making your main game loop, so it wait's very little time for vetical retrace on a 486, you would get the right speed on most pc's, you would after have some very bad programming for your dos game to be slow, even on a 486, in my main loop i had to put a big delay in, as even on a 486 it ran too fast.

\\\\||////
(@@)
ASHLEY4.
Post 19 Sep 2004, 10:51
View user's profile Send private message Reply with quote
Bitdog



Joined: 18 Jan 2004
Posts: 97
Bitdog
Maybe something like this might work?
Make a macro that checks if Vretrace is right for a screen update,
and sprinkle it about in your game loop code. (use ports to check)
If Vretrace, if data ready, if time right, update screen, ELSE continue.
Continue in the work loop which has functions called in priority, top to bottom.
So bottom game functions get called durring slow times only.
Like a priority system.
Then an array of bytes indicating the status of each function called since last screen update allows already processed functions to be skipped. There would be no wait for Vretrace at times that a good frame rate is required. INC function status bytes on each screen update, & zero out a functions status when called (maybe) then, make sure a function is called if it flips the status byte & sets the zero flag?
That way it's not ignored forever.
At 60 frames per second (60hz), bit 7 of a byte is set every 2 seconds?
Post 18 Jan 2005, 15:29
View user's profile Send private message Reply with quote
Bitdog



Joined: 18 Jan 2004
Posts: 97
Bitdog
JOHNFOUND "AFAIK, you can program the video card to make interrupt on the vertical sync pulse. IMHO, this is the only proper way to make real synchronization. "

I am very interested in this method.
Do you have any asm code, links, or further info for me/us?
Post 29 Jan 2005, 19:36
View user's profile Send private message Reply with quote
Cas



Joined: 26 Feb 2004
Posts: 82
Location: Argentina
Cas
About that. In my computer, my motherboard allows me to assign IRQ 10 to the video board. In case the interrupt sync can be done... is it ALWAYS going to be at IRQ 10? If not.... how can I find out if this is available on a PC and at which IRQ?
By the way... THANK YOU FOR ALL THE HELP YOU'RE GIVING ME. This is still very useful after all this time since that project. Smile
Post 05 Feb 2005, 04:26
View user's profile Send private message Yahoo Messenger MSN Messenger Reply with quote
E}I{



Joined: 30 Apr 2005
Posts: 7
E}I{
IMHO you shouldn't use video IRQ, because it will not work on many videocards. I cann't recommend optimal solution, but I think detecting length of video refresh (in timer ticks) can help you to roughly determine where beam currently is, and how much time you have until next vsync, this can be helpful.. Also.. you can set new timer interrupt to happen just before vsync and wait only remaining millisecond or less(and reset timer counters after detecting actual vsync pulse) Nice idea, huh? this method can also be combined with triple-buffer. (you draw in buffer A, buffer B is ready to display and copied into framebuffer C (or pageflipped) by interrupt handler ) For movement you can update coords after/before rendering each actual frame, but divide all speeds, given initially in "pixels per second" by known refresh rate, using fixed-point math or FPU.
Post 04 May 2005, 18:32
View user's profile Send private message Reply with quote
loyola



Joined: 24 May 2005
Posts: 1
loyola
Listen, it`s all very simple. Get your game commands in( up down shoot ect.). and calculate where you want to put your pixels. make the changes in memory fist before even touching the screen. Then, have your screen memory as a pointer (in c++, or an array in assembly language ect) then refresh the screen and draw the whole thing at once by having the screen pointer locate your memory image.
Post 24 May 2005, 15:46
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.