Jump to content

SeaGtGruff's Photo

SeaGtGruff

Member Since 7 Aug 2005
OFFLINE Last Active Yesterday, 8:09 PM

Posts I've Made

In Topic: Wall/Object Collision and Multiple Screen Help

Wed May 15, 2013 11:06 AM

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

Is there a batari Basic thread earlier than the one below from July 7, 2005?
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! :skull: 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.

In Topic: Randomizing and "Shot" Questions

Wed May 15, 2013 10:57 AM

View PostArcade, on Wed May 15, 2013 9:08 AM, said:

The sprite starts as a random color (which I got down and it will do everytime I start up Stella). But now I'm trying to test the fact, how can I go one step further and every time I press up on the joystick, then I can recall the randomness and change the color of the sprite? I tested setting it as white in the main, but it stays white no matter what. So if I set it to a random color in the main then it will show. If I don't even set it in the main obviously it doesn't appear UNTIL I press up...but it's always that one random color.

How to make it start off as a random color...then press up and it will change...press up again and it changes again? Is this where I need to set it to temp1 instead of f then? (As far as rand). Sorry if I'm babbling or confusing...I'm just getting aggrevated!
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.

In Topic: Randomizing and "Shot" Questions

Tue May 14, 2013 10:56 PM

View PostArcade, on Tue May 14, 2013 4:35 PM, said:

Also another quick question...let's say for instance your character will move normally. Then, by pressing the fire button, your character does something else instead of move (say for instance he fires in all 4 directions). How would you go about coding it to where you can switch out between moving and shooting? I can make my character move, then when I press the fire button he won't move, but instead fire in all 4 directions. However, when I press the fire button again, he won't start moving (thus cancelling out the shooting). I've tried numerous things, but the only thing I can come up with is having to hold the fire button down. I don't want to hold it down, just press the fire button to switch out between the two commands.
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.

In Topic: fun with tables

Tue May 14, 2013 10:20 PM

View Postbogax, on Tue May 14, 2013 12:26 PM, said:

here I've molested SeaGtGruff's code
Molest away! :thumbsup:

In Topic: Wall/Object Collision and Multiple Screen Help

Mon May 13, 2013 11:12 PM

View Postbogax, on Mon May 13, 2013 6:59 PM, said:

SeaGtGruff's move_around_rooms is similar
except he goes to a subroutine for each
direction that does the table look up for
that direction then uses the room to
look up a room shape (and a room color)
then uses a bunch of if statements instead
of on goto (and why in the world.. ;P )
to select the correct room shape drawing
code for the room. (so different rooms
can have same shapes with different colors)
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. :)