Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectMore assembly fun! new Reply to this message
Posted bySnowball 2
Posted on11/06/03 06:52 PM



So I figured out how to draw a bitmap in mode 13, hooray! Now I'm trying to make a sprite(another bitmap) move around on my loaded bitmap background. I think I know how I want to do it and here's the general idea:

1.Draw the background to screen buffer
2.Draw the sprite over it
3.Transfer screen buffer to video memory for output

Now here comes the tricky part for me. As the sprite moves around my background I don't want to constantly redraw the entire image. I just want it to redraw the sprite and just the portion of the background that it moves over. Or is there another easier way to avoid having to redraw what the sprite moves over?






SubjectRe: More assembly fun! Reply to this message
Posted byBart T.
Posted on11/06/03 07:48 PM



> 1.Draw the background to screen buffer
> 2.Draw the sprite over it
> 3.Transfer screen buffer to video memory for output

Sounds good.

> Now here comes the tricky part for me. As the sprite moves around my background
> I don't want to constantly redraw the entire image. I just want it to redraw
> the sprite and just the portion of the background that it moves over. Or is
> there another easier way to avoid having to redraw what the sprite moves over?

On one hand, people will tell you that today's machines are fast enough that redrawing the entire scene shouldn't be a concern, but IMHO, it's good that you're trying to optimize this, because it would be an issue on very old hardware.

I actually did the same thing once. You can have your sprite object defined as 2 bitmaps: The actual sprite and a "background save" buffer.

Each time you move the sprite, draw the background save buffer as a solid, non-transparent sprite (basically, copy it directly) at the position where the sprite is currently at (to erase it.) Next, copy the background where your sprite will move to and then draw the sprite.



----
Bart


SubjectExcellent idea new Reply to this message
Posted bySnowball 2
Posted on11/07/03 00:35 AM



Think I'll try to implement that on the train ride tommorrow. As far as trying to optimize it's really a good idea for me since my laptop isn't very cutting edge(3 year old celeron 1ghz) and the integrated graphics leaves something to be desired.

I may have a problem when I try to run this in the lab at school though. They've got more powerful CPU's and I have yet to implement any sort of speed regulation here. Now that I'm in the nitty gritty of drawing graphics how is it that you can set a certain speed for the program to run? Just continuously fetch system time and have it execute at certain intervals?






SubjectRe: Excellent idea new Reply to this message
Posted byBart T.
Posted on11/07/03 01:08 AM



> Think I'll try to implement that on the train ride tommorrow. As far as trying
> to optimize it's really a good idea for me since my laptop isn't very cutting
> edge(3 year old celeron 1ghz) and the integrated graphics leaves something to be
> desired.

By "very old" I meant 386, 486, and early Pentiums :)

> Now that I'm in the nitty gritty of drawing graphics how is it
> that you can set a certain speed for the program to run?

There are a few ways to do it.

You can program the PIT (programmable interval timer) to generate an interrupt at some frequency (say 30 or 60Hz) and wait at the end of each frame for that. This is kind of a pain in the ass because it can screw with system timing on DOS-based systems so you've got to call the original DOS interrupt vector at 18.2Hz to maintain time.

Alternatively, you can wait for the Vsync signal before blitting. The problem with this is that it's mode-dependent, but AFAIK, it will be the same for all systems at a given mode. For Mode 0x13, it occurs at 70Hz. For 320x240 Mode X it happens at 60Hz.

You'd want your game loop to look like this:

1. Game logic
2. Render to buffer
3. Wait for vsync
4. Blit!
5. Goto 1

Step 3 consists of polling the VGA. Here's some code for it:

WaitVSync:
mov edx, 0x3da ; input status
.l0:
in al, dx
and al, 8
jnz short .l0
.l1:
in al, dx
and al, 8
jz short .l1
ret

IIRC, bit 7 being set means the VGA controller has entered the Vsync period (when the monitor's beam is being retraced to the top and the VRAM is not being accessed by the VGA.) You will want to check up on that to make sure.

This code consists of 2 loops: The first (.l0) will keep looping until we're OUT of the vsync period (in case this routine was called while in the middle of a vsync.) The second will wait until vsync is entered.

I think you only really need the second loop. The first loop will essentially skip an entire frame (it just makes sure to wait for the next vsync period so we're guaranteed to be at the beginning of vsync when the routine exits.)


----
Bart


SubjectRe: More assembly fun! new Reply to this message
Posted bygalibert
Posted on11/07/03 03:59 AM



> Now here comes the tricky part for me. As the sprite moves around my background
> I don't want to constantly redraw the entire image. I just want it to redraw
> the sprite and just the portion of the background that it moves over. Or is
> there another easier way to avoid having to redraw what the sprite moves over?

Very soon you'll want to scroll and/or animate the background, and then all the time you'll have spent programming dirty handling will be lost. 5 years ago it was worth it, not anymore.

OG.






Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode