Using Superchip Variables/ Substitutions for Rand...

[KevKelley]

I have been playing around with Superchip stuff and experimenting with the extra variables. I had noticed some of the quirkiness of how they can be used and I had kind of used them for counters and holding values of things and I was wondering if there is a way to use them with movement, like P0x = player0x.r001. 

 

When I tested it I couldn't get it to work but was wondering if there was a way? 

 

 

Edited February 6, 2022 by KevKelley
Title change to better reflect discussion.

[+Random Terrain]

Check out the warning:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#warningsuperchipram

[KevKelley]

45 minutes ago, Random Terrain said:

Check out the warning:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#warningsuperchipram

I remember reading that warning. I did forget a couple of the points. I assume there is no workaround or that it is just not feasible due to how it works. 

 

Thanks!

[+Gemintronic]

R.T. also has some fixed point variable examples that move the player around:

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#fixedpoint

 

In general I avoid the problem of sub pixel movement by calling the input event routines less often in the main loop using a counter variable that increments at the start.

 

This pseudo example processes movement every other main loop run so about half a pixel effectively.

The first bit of counter toggles between 0 and 1 depending on the frame.  Assuming drawscreen is called once in the main loop.
 

main

 counter = counter + 1

 if counter{0} then goto inputevent else goto after_inputevent

 

[KevKelley]

3 hours ago, Gemintronic said:

R.T. also has some fixed point variable examples that move the player around:

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#fixedpoint

 

In general I avoid the problem of sub pixel movement by calling the input event routines less often in the main loop using a counter variable that increments at the start.

 

This pseudo example processes movement every other main loop run so about half a pixel effectively.

The first bit of counter toggles between 0 and 1 depending on the frame.  Assuming drawscreen is called once in the main loop.
 

main

 counter = counter + 1

 if counter{0} then goto inputevent else goto after_inputevent

 

I had done some things like that, like "if p{0} then..." or "if p{1} then..." 

 

I generally was using them for counters or things I can assign values to which greatly frees up regular variables but I was wondering if there were any tricks to use them in different ways. I did forget the warning on RT's page. I did remember there were some limitations but I forgot all the dos and don'ts. 

[+Gemintronic]

I use and abuse the counter variable so often I forgot all the possibilities

 

If you're running low on cycles sometimes substituting a counter variable instead of rand can cut some cpu time.

 

Also, if you want something to happen every 8 main loops then you cold do "if counter&7 = 0"

 

In contrast you could have something skip every 8th main loop by "if counter&7 > 0 then goto dosomething"

 

Bitwise, SuperChip and Nybble variables all have their complications and math operation gotchas.  About the only way I know of to squeeze more normal variables is to reduce the playfield resolution to free up vars from the standard kernel.

[KevKelley]

7 hours ago, Gemintronic said:

"if counter&7 > 0 then goto dosomething

Ooh. This is something I wasn't thinking about but definitely need. In the thing I was working on I randomize a door, obstacle, and type of obstacle. It definitely causes a scan line issue for just that single moment. I had tried to break it up by a frame or so, but I could t quite get my code right but this seems a better solution.

 

So how exactly would I use the counter vs rand in something like I have 15 different choices? Or 7? I am a little confused by the application.

 

I understand rand, so if I do "x=Rand&15" then I would do "if x= whatevernumber then..."

 

So would this act the same or would I have to give ranges?

 

Part of me was considering tying a location to something that is continually moving to avoid too many rand useages.

Edited February 6, 2022 by KevKelley

[KevKelley]

14 hours ago, Gemintronic said:

I use and abuse the counter variable so often I forgot all the possibilities

So I was playing around with this.  

 

So I replaced this part in my code:

o=(rand16&15) + 1

with this:

o=(w&15) + 1

where w is my counter variable.

 

Seemingly the spawning of all my locations seemed to work.  I didn't test it for too long but the randomization of door locations seemed to work.

 

Would that be all I needed to do?

 

And if so this is a lifesaver and may just be what I need to finish some other projects, as when I substituted the rand for this the scanline issue I had disappeared.

[+Gemintronic]

Sometimes I've made a myrand variable that stores the output of rand for that main loop

 

main

 counter = counter + 1

 myrand = rand

 

That way I call rand just once in the main loop and use variations for different rand results

 

if (counter+myrand) > 45 then goto createbobo

 

if (myrand+myrand) < 25 then goto openchest

 

if myrand&15 = 12 then missilex = 75

 

if myrand{5} then timer = timer - 1

 

 

[KevKelley]

9 minutes ago, Gemintronic said:

Sometimes I've made a myrand variable that stores the output of rand for that main loop

 

main

 counter = counter + 1

 myrand = rand

 

That way I call rand just once in the main loop and use variations for different rand results

 

if (counter+myrand) > 45 then goto createbobo

 

if (myrand+myrand) < 25 then goto openchest

 

if myrand&15 = 12 then missilex = 75

 

if myrand{5} then timer = timer - 1

 

 

These are all great tips! 

 

I am still a little confused about using the counter instead of Rand. Does it pretty much act the same or is there any other check I need to do to make it work essentially the same as a rand?

 

From what I can tell it seemed to work alright. I usually will take the code and put it in the loop so I can watch a super fast distribution of where the things appear. I just wonder if there is a downside to this method? 

[+Gemintronic]

I mean, using a counter variable you're fighting with its regularity.  Every 255 loops it's always gonna give you 46,  The player is eventually going to notice certain patterns that are going to emerge from counting up from 0 to 255,   If you tie it to the inherent randomness of user actions it can help.  Say, if (player0x+counter) > 128 then goto dosomething

[KevKelley]

48 minutes ago, Gemintronic said:

I mean, using a counter variable you're fighting with its regularity.  Every 255 loops it's always gonna give you 46,  The player is eventually going to notice certain patterns that are going to emerge from counting up from 0 to 255,   If you tie it to the inherent randomness of user actions it can help.  Say, if (player0x+counter) > 128 then goto dosomething

So is it possible to do other things instead of a counter? Like let's say player just goes left to right. So I could do something like o=player4x&15?

Edited February 7, 2022 by KevKelley

[KevKelley]

I guess what makes this a little more difficult for me to fully understand is that Rand seems like a very simple concept. Here is a random number in such and such range. But I see some great benefits to your advice. Even my test yielded no scan line issues and that was one of my hangups in some other games I was stuck on. 

[+Gemintronic]

Oh, yeah.  Doing weird things like this is a kludge to shave off some CPU cycles if you're going slightly over

 

I'm always tinkering with side scrolling and  soft collision for many sprites so I made a habit of using rand sparingly.

[KevKelley]

46 minutes ago, Gemintronic said:

Oh, yeah.  Doing weird things like this is a kludge to shave off some CPU cycles if you're going slightly over

 

I'm always tinkering with side scrolling and  soft collision for many sprites so I made a habit of using rand sparingly.

You might have just saved me. I'm thinking to my issues in Crossdock. I could save not only cycles but space with how I generate the boxes if I do your myrand trick. 

[+Karl G]

16 hours ago, KevKelley said:

I guess what makes this a little more difficult for me to fully understand is that Rand seems like a very simple concept. Here is a random number in such and such range. But I see some great benefits to your advice. Even my test yielded no scan line issues and that was one of my hangups in some other games I was stuck on. 

The reason the frame counter instead of rand sometimes works is because of how quickly the number changes. It cycles through all 256 possible values in a few seconds, so if you don't poll it that often, the value seems somewhat random, and the value obtained can be in the range of 0-255, just like rand. If you check too often, the patterns will become obvious, though.

 

Still, calls to rand shouldn't take too much time, usually. If you haven't already, I'd suggest placing "set optimization inlinerand" at the beginning of your program. That decreases the time it takes to produce a random number at the cost of increased code size when you use it. The difference in cycles is most obvious in bankswitched games.