Jump to content

Photo

Really strange bug in my program.


4 replies to this topic

#1 Pantomchap OFFLINE  

Pantomchap

    Space Invader

  • 16 posts

Posted Fri May 26, 2017 12:09 AM

So what it's supposed to do is move the player0 sprite when the player 0 fire button is pressed. However, it only works if I make it stop the player0 sprite when the button is pressed.

 

Go to line 84 which says lda #%01111111 and turn it into lda #%10000000. It messes up the program completely somehow.

 

 

I'm sorry for the horrible description of the bug. I'll post a much better explanation of the bug in the morning.

Attached Files



#2 Pantomchap OFFLINE  

Pantomchap

    Space Invader

  • Topic Starter
  • 16 posts

Posted Fri May 26, 2017 9:09 AM

Alright, good morning. So basically in the last two scanlines of the overscan, my program runs this:

checkfire:
	sta WSYNC
	lda #%01000010
	sta VBLANK
	lda #%01111111
	eor INPT4
	bmi fireisnotchecked
	sta WSYNC
	rts
fireisnotchecked:
	sta WSYNC
	ldy $80
	iny
	sty $80
	rts

What I was trying to do is make it so that the p0 sprite moves down when the fire button is pressed by player 0. This part of the code is what loads and stores the new Y position of the p0 sprite whenever the fire button is pressed.

 

 

However, it only works if I check if INPT4 is not held down. If I reverse

	lda #%01111111

to

	lda #%10000000

The program goes haywire and Stella tells me that the framerate is ranging from 300-400 FPS. When I debug with Stella the VBLANK area seems to start somewhere in the middle of where the program would be drawing the visible picture. How is it that this is causing such a massive problem?

 

 

 

 

Also, obviously I could have used 

bit INPT4

instead of

lda #%01111111
eor INPT4

but I was trying to find if that one would work.



#3 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Fri May 26, 2017 9:30 AM

I'd say that what is happening is that your $80 value is rapidly incremented' (there is no top limit) over multiple frames, and it gets to a large value (say 200+).  Then, your loop to draw the sprite within the 192 line area is failing because the loop is based on the Y value, not the X value.  In other words, it draws (say) 200+ scanlines and by that time x has decremented past zero too and it's now (say) 200 as well for the latter part of the screen draw after the sprite, and so that loop (unused lines) will ALSO draw another 200+ scanlines. So I'd say that's what's probably going wrong. :)



#4 Pantomchap OFFLINE  

Pantomchap

    Space Invader

  • Topic Starter
  • 16 posts

Posted Fri May 26, 2017 7:19 PM

I'd say that what is happening is that your $80 value is rapidly incremented' (there is no top limit) over multiple frames, and it gets to a large value (say 200+).  Then, your loop to draw the sprite within the 192 line area is failing because the loop is based on the Y value, not the X value.  In other words, it draws (say) 200+ scanlines and by that time x has decremented past zero too and it's now (say) 200 as well for the latter part of the screen draw after the sprite, and so that loop (unused lines) will ALSO draw another 200+ scanlines. So I'd say that's what's probably going wrong. :)

 

I found out the problem after reading this. Apparently the loop to draw the sprite cannot handle if the y position is 0 which caused the program to go haywire. So now it doesn't go under 1.



#5 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sat May 27, 2017 1:36 AM

Your analasis is, I am pretty sure, wrong.  Yes, when it's 0 it will do what you say.  It will ALSO fail when Y is (say) 255.  Because it will loop 255 times (instead of 256 when it's 0).  When Y is 200, it will loop 200 times.  The error is in the code at 'fireisnotchecked' where $80 is incremented without a check on the upper bound.  It can go right up to 200... 250... and then to 0.   You asked for an analysis; I gave it. Pay close attention to what I've pointed out is the problem, because unless I'm badly misunderstanding what your code is doing, then the same problem is going to come back and bite you.  You appear to have fixed the symptom, not the problem.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users