SeaGtGruff Posted August 10, 2005 Share Posted August 10, 2005 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 Quote Link to comment Share on other sites More sharing options...
+batari Posted August 10, 2005 Share Posted August 10, 2005 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! Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 10, 2005 Author Share Posted August 10, 2005 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 10, 2005 Share Posted August 10, 2005 (edited) 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 August 10, 2005 by Random Terrain Quote Link to comment Share on other sites More sharing options...
+batari Posted August 10, 2005 Share Posted August 10, 2005 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 10, 2005 Share Posted August 10, 2005 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.908170[/snapback] That would be good to know. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.