Bouncing Square Clipping

[tda0626]

Wrote a program that moves a square around the screen and bounce it off the boundaries. It works fine except for when it reaches almost the very top and then it clips right before it impacts the top boundary. Anyone have an idea why it would do that? Source code and program are attached.

Code Select Expand


mov lx1, 0
mov ly1, 99

mov wx, 15
mov hy, 15

mov speedx, 2
mov speedy, 4

BounceLoop:


invoke DrawSR, lx1,ly1, wx, hy, 028h, 1
invoke VRetrace
invoke DrawSR, lx1, ly1, wx, hy, 0, 1

mov ax, speedy
add ly1, ax

mov ax, speedx
add lx1, ax


mov ax, lx1
mov bx, lx1
add bx, wx

.if ax <= 0
mov ax, speedx
neg ax
mov speedx, ax
.elseif bx >= 319
mov ax, speedx
neg ax
mov speedx, ax
.endif

mov bx, ly1
add bx, hy
mov ax, ly1
sub ax, hy
.if ax <= 0
mov ax, speedy
neg ax
mov speedy, ax
.elseif bx >= 199
mov ax, speedy
neg ax
mov speedy, ax
.endif

xor ax, ax
mov ah, 1 ; wait for key press
int 16h
cmp al, 32
jz EndBounceLoop



jmp BounceLoop

EndBounceLoop:


VRetrace proc

mov dx, 03dah

Wait1:
in al, dx
test al, 08h
jnz Wait1

Wait2:
in al, dx
test al, 08h
jz Wait2
ret

VRetrace endp

   

[NoCforMe]

Kinda hard to tell what's going on there with variables with (unexplained) names like "lyl" and "hy". Few comments, pleeze?

[sinsi]

Signed comparisons need a different syntax

Code Select Expand

.if (sword ptr ax) <= 0


[tda0626]

Kinda hard to tell what's going on there with variables with (unexplained) names like "lyl" and "hy". Few comments, pleeze?

Sorry about that. I kind of jumped the gun there.

Code Select Expand

mov lx1, 0 ; starting coordinates for square
mov ly1, 99

mov wx, 15 ; width and height definitions for square
mov hy, 15

mov speedx, 2 ; Speed values in the x and y plane
mov speedy, 4

BounceLoop:


invoke DrawSR, lx1,ly1, wx, hy, 028h, 1     ; Draw square or rectangle
invoke VRetrace      ; wait for vertical retrace
invoke DrawSR, lx1, ly1, wx, hy, 0, 1     ; clear last drawed squared

mov ax, speedy
add ly1, ax ; add speed to our y coordinate to update position

mov ax, speedx
add lx1, ax ; same but with x


mov ax, lx1
mov bx, lx1 ; had to take wx into considertion
add bx, wx ; square was drawing off screen until it reached lx1

.if (sword ptr ax) <= 0 ; our we on the left boundary?
mov ax, speedx
neg ax ; if so negate speedx so we bounce off at same angle
mov speedx, ax
.elseif bx >= 319
mov ax, speedx ; right boundary?
neg ax ; same as above
mov speedx, ax
.endif

mov bx, ly1 ; same as with x above drawing off screen
add bx, hy
mov ax, ly1

.if (sword ptr ax)  <= 0       ; top boundary?
mov ax, speedy
neg ax
mov speedy, ax
.elseif bx >= 199 ; bottom boundary
mov ax, speedy
neg ax
mov speedy, ax
.endif

xor ax, ax
mov ah, 1 ; check for spacebar to exit
int 16h
cmp al, 32
jz EndBounceLoop



jmp BounceLoop

EndBounceLoop:
VRetrace proc

mov dx, 03dah

Wait1: ;check to see if we are in middle of retrace
in al, dx
test al, 08h
jnz Wait1

Wait2: ; start on beginning of retrace
in al, dx
test al, 08h
jz Wait2
ret

VRetrace endp



Signed comparisons need a different syntax

Code Select Expand

.if (sword ptr ax) <= 0


That is helpful. I did not know that. Learned something new...

[daydreamer]

I have similar code in windows 32 bit drawing icons ,guess you replace it with sprite drawing,I discovered that you can simple shorten code to
Neg speedy
Neg speedx

[tda0626]

I have similar code in windows 32 bit drawing icons ,guess you replace it with sprite drawing,I discovered that you can simple shorten code to
Neg speedy
Neg speedx

Thanks. Little things like that make a difference.


I think the issue might have to do with how I erase the previous square. Maybe I just need to clear the screen during V Retrace reset. Will have to give that a go when I get home tonight.

[tda0626]

Yea didn't work.

Reading up on the subject, to get a smooth moving object, it looks like the only way is to go unchained mode on 320 x 200 or mode X 320 x 240 and do page flipping.

[_japheth]

Reading up on the subject, to get a smooth moving object, it looks like the only way is to go unchained mode on 320 x 200 or mode X 320 x 240 and do page flipping.

Not necessarily. However, you shouldn't render your items directly in video memory. A better approach is to render the screen contents in a memory buffer , wait for vertical retrace and finally do a quick copy from your buffer to video memory.

Also, to draw a square by using line drawing code isn't very fast, btw.

Attached your modified sample, using a buffer.

[daydreamer]

I agree with japhet 
But like to add, drawing or loading in initialize program sprite map in memory for moving objects simple to copy to screen
More advanced tiles for background objects combined with sprites if any sprites in front of tile before copying
Only need to update the tiles and sprites that changes on screen

[tda0626]

Not necessarily. However, you shouldn't render your items directly in video memory. A better approach is to render the screen contents in a memory buffer , wait for vertical retrace and finally do a quick copy from your buffer to video memory.

Also, to draw a square by using line drawing code isn't very fast, btw.

Attached your modified sample, using a buffer.

Thank you. Is the technique you are describing called double buffering?

When you allocate memory with DOS function AH=48, you specify the number of pages of memory needed as 1000h. Why did you specify that and not 4000 decimal, which is 64k/16?

Tim

[tda0626]

I agree with japhet 
But like to add, drawing or loading in initialize program sprite map in memory for moving objects simple to copy to screen
More advanced tiles for background objects combined with sprites if any sprites in front of tile before copying
Only need to update the tiles and sprites that changes on screen

Do you have a good resource that you can point me to about sprite manipulation?

Tim

[NoCforMe]

When you allocate memory with DOS function AH=48, you specify the number of pages of memory needed as 1000h. Why did you specify that and not 4000 decimal, which is 64k/16?

1000h = 4096 decimal, which is "4K"
64K (65,536) / 16 = 4096, not 4000

We like to use hex numbers here.

[FORTRANS]

Hi,

Do you have a good resource that you can point me to about sprite manipulation?

   If you were following my comments in another thread about Wu
antialiased lines, there was an animation in a chapter of the
book I pointed out.

Code Select Expand

Abrash's Graphic Programming Black Book

;LISTING 43.1 L43-1.ASM
; Program to demonstrate bit-plane animation. Performs
; flicker-free animation with image transparency and
; image precedence across four distinct planes, with
; 13 32x32 images kept in motion at once.
; Bit-Plane Animation 801
; Set to higher values to slow down on faster computers.
; 0 is fine for a PC. 500 is a reasonable setting for an AT.
; Slowing animation further allows a good look at
; transparency and the lack of flicker and color effects
; when images cross.

Regards,

Steve N.

[tda0626]

When you allocate memory with DOS function AH=48, you specify the number of pages of memory needed as 1000h. Why did you specify that and not 4000 decimal, which is 64k/16?

1000h = 4096 decimal, which is "4K"
64K (65,536) / 16 = 4096, not 4000

We like to use hex numbers here.

But 320x200x1 byte is 64000 bytes /16 page = 4000 or am I missing something here?

Hi,

Do you have a good resource that you can point me to about sprite manipulation?

   If you were following my comments in another thread about Wu
antialiased lines, there was an animation in a chapter of the
book I pointed out.

Code Select Expand

Abrash's Graphic Programming Black Book

;LISTING 43.1 L43-1.ASM
; Program to demonstrate bit-plane animation. Performs
; flicker-free animation with image transparency and
; image precedence across four distinct planes, with
; 13 32x32 images kept in motion at once.
; Bit-Plane Animation 801
; Set to higher values to slow down on faster computers.
; 0 is fine for a PC. 500 is a reasonable setting for an AT.
; Slowing animation further allows a good look at
; transparency and the lack of flicker and color effects
; when images cross.

Regards,

Steve N.

Thanks, Steve. I will have to read that book.

Tim

[NoCforMe]

Thanks, Steve. I will have to read that book.

Here's the link to that chapter (Bit-Plane Animation).