Jump to content
IGNORED

Bug in pfhline, pfvline, and pfpixel


SeaGtGruff

Recommended Posts

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

Link to comment
Share on other sites

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

908044[/snapback]

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!

Link to comment
Share on other sites

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

908044[/snapback]

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!

908139[/snapback]

 

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

Link to comment
Share on other sites

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.

908163[/snapback]

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
Link to comment
Share on other sites

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

908163[/snapback]

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...