Jump to content

Photo

Bug in pfhline, pfvline, and pfpixel


5 replies to this topic

#1 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Tue Aug 9, 2005 8:20 PM

There's a problem with the pfhline, pfvline, and pfpixel commands, sometimes they change too many pixels. For example, consider the following code:

  COLUBK=$08:COLUPF=$44
  pfhline 0 0 31 on
  pfvline 31 0 3 on
  pfvline 31 7 10 on
  pfvline 0 0 10 on
  pfhline 0 10 31 on
loop
  drawscreen
  goto loop

What it *should* do is draw a border around the screen, but with a gap on the right side-- in other words, draw a room with an exit going "east." But what it actually does is fill the screen (or playfield, anyway) with solid red.

Or try this:

  COLUBK=$08:COLUPF=$44
  pfhline 0 0 31 on
  pfvline 31 0 10 on
  pfvline 0 0 10 on
  pfhline 0 10 31 on
  pfvline 31 4 6 off
loop
  drawscreen
  goto loop

It should draw a border or wall around the screen, then erase part of the east wall to make an exit. But instead, it erases the entire bottom right corner. I haven't tried to unravel the compiled assembly code to see what's going on.

Here's another one, using pfpixel:

  COLUBK=$08:COLUPF=$44
  pfhline 0 0 31 on
  pfvline 31 0 10 on
  pfvline 0 0 10 on
  pfhline 0 10 31 on
  for a=13 to 18:pfpixel a 0 off:next
loop
  drawscreen
  goto loop

Again, we're trying to draw a wall around the room, and then add an exit-- this time, in the north wall. But the pfpixel command in the for..next loop erases too much, and leaves a couple of pixels unerased.

Oddly enough, if we change the "off" to "flip" in the last example, it works as it's supposed to:

  COLUBK=$08:COLUPF=$44
  pfhline 0 0 31 on
  pfvline 31 0 10 on
  pfvline 0 0 10 on
  pfhline 0 10 31 on
  for a=13 to 18:pfpixel a 0 flip:next
loop
  drawscreen
  goto loop

Michael Rideout

#2 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Tue Aug 9, 2005 11:50 PM

There's a problem with the pfhline, pfvline, and pfpixel commands, sometimes they change too many pixels. For example, consider the following code:
Michael Rideout

View Post

I did discover a bug in the above commands when I was rewriting these commands to allow indexed variables. I expect that these commands will work properly for the upcoming Alpha 0.3 release, which should be soon, I hope!

#3 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • Topic Starter
  • 5,566 posts
  • Location:South Carolina, USA

Posted Wed Aug 10, 2005 2:12 AM

There's a problem with the pfhline, pfvline, and pfpixel commands, sometimes they change too many pixels. For example, consider the following code:
Michael Rideout

View Post

I did discover a bug in the above commands when I was rewriting these commands to allow indexed variables. I expect that these commands will work properly for the upcoming Alpha 0.3 release, which should be soon, I hope!

View Post


I expect there will be quite a few bugs that need to be fixed in the early releases of Batari BASIC, and I hope you don't get discouraged about it, because I think Batari BASIC is a fantastic tool that puts Atari 2600 programming within the reach of just about everyone!

I don't want to deluge you with bug reports, but there's another bug I noticed last night which I didn't mention yet. Namely, when using GOSUBs, the program may not compile correctly.

For example:

loop
  if a=1 then gosub routine1
  goto loop
routine1 b=4:return
routine2 b=3:return

This gives a message "return without gosub," but it compiles anyway, so I guess it's just a warning message, rather than an error?

But here's another example:

loop
  if a=1 then gosub routine1
  if a=2 then gosub routine1
  if a=3 then gosub routine1
  if a=4 then gosub routine1
  if a=5 then gosub routine1
  goto loop
routine1 b=4:return

This gives a message "Max. nested gosubs exceeded," and results in a fatal error, even though the program should be RETURNing each time, such that there actually aren't any nested GOSUBs.

Another thing I noticed is that COLUBK and COLUPF can be set outside of the main loop (such as when those colors will be constant throughout the program), but if you set COLUP0 or COLUP1 outside of the loop, the players will be black; you must set COLUP0 and COLUP1 within the loop, even if they're never going to change, or else the players won't be set to the desired colors (or else they're getting reset to black each time DRAWSCREEN finishes executing; I haven't checked the compiled code to see what's happening).

Michael Rideout

#4 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,866 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Aug 10, 2005 2:21 AM

This gives a message "Max. nested gosubs exceeded," and results in a fatal error, even though the program should be RETURNing each time, such that there actually aren't any nested GOSUBs.

View Post

I had a similar problem. I thought it was something I did wrong. I think I got that with only three gosubs inside of if-thens. Might have been 4 though. If that gets fixed in the next version, that will be cool because I planned to use a fair amount of gosubs.

Edited by Random Terrain, Wed Aug 10, 2005 2:29 AM.


#5 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Wed Aug 10, 2005 2:39 AM

This gives a message "return without gosub," but it compiles anyway, so I guess it's just a warning message, rather than an error?
...
This gives a message "Max. nested gosubs exceeded," and results in a fatal error, even though the program should be RETURNing each time, such that there actually aren't any nested GOSUBs.

I'm aware of these bugs too. I appreciate the bug reports - Please keep reporting them, as it helps me make bB better, as I don't have time to exhaustively test everything myself.

Another thing I noticed is that COLUBK and COLUPF can be set outside of the main loop (such as when those colors will be constant throughout the program), but if you set COLUP0 or COLUP1 outside of the loop, the players will be black; you must set COLUP0 and COLUP1 within the loop, even if they're never going to change, or else the players won't be set to the desired colors (or else they're getting reset to black each time DRAWSCREEN finishes executing; I haven't checked the compiled code to see what's happening).

Michael Rideout

View Post

This is true - COLUP0 and COLUP1 must be set in the main loop, while COLUBK and COLUPF can be set before. Simply said, some registers are persistent in bB. and some are not. I need to make a list at some point so you know what you do and don't need to set in the main loop.

#6 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,866 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Aug 10, 2005 2:43 AM

I need to make a list at some point so you know what you do and don't need to set in the main loop.

View Post

That would be good to know.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users