Jump to content
IGNORED

rand16 scatterplot


bogax

Recommended Posts

Atarowg uses rand to generate the dungeon floors. Unfortunately, the dungeon layouts are always very, very predictable. I tried seeding rand with the worldx coordinate and rand16 with the worldy coordinate but the results weren't better AND some dungeon floors changed randomly. This should not happen in a PRNG. Eventually I had to drop trying to seed rand16 and resort to bit shuffling again.

 

It also seemed the farther out the binary digit the harder it was to get certain bits. Meaning, there was a greater chance randresult{0} would be 1 and way less chance of getting randresult{7} to be 1.

 

For some reason my ISP must be blocking netau.net. I can get to the site linked just fine through a different Internet service. Strange.

Link to comment
Share on other sites

The blue dots look like they are 3D and are about a fourth of an inch behind the red dots.

http://en.wikipedia.org/wiki/Chromostereopsis

 

PRNGs are of course never really random. In particular for most PRNGs the upper bits are much more random than the lower ones.

Which probably is the main reason for many problems.

I.e. for Assembloids2600 you really feel the difference if the choice of the next tile (only 4 options) is based on bit01, bit23 or i.e. bit 56.

Also people often use the same PRNG for different things, this also introduces problems because it is NOT random.

B will always follow A.

So again in Assembloids2600, if I would call the same rnd-function to select a tile and afterwards to select a color,

the pair of tile and color would always be strongly coupled and you would 'feel' that.

 

PRNGs are great, and they are ooooold (it seems like a recent re-discovery is going on). Also very old in game-coding :)

But its not always trivial to use them. You have to tune and judge your ago wisely or you end up with a very short period no matter if its 8 or 16 bits and you have to take into account that they are... well.. not random :)

You often see people combining two PRNGs for 'more' randomness which in generall leads to quite the opposite.

Edited by enthusi
Link to comment
Share on other sites

LFSRs are not very random to begin with.

And 8 or 16 bits is just not enough to
look very random.

A big problem on the 2600.
When you begrudge the extra byte for
rand16 who is going to want to use a rand64?

Probably would help if we could afford more
cpu time to mix things up but even multiplication
is a significant cost never mind, say, a 32 bit
square root.

And as enthusi said you've got to be careful.
if you always take 5 numbers at a time
from your lousy 255 cycle length 8 bit LFSR,
you just turned it into (something like)
a really lousy 51 cycle length LCG

Never the less I'm impressed with how well
rand16 does for something so simple.
(at least, going by the scatterplot)

I don't know a good solution.
I think I'd try combing an LFSR and an LCG
and using at least 4 bytes for state
(at least a 32 bit PRNG)

Link to comment
Share on other sites

Atarowg uses rand to generate the dungeon floors. Unfortunately, the dungeon layouts are always very, very predictable. I tried seeding rand with the worldx coordinate and rand16 with the worldy coordinate but the results weren't better AND some dungeon floors changed randomly. This should not happen in a PRNG. Eventually I had to drop trying to seed rand16 and resort to bit shuffling again.

 

 

I'd guess that there's an exellent chance that you're just short circuiting

part of the cycle by seeding the PRNG from itself (in effect changing

it from 16 bits to something less, maybe much less).

 

What bit shuffling did you do?

 

Can you afford a couple more bytes for a better rand?

Link to comment
Share on other sites

 

I'd guess that there's an exellent chance that you're just short circuiting

part of the cycle by seeding the PRNG from itself (in effect changing

it from 16 bits to something less, maybe much less).

 

What bit shuffling did you do?

 

Can you afford a couple more bytes for a better rand?

 

In a perfect world my PRNG would take four values as seed: worldx, worldy, dungeonfloor, worldseed

 

The gotcha is that worldx, worldy should not result in the same output as worldy, worldx.

 

Basically, I've been trying to overcome that by seeding the bB rand function thus:

 

rand = (worldx + worldy + worldy + dungeonfloor + worldseed)

 

UPDATE: I keep mulling over this PRNG. Could it be adapted to the 2600?

http://codebase64.org/doku.php?id=base:small_fast_8-bit_prng

Link to comment
Share on other sites

What do you mean: adapted to 2600?

Its pure 6502 and I use the exact same one for Assembloids2600 as I posted somewhere :)

 

Sorry, I just wondered if the assembly literate crowd would know if there's something in the 2600 architecture that would make that code unusable. You answered that question quite well :)

Link to comment
Share on other sites

 

In a perfect world my PRNG would take four values as seed: worldx, worldy, dungeonfloor, worldseed

 

The gotcha is that worldx, worldy should not result in the same output as worldy, worldx.

 

Basically, I've been trying to overcome that by seeding the bB rand function thus:

 

rand = (worldx + worldy + worldy + dungeonfloor + worldseed)

 

UPDATE: I keep mulling over this PRNG. Could it be adapted to the 2600?

http://codebase64.org/doku.php?id=base:small_fast_8-bit_prng

 

How do those variables get changed and

how do you want them to change?

 

I mean do you want to get a certain

maze from a certain seed and have the

maze be predictable?

 

Or do you want eg which room you go to

from here to depend on which room you

came from to get here?

 

 

That is the bB rand except that bB shifts

the opposite direction and doesn't insert

0 in to the sequence.

 

Edited by bogax
Link to comment
Share on other sites

 

How do those variables get changed and

how do you want them to change?

 

Every time the player moves to a different screen the worldx and worldy coordinates change. Each screen has it's one unique worldx, worldy coordinate. So, if the player moves to the left the worldx coordinate would decrease by one.

I mean do you want to get a certain

maze from a certain seed and have the

maze be predictable?

 

Yes! Instead of storing the dungeon layout I'd use a PRNG to determine the properties of each screen. When the player moves between screens the properties should be static.

Or do you want eg which room you got to

from here to depend on which room you

came from to get here?

 

I usually picture a PRNG giving the same result given the same worldx, worldy coordinate - no matter how far the player has traveled.

 

That is the bB rand except that bB shifts

the opposite direction and doesn't insert

0 in to the sequence.

 

Fudge. Thanks for checking it out.

 

In Atarowg seeding the bB PRNG with the worldx, worldy, dungeonfloor and worldseed values give you a single 8 bit number to determine the current rooms properties:

 

Bit 0 - Has exit West?

Bit 1 - Has exit East?

Bit 2 - Has exit North?

Bit 3 - Has exit South?

Bit 4 - Has laser trap?

Bit 5 - Has monster spawn?

Bit 6 - Has Treasure chest?

Bit 7 - Has staircase?

 

Through playtesting I found bits 4-7 seemed less prone to change. Meaning there would be easily repeatable chains of rooms all having staircases or chests etc..

Link to comment
Share on other sites

Is ROM space an issue? If not you can and should work i.e. with an SBOX.

That being thrown in:

imagine a simple table of 256 REAL random numbers, now use your PRNG value as pointer into this table.

This wont help the period issue but it will make each individual bit of a value completely independant on the former one which LSFR is per definition not :)

Also about my short reply with regard to the 2600-implementation of the 8 bit PRNG: that probably sounded a bit harsh. Sorry if that was the case.

I was just surprised by the question. So yes, all it needs is one byte in RAM and you can copy-paste that code directly. Basically ALL math code from codebase64.org as it is not hardware-specific.

If you spot fiddling with $00, $01 or anything in the $dxxx range, that is likely to be C64-specific though :)

  • Like 1
Link to comment
Share on other sites

 

In Atarowg seeding the bB PRNG with the worldx, worldy, dungeonfloor and worldseed values give you a single 8 bit number to determine the current rooms properties:

 

Bit 0 - Has exit West?

Bit 1 - Has exit East?

Bit 2 - Has exit North?

Bit 3 - Has exit South?

Bit 4 - Has laser trap?

Bit 5 - Has monster spawn?

Bit 6 - Has Treasure chest?

Bit 7 - Has staircase?

 

Through playtesting I found bits 4-7 seemed less prone to change. Meaning there would be easily repeatable chains of rooms all having staircases or chests etc..

 

So you'll have 256 possible room layouts

 

Except that I think you need something

to tell you if the stairs are going up

or down and some way to control stairs

between floors so that if there are stairs

they go both ways ie you want to be able to

go both up and down a particular set of stairs

(you have a similar problem with going between

rooms, but at least you specify passages going

both ways)

I think you need more than 8 bits to specify

a room

 

And this will be in something like a

256 x 256 x 256 world?

 

Can you afford some 256 byte look up tables?

I think some tables would definitely help.

including but not limited to enthusi's

scatter tables (SBOX)

 

I think if you're not careful you'll

end up with mazes with unconnected

parts.

 

Which could be cool, you need the

magic amulet that let's you walk

through walls to get to them

(or something)

 

 

 

Edited by bogax
Link to comment
Share on other sites

In Atarowg the stairs always go down until you pick up the Eye of Gingrich. Then the stairs only go up. When you go through a staircase the next floor may not have a connecting staircase back to the previous floor.

 

In Destiny there are stairs up or down. There is no guarantee of a connecting staircase on the next floor in either game.

 

In both games I guarantee an exit leading back to the previous room. This exit back is only temporary. If the player moves two screens forward and comes back the temporary exit is gone.

 

If I need more data (for instance, the contents of a treasure chest) I just use the PRNG again to generate another 8 bit value to use.

 

In either game the ideal was 256x256 rooms for each of the 256 floors possible. In Destiny I go one further by having each room have an alternate version that gets triggered infrequently.

 

I dunno. Using up a table seems awkward and space hogging. I should re-read the alternative PRNGs mentioned in the Destiny topic. Maybe by using alternative PRNGs I can double down on the pseudo randomness without tables :)

Link to comment
Share on other sites

In Atarowg the stairs always go down until you pick up the Eye of Gingrich. Then the stairs only go up. When you go through a staircase the next floor may not have a connecting staircase back to the previous floor.

 

In Destiny there are stairs up or down. There is no guarantee of a connecting staircase on the next floor in either game.

 

In both games I guarantee an exit leading back to the previous room. This exit back is only temporary. If the player moves two screens forward and comes back the temporary exit is gone.

 

If I need more data (for instance, the contents of a treasure chest) I just use the PRNG again to generate another 8 bit value to use.

 

In either game the ideal was 256x256 rooms for each of the 256 floors possible. In Destiny I go one further by having each room have an alternate version that gets triggered infrequently.

 

I dunno. Using up a table seems awkward and space hogging. I should re-read the alternative PRNGs mentioned in the Destiny topic. Maybe by using alternative PRNGs I can double down on the pseudo randomness without tables :)

 

So you just need a hash of your four

parameters/variables.

 

I'd suggest if you're going to use

rand to do the hashing you keep it

seperate from other uses of rand

where you want a random number

so the other stuff doesn't end up

dependent on your room type.

 

 

the rand function is like this

 

 

if rand{0} then rand = rand/2 ^ $B4 else rand = rand/2

when you do the hash take a random

number at least 8 times, that gives

all the bits of the seed a chance

to have an effect on the hash

ie pass through if rand{0}.

 

so something like this

 

temp1 = rand
rand = worldx + worldy + dungeonlvl + worldseed
rand = rand : rand = rand : rand = rand : rand = rand
rand = rand : rand = rand : rand = rand : roomtype = rand
rand = temp1

That's just for illustration.

 

There's all kinds of variations you could try

eg substitute xor for all or some of the addition

or do some of the shifting yourself

 

temp1 = rand
rand = worldx ^ worldy ^ dungeonlvl ^ worldseed
rand = rand/4 ^ rand
rand = rand : rand = rand : rand = rand : roomtype = rand
rand = temp1

 

I think you'll still run a risk

of having some of the maze be unconnected.

 

 

  • Like 1
Link to comment
Share on other sites

Mulling over your advice I settled on:

 rand = (worldx + dungeonlvl + worldy)
 rand = rand + (worldy ^ worldseed)
 roomtype = rand

It seems to work! The dungeon seems like it's less repetitive.

 

atarowg_bogax.bin

 

Thank you VERY much for your help. I apologize for hogging your topic with my personal PRNG woes. I DO know I'll make better games as a result!

Link to comment
Share on other sites

Mulling over your advice I settled on:

 rand = (worldx + dungeonlvl + worldy)
 rand = rand + (worldy ^ worldseed)
 roomtype = rand

It seems to work! The dungeon seems like it's less repetitive.

 

attachicon.gifatarowg_bogax.bin

 

Thank you VERY much for your help. I apologize for hogging your topic with my personal PRNG woes. I DO know I'll make better games as a result!

 

Here's another bit of sillyness.

I doubt if it does any thing useful.

 

What it does do is hash a couple of values

and then plot the result on the standard

kernel playfield.

 

You can step through the values x and y using the

joy stick.

 

The fire button steps through different hashes

and clears the screen but doesn't effect x and y

 

The first hash is COMB for combined.

Combined is a variable that combines x and y

at the beginning of the plot routine.

 

r1..r8 sets rand to combined then calls

rand that number of times.

 

9..E are slots for other possibilities.

Only 9 and E are occupied.

9 with something like your hash but using

only x and y.

E is just (the equivalent of) rand16.

It doesn't hash x and y it just plots rand16.

It also shows the two bytes in the lower

left of the playfield. You can watch them

sort of circulate.

 

The last one PEAR is a Pearson's hash.

 

 

Like I said I doubt if it shows anything really

useful, but it's interesting to see the patterns :) .

 

I wanted to see how calling rand different numbers

of times would affect things and to see what the

Pearson's hash would look like and how it compared.

 

I think I tried the ones I suggested previously and

they looked liked they'd really suck :P ;) .

 

plothash.bas

 

 

  • Like 1
Link to comment
Share on other sites

I believe you just have to dim rand16 and bB (actually DASM) will use

that as the other half of the seed and produce the rand16 code

 

(RT's page) rand

 

I'd say definitely use rand16 if you can possibly spare the variable.

Edited by bogax
Link to comment
Share on other sites

 

How exactly do I use rand16?

 

I have:

 

dim rand1=$DA
and then:
player0y=(rand&40)+92
...
b=(rand&40)+92
Could I use rand16? The way it works now, I get a lot of similar values in a row.

 

 

rand & 40 will produce one of 4 values

 

0, 8, 32 or 40

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...