Jump to content

Photo

Strange Problem with Randomization


19 replies to this topic

#1 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • 230 posts

Posted Fri Feb 10, 2012 3:23 PM

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


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


#2 stephena OFFLINE  

stephena

    River Patroller

  • 2,523 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Feb 10, 2012 4:30 PM

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.

#3 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,810 posts
  • Busy bee!
  • Location:North, England

Posted Fri Feb 10, 2012 4:38 PM

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

#4 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Feb 10, 2012 5:40 PM

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

#5 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 5,513 posts
  • Location:Canada

Posted Fri Feb 10, 2012 8:19 PM

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.

#6 theloon ONLINE  

theloon

    Quadrunner

  • 7,793 posts

Posted Sat Feb 11, 2012 3:27 AM

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..

#7 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Sat Feb 11, 2012 9:21 AM

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.

#8 theloon ONLINE  

theloon

    Quadrunner

  • 7,793 posts

Posted Sat Feb 11, 2012 11:02 AM

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/

#9 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Sat Feb 11, 2012 11:33 AM

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

#10 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Sat Feb 11, 2012 3:06 PM

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?

#11 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Sat Feb 11, 2012 3:22 PM

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! :D
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.


#12 theloon ONLINE  

theloon

    Quadrunner

  • 7,793 posts

Posted Sat Feb 11, 2012 8:33 PM

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.

#13 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Sun Feb 12, 2012 2:57 AM

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

Thanks for helping out everyone. :3

#14 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 8,187 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Mon Feb 13, 2012 1:24 PM

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.

#15 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Mon Feb 13, 2012 2:13 PM

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

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


#16 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,810 posts
  • Busy bee!
  • Location:North, England

Posted Mon Feb 13, 2012 2:21 PM

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.

#17 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Mon Feb 13, 2012 2:59 PM

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

#18 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,810 posts
  • Busy bee!
  • Location:North, England

Posted Mon Feb 13, 2012 3:01 PM

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.

#19 Lodmot OFFLINE  

Lodmot

    Chopper Commander

  • Topic Starter
  • 230 posts

Posted Mon Feb 13, 2012 3:21 PM

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

#20 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,810 posts
  • Busy bee!
  • Location:North, England

Posted Mon Feb 13, 2012 3:34 PM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users