19 replies to this topic

[Lodmot]

Hi. I'm having the strangest problem with randomization in my new game that I'm working on.

What's going on is, I have single playfield pixels falling from the top of the screen, and when they either hit a missile object or reach the bottom of the screen, they are supposed to appear back up at the top, but at a different randomly-chosen x position between 0 and 31 (because they're playfield objects).

The code I have seems to work fine in Stella, but when I tried it on my real Atari, the playfield pixels never get randomized; they always appear at the left-most X coordinate. Periodically the same thing will happen in Stella as well, but on the console it happens all the time. Is there anyone that may know how to fix this problem?

Thanks.

Attached Files

•  default.bas   16.86K   47 downloads

Edited by Lodmot, Fri Feb 10, 2012 3:23 PM.

[stephena]

Lodmot, on Fri Feb 10, 2012 3:23 PM, said:

Hi. I'm having the strangest problem with randomization in my new game that I'm working on.

What's going on is, I have single playfield pixels falling from the top of the screen, and when they either hit a missile object or reach the bottom of the screen, they are supposed to appear back up at the top, but at a different randomly-chosen x position between 0 and 31 (because they're playfield objects).

The code I have seems to work fine in Stella, but when I tried it on my real Atari, the playfield pixels never get randomized; they always appear at the left-most X coordinate. Periodically the same thing will happen in Stella as well, but on the console it happens all the time. Is there anyone that may know how to fix this problem?

Thanks.

Perhaps it has something to do with zero page RAM being randomized in Stella and not on a real system??  You can turn this on or off in Stella with the 'ramrandom' commandline argument, either from the commandline or by editing the config file (unfortunately there's no way to do this in the UI yet).  If that makes Stella behave like real hardware, then at least you'll know why it's happening.

[GroovyBee]

rem out the "dim rand16=x" line and see if that makes a difference.

[Random Terrain]

I had a similar problem with Seaweed Assault. It seems if you use nothing but & instead of dividing, you can get random numbers that aren't so random. I fixed the problem by dividing when necessary. For example, there was a variable that added three random numbers. I used & for two of them and used division for the third one. That made the problem go away. You have to play around and see where division is needed.

So if a = (rand&15) isn't working correctly, try a = (rand/16). I thought I already added something about this to the bB page, but I can't find it. I just added a warning to the Did You Know? box:

http://www.randomter...mands.html#rand

[Omegamatrix]

Remember if you are using a Harmony Cart that it first puts code into the zero page ram and then runs it while the Tao logo is being displayed. The consequence is that when you start a game on the Harmony the zero page ram is not in a randomized state, and your initial seed is always the same. So even though it is being played on real hardware it is not quite the same effect. You might want to try making a single image with the Harmony cart and see if the problem is still there.


If I had one wish for H2 it would be to have randomized zero page ram before letting the game run, and further to that if it was being played on a 7800 then it would write the known values for zero page ram on the 7800 back in so we could preform 7800/2600 auto-detection.

[theloon]

Forgive me if this sounds like a dumb solution, but, what about setting your seed value based on a counter and the first joystick button press?  That should work on emulator and hardware..

[Lodmot]

Alright, this problem has gotten even stranger...

Last night I went ahead and implemented a game over screen, which resets the game via a timer.
Today, I tested the game on the real console. I tried the rand/# method, but that didn't change anything.

HOWEVER, as I was playing through the game on the real console, I discovered that if the game over screen happens, and you begin a 2nd game, RANDOMIZATION WORKS!
It only doesn't work when you play the game first time around.

How's that one for you?

Oh, and also, I use randomization for the "rants" that you get whenever one of the shitty game objects (the playfield pixels) touches the game systems at the bottom of the screen (colored horizontally moving squares). The rants also don't get randomized at first on the real console, but as stated before, after a Game Over and starting a 2nd game, it does.

[theloon]

Lodmot, on Sat Feb 11, 2012 9:21 AM, said:

Alright, this problem has gotten even stranger...

Last night I went ahead and implemented a game over screen, which resets the game via a timer.
Today, I tested the game on the real console. I tried the rand/# method, but that didn't change anything.

HOWEVER, as I was playing through the game on the real console, I discovered that if the game over screen happens, and you begin a 2nd game, RANDOMIZATION WORKS!
It only doesn't work when you play the game first time around.

How's that one for you?

Oh, and also, I use randomization for the "rants" that you get whenever one of the shitty game objects (the playfield pixels) touches the game systems at the bottom of the screen (colored horizontally moving squares). The rants also don't get randomized at first on the real console, but as stated before, after a Game Over and starting a 2nd game, it does.

From the default.bas at top it looks like you need to randomize the seed value better.  Check out the source to my unfinished Destiny game for an example of using player input to help seed and bit shifting to further ranomize things.
http://www.atariage....86-destiny-wip/

[Lodmot]

Okii. Ill try that when I get home from work. Thanks ^^

[Lodmot]

I'm looking at your source code for that unfinished game you made, and I was wondering, what exactly is "seeding", and how does it help with randomizing things?

[Lodmot]

Alright, after doing a bit more research I was able to try out Omegamatrix's suggestion by making a single image to the Harmony cart. That did the trick!
So I assume when I get this game put on a custom cartridge, it will not have this problem, right?

Thanks for the help guys. :3

Edited by Lodmot, Sat Feb 11, 2012 3:45 PM.

[theloon]

From my own experience I've seen no difference running from a harmony cart or AtariAge made cart.  In fact, the only time I've heard of a difference is between running an EverDrive and a real Genesis cart.  Different system obviously.

[Lodmot]

Yeah. Well, everything is working great now, and I actually got the game finished. ^^

Thanks for helping out everyone. :3

[SpiceWare]

Lodmot, on Sat Feb 11, 2012 3:22 PM, said:

So I assume when I get this game put on a custom cartridge, it will not have this problem, right?

It probably will on a 7800.

[Lodmot]

Well, it's a 2600 game anyway. But why would it have the problem?

Edited by Lodmot, Mon Feb 13, 2012 2:14 PM.

[GroovyBee]

Because the 7800 has a BIOS that runs before your game. After the BIOS detects a 2600 cart it copies some code to RIOT RAM and executes it before jumping to your game's reset vector.

[Lodmot]

I have no idea what that is... Lol.

[GroovyBee]

RIOT is the chip that contains the 128 bytes of RAM in the 2600. It also contains a timer block and two eight bit wide ports used for console switches and joystick directions.

[Lodmot]

I see. So are you saying the game wouldn't run in a 7800 correctly because of that bit of code it executes?

[GroovyBee]

Not exactly. I'm saying that the contents of the RAM aren't random before your game ROM's reset vector is called. I'm pretty sure that the batari Basic runtime does some initialisation of the RAM too.