Random Terrain, on Wed May 15, 2013 8:48 AM, said:

I couldn't remember if version 0.1 was released in 2005 or 2004, or maybe even before 2004-- and I was too tired at the time to go look it up! I do remember that the first four versions (0.1, 0.2, 0.3, and 0.35) were released pretty close to each other, then there was a "pause" before 0.99 was released.

Anyway, I was thinking that "on-goto" might not have been added to batari Basic yet when I wrote that "move_around_rooms.bas" example.

Arcade, on Wed May 15, 2013 9:08 AM, said:

Well, unless you're using a multi-sprite kernel and are using the player that gets multiplexed, you'll need to set the player's color in the loop sometime before you call drawscreen (since COLUP0 and COLUP1 get wiped out at the end of drawscreen when the score is displayed). So "all" you need to do to test the random colors is to check the joystick just before you set the player's color and-- if the joystick is pressed up-- randomize the color again before you set it.

Arcade, on Tue May 14, 2013 4:35 PM, said:

It sounds like you got the color issue figured out, and I'm not experienced with DPC+ yet, so I'll tackle the movement question.

From your description of what you want to achieve, I'd suggest defining a flag for indicating whether the player is moving or is stationary/shooting. It doesn't need to be an entire variable (byte)-- just a single bit. Random Terrain's bB web page should have lots of examples of dividing a byte into multiple bit variables or flags.

Now, supposing that you have plenty of variables free, the simplest way to do this would be to use an entire byte for the flag, then use the exclusive-or (the ^ operator) to flip the flag when the button is pressed, something like this:

   dim flag = a

   flag = 0 : rem initialize the flag to "off"

loop

   if joy0fire then flag = flag ^ 1 : rem this flips the flag on if it's off, or off if it's on

   if flag = 0 then gosub player_is_moving
   if flag = 1 then gosub player_is_firing

   goto loop

This is obviously an incomplete example, but hopefully you can get the idea of what I mean.

The tricky part, though, will be reading the fire button, because you'll need to "debounce" it-- which I didn't do in the above example. Debouncing a console switch (like game reset or game select) or a fire button or a game controller refers to processing its state in a way that prevents it from being "read" too many times in a row, or too quickly. For example, in the code above it's possible that pressing the fire button will rapidly flip the flag on and off and on and off many times as the program loops, because the computer/2600 operates so much faster than you do-- so even if you try to tap the button very quickly, it may seem to the 2600 as though you're holding the button down for a really long time. There are examples of debouncing the fire button in older posts, and Random Terrain also has examples on his bB web page.

bogax, on Tue May 14, 2013 12:26 PM, said:

Molest away!

bogax, on Mon May 13, 2013 6:59 PM, said:

Well, it was written about 6.5 years ago, so I don't really remember why in the world I did it that way. I'm not sure when on-goto was added to batari Basic, but I don't think the no_blank_lines option was available yet, otherwise I'm pretty sure I would have used it in that example. On Random Terrain's page it says "The original beta version [of batari Basic] was released in 2005. Version 1.0 was released in 2007." I thought the first versions of batari Basic were released before 2005, but if I remember correctly Fred considered the 0.99 release to be the first true "beta" release, so maybe that's what 2005 is referring to?

Anyway, my example was just a quickie demo to suggest what *could* be done, not anything I spent a lot of time trying to optimize, and I hadn't meant it to be an example of how something *should* be done. I only mentioned it because using a separate array for each direction allows up to 256 rooms. To break the 256-room barrier you could use sdata statements, or split the game into multiple "lands" and have separate sets of data statements for each land, allowing up to 256 rooms in each land, etc.

But yeah-- if I were doing it today, I'd do it differently than how I did it back in 2006.