HUGE Request!

[MausBoy]

First let me say this version of BASIC is fantastic and much more than I had hoped for when I first heard about it. It's almost exactly what I needed to be able to put together the few 2600 game ideas I've had bouncing around in my head for a while. My main problem in using it is the variable thing though.

When I was a kid, my NES was for playing alone for hours on end, and the 2600 was for 2 player battles with friends. So when I'm programming 1 player games now, I still think in terms of that NES style gameplay. Lots of wierd features and things that are just there to be there, like sprite shadows, cut scenes, sprite animations, and most importantly a variety of powerups and enemies.

All of these types of things can easily be implemented in this BASIC, it lets you add any element like this you can think up, in just a few minutes! The problem is, adding any one thing requires at least one variable, so the depth of game play and game logic is ALWAYS limited by the # of variables available.

So I can create games that use a few of these elements and possibly have a great 2600 style game, but I'm not that creative and chances are it'll be a game that's already been done at least once for the system. But if I could combine many of these elements I would be much more likely to create something that this system hasn't seen yet.

 

If you could just add a few new variables it would help a lot. I suggest maybe built in "p0x" / "p1x" and "p0y" / "p1y" variables to use for the player locations. That would free up four a-z variables for game logic! You could also add "co1" and "co2" variables for counters (used as co1 = co1 + 1, etc) and free up two more. I know if I had six more, it would completely change the kind of games I could make.

 

I also have a question: How do I use SCORE? I tried making SCORE = 1000 then counting down to zero, when zero is reached the level increases. But a "if score = 0 then" never branches and the score goes into negative numbers. What am I doing wrong?

[s0c7]

I also have a question: How do I use SCORE? I tried making SCORE = 1000 then counting down to zero, when zero is reached the level increases. But a "if score = 0 then" never branches and the score goes into negative numbers. What am I doing wrong?

 

http://www.atariage.com/forums/index.php?s...ndpost&p=894637

[+batari]

If you could just add a few new variables it would help a lot. I suggest maybe built in "p0x" / "p1x" and "p0y" / "p1y" variables to use for the player locations. That would free up four a-z variables for game logic! You could also add "co1" and "co2" variables for counters (used as co1 = co1 + 1, etc) and free up two more. I know if I had six more, it would completely change the kind of games I could make.

Well, some of what you are asking for is already there, but not documented very well. While it is true that some built-in variables do not retain their values after you call drawscreen (temp1-temp6, most notably), and most of the TIA regs don't either (e.g.: COLUP0, COLUP1, NUSIZ0, NUSIZ1.) However, the built-in variables player0x, player0y, player1x, player1y, missile0x, missile1x, missile0y, missile1y, ballx, bally, scorecolor, and others hold their values, so there's several more right there that you can use. I've been meaning to make a list of which variables are persistent and which are not.

 

Another way to help is to convert calculations requiring numerous variables to data tables instead. It's kind of an art to do this, but it not only saves RAM, but cycles too.

[MausBoy]

Well, some of what you are asking for is already there, but not documented very well. While it is true that some built-in variables do not retain their values after you call drawscreen (temp1-temp6, most notably), and most of the TIA regs don't either (e.g.: COLUP0, COLUP1, NUSIZ0, NUSIZ1.) However, the built-in variables player0x, player0y, player1x, player1y, missile0x, missile1x, missile0y, missile1y, ballx, bally, scorecolor, and others hold their values, so there's several more right there that you can use. I've been meaning to make a list of which variables are persistent and which are not.

 

Another way to help is to convert calculations requiring numerous variables to data tables instead. It's kind of an art to do this, but it not only saves RAM, but cycles too.

 

Thanks for the suggestions and help Batari! Unfortunately I have yet to come up with a game concept that dosn't use all of the built in variables for their original intended use, but if I do I can keep that in mind. Doing things like flickering the ball to use as both missiles (to free them up as variables) won't work for me because I'm all about the frills, like animating the missiles and them not being the same color as the playfield.

 

As far as data tables, the way I use variables isn't so much for detailed calculations as to hold information. So whether I'm assigning that data directly to a variable or reading from a data table, its not gonna save me anything except main loop space. Am I missing what you are saying? What I mean is that a line that loads a value into X depending on the value of Y with IF THEN dosn't beat a DATA read. The value change is still depending on the variable Y either way. It only saves space (a FOR NEXT loop vs a ton of IF THENs)

 

If you could please explain further, and if there are any other ways around the variable limit I'm all ears. I rarely use ON OFF flags so stuff like a(3) dosn't help me much.

 

Can you use that to pump up your variable limit by using multiple bit flags ( if a(1) && a(2) && a(3) then etc) ? I mean can you assign 0 or 1 to each bit?

 

example:

 

a(1) = 0 : a(2) = 0 : a(3) = 0

if k = 1 then a(3) = 1

if k = 2 then a(1) = 1 : a(2) = 1 : a(3) = 0

if k = 3 then a(1) = 1 : a(2) = 1 : a(3) = 1

if a(1) && a(2) && a(3) then goto 20

if a(1) && a(2) then goto 30

if a(1) then goto 40 else goto 50

 

 

So then I could use some bits as one variable and some as another. I can try doing that with some stuff, but sounds like a major headache!

 

 

Is there ANY way at all you could squeeze a couple more in there for us, like my co1 & co2 idea? I really only need a few more! I have yet to create a game without running out. For example, creating a shooter then running out of variables when you get to the enemies renders the game useless. Then it's either cut stuff out or start over. Granted, I only downloaded bB a week ago, but still. Squeezing games into a rather tiny rom can be fun, squeezing them into a limited number of variables definately is not. I obviously also need to be putting more thought and planning into games, but if the variable limit takes an awesome new idea and turns it into the same old crap why bother.

[+batari]

If you could please explain further, and if there are any other ways around the variable limit I'm all ears. I rarely use ON OFF flags so stuff like a(3) dosn't help me much.

 

Can you use that to pump up your variable limit by using multiple bit flags ( if a(1) && a(2) && a(3) then etc) ? I mean can you assign 0 or 1 to each bit?

 

example:

 

a(1) = 0 : a(2) = 0 : a(3) = 0

if k = 1 then a(3) = 1

if k = 2 then a(1) = 1 : a(2) = 1 : a(3) = 0

if k = 3 then a(1) = 1 : a(2) = 1 : a(3) = 1

if a(1) && a(2) && a(3) then goto 20

if a(1) && a(2) then goto 30

if a(1) then goto 40 else goto 50

 

 

So then I could use some bits as one variable and some as another. I can try doing that with some stuff, but sounds like a major headache!

The best way to use parts of variables is to use masking. It is easier than and less of a headache than the above example, but it's not as good as a full variable.

 

For example, suppose you have two values that can only be 0-15. If so, you can split a single variable in half. Let's say you are using "a" for this.

 

You can "extract" the two halves into temp1 and temp2 by:

temp1=a & %00001111

temp2=a / 16

 

The first one uses a bitwise AND to place zeros in the upper 4 bits ("mask" them out) and retain the lower 4. The second one is a little more subtle, until you consider what is happening in binary: A divide by 16 is the same as shifting the bits right 4 places.

 

Now you can manipulate temp1 and temp2 however you want. Then to recombine them into the single variable, one way is:

 

a=temp2*16 + (temp1 & %00001111)

 

Or, if you are sure that temp1<=15, the expression would become

 

a=temp2*16 + temp1

 

You aren't limited to 4-4 splits, of course, but you'll need to slightly modify the above to handle other cases.

Is there ANY way at all you could squeeze a couple more in there for us, like my co1 & co2 idea? I really only need a few more! I have yet to create a game without running out. For example, creating a shooter then running out of variables when you get to the enemies renders the game useless. Then it's either cut stuff out or start over. Granted, I only downloaded bB a week ago, but still. Squeezing games into a rather tiny rom can be fun, squeezing them into a limited number of variables definately is not. I obviously also need to be putting more thought and planning into games, but if the variable limit takes an awesome new idea and turns it into the same old crap why bother.

Well, every single last byte in the 2600's RAM is currently assigned to something. However, now that I think about it, the way I did the score is a little wasteful. There's a possibility that I might be able to free up 6 variables. I'll look into it for the next release.

 

I'm also looking into a ROM-based playfield option for the standard kernel. You'd lose the playfield drawing commands, but you'd gain 48 variables. May or may not be worth the tradeoff. But as you may be learning, there are few things on the 2600 that don't require a tradeoff of some sort.

[MausBoy]

Thanks for explaining all that. The examples definately helped a lot. I do use a lot of variables for numbers that dont go over 15.

 

It's great to hear about the score change, I think i'll put off some of the bitmasking and finish some of these projects when that release gets here. Yes there are trade-offs, but your compiler makes it pretty easy to preplan what you can and can't do, and see it working (or not) as you go. I definately think people will be making plenty of cart worthy games with bB, especially with each new release. I like the idea of 48 variables too but I would be clueless on how to manipulate the playfield the way I want to without the drawing commands. Does that include pfscroll too?

Edited April 15, 2006 by MausBoy

[+batari]

Thanks for explaining all that. The examples definately helped a lot. I do use a lot of variables for numbers that dont go over 15.

 

It's great to hear about the score change, I think i'll put off some of the bitmasking and finish some of these projects when that release gets here. Yes there are trade-offs, but your compiler makes it pretty easy to preplan what you can and can't do, and see it working (or not) as you go. I definately think people will be making plenty of cart worthy games with bB, especially with each new release. I like the idea of 48 variables too but I would be clueless on how to manipulate the playfield the way I want to without the drawing commands. Does that include pfscroll too?

Basically, you will need to specify the playfield a whole screen at a time. The command for this is pretty simple (the command is available now, actually.) You will also be able to specify an extended screen that can be scrolled, but only up or down.