Random game it's not to much randomly :)

IanDaemon

@djdiabolik So...this? (ignore the file sizes)

mitu

@djdiabolik I'll take a look.
I have a suspicion that 'random' counts only the games in the main folder (excluding the sub-folders) and that's why it's always picking the same number (or close to it, if you have few games in the main folder).
Could be related to the reports of users about screensaver not being 'random' enough - though it wasn't something I was able to reproduce.

DjDiabolik

@IanDaemon
Wait... i have the same folder structure also on a folder on windows (for made skraper of all roms).

This is the content of "/roms/arcade"

Inside mame2003-plus there are all roms zips

@mitu for curiosity... how is random choice made ?
each game has its own id and retropie chooses an id at random and selects it ?

Or simply retropie made a random step upward or downward respect the last game selected ?

mitu

@mitu for curiosity... how is random choice made ?

step 1 - count the games in the system.
step 2 - pick a random number between 0 and N, where is N is the number of games
step 3 - go to that game.

DjDiabolik

@mitu said in Random game it's not to much randomly :):

step 1 - count the games in the system.
step 2 - pick a random number between 0 and N, where is N is the number of games
step 3 - go to that game.

Oh ok..... therefore it may happen that the same game is reselected frequently if the variable N it is "generated not too randomly" :) ?
This reminds me of one thing... i have a good knowledge whit BASIC and AutoIT developing:
About 5 years ago I was writing a program where I needed to generate a randomatic variable.
If i remember correctly this variable need to obtain a value from 1 to 60....... I remember that this variable, after several tests, always seemed to obtain very similar values.

By way of workaround i "made/intent" a new routine of random choice.... i used a loop... an example:

RND(X) 1 to 10000 <- Temp variable
RND(N) 1 to 60 <- The variable i need
Made a complete loop whit variable X and regenerate variable N every time.

I don't know if I've made myself clear.... but thus the choice of the variable I needed immediately appeared more randomatic :)

IanDaemon

@djdiabolik I just tested the functionality and it appears to be working correctly on my end. Wouldn't your loop just complete the same "non-random selection" ten thousand times?

DjDiabolik

@iandaemon mmmmmmmm....
i don't have idea because it's happend on my pi4 setup :)

I can say that if the same thing happened to me on a roulette wheel I could get rich :)

Here it's very strange........ from a collection of about 2000 games if i press 15 times random button i can clearly see the same game selected from the 3 or 4 times.

then we can say that it's just "randomness" :)

IanDaemon

I believe that it's happening to you. I'm just trying to figure out the logic in my head. Selecting a random number from one to "N" should give you a random number within the constraints given. If the total number of games isn't "N" then where might "N" be coming from? Maybe there is some limit to the subfolders traversed and that is affecting "N"? I'm not sure, but this sounds like a mystery.

mitu

Can't reproduce this. I have a system with 1000+ games in a sub-folder, pressing X always gets me a random game. It doesn't matter whether there's a few games in the main folder or not.

If you can zip your gamelist.xml and upload it somewhere I could try to reproduce it using it.

Lolonois

"Random Number Generation is too Important to be Left to Chance" -- Robert Coveyou

Thanks to @DjDiabolik for bringing this up and sorry, the next sections will be technical. I can not judge what role your specific setup plays in the described effect, but I have evidence that some part is also caused by the current implementation. Maybe your described effect is a cumulation of both.

I had a review of the codesegments in question, and the randomness is not really a unique randomness (if it would be a roulette it would be rigged). However, on my setup I have not noticed the same games selected/shown over short time / X presses, but some do show up more often in the slideshow than others and some have never been shown.

Here is my analysis:

Major flaw is the use of rand() in the code which does not spread evenly in RAND_MAX (=not uniform random as a ideal coin). Your effect @DjDiabolik may be caused by a non synchronized clock (which is likely as the Rpi has no real hardware clock as a PC and if the Rpi fake-hwclock is disabled or not updated on shutdown the Rpi time "stands still"). If system time is not updated and your system boots up with a tolerance of +/-0.5 sec you will most likely get the same random numbers from rand() as the random number generator gets initialized with the same time (which then defines the sequence of random numbers).
It is very, very unlikely to get the screensaver image/video to show the last game in the overall gamelist list. If you maintain 3000 ROMs for example the likelyhood is not 1/3000 but 1/2147483647 (NB: 2147483647 = 2^31-1 which is RAND_MAX on Linux-Rpi). This subtle programmatically introduced non-uniforminess is something tried to be mitigated on the random game/random system selection but in a odd way.
Whenever one uses custom images to display during the screensaver there is a modulo bias, so even if rand() would be uniform distributed random numbers, some custom images are shown more often than others.

I lifted the code a while ago and I am happy to file a PR the next days: It utilizes a fast real uniform random number generator (not depending on time as sole source of entropy/initialization), uses the benefits of C++11 and has less code to accomplish the same.

DjDiabolik

@iandaemon said in Random game it's not to much randomly :):

I believe that it's happening to you. I'm just trying to figure out the logic in my head. Selecting a random number from one to "N" should give you a random number within the constraints given. If the total number of games isn't "N" then where might "N" be coming from? Maybe there is some limit to the subfolders traversed and that is affecting "N"? I'm not sure, but this sounds like a mystery.

lol...i don't have idea. I'm probably the one who's noticing it too much :)

@mitu said in Random game it's not to much randomly :):

Can't reproduce this. I have a system with 1000+ games in a sub-folder, pressing X always gets me a random game. It doesn't matter whether there's a few games in the main folder or not.

If you can zip your gamelist.xml and upload it somewhere I could try to reproduce it using it.

it's not a problems.... tomorrow or next time i turn on my Pi4 i get for you the gamelist.xml of my NES system. It's about 3000 roms divided alphabetically by subfolder and try to upload on zippyshare or somethigs similar (suggest if you have a preferred host site).
i can also provide the gamelist.xml of my arcade system whit only mame2003-plus collection. here all roms it's inside a single subfolders and also here I can notice this strange randomness :)

Guys... what seems strange to me it's this. with a smaller collection of roms obviously the chances that the same game will be selected randomly more times is higher:
For example.. Atari Linx entire collection it's only 95 titles. But with a larger collection, in theory, it should be the exact opposite :)

@Lolonois i have read carefully your explanation...... but it's too much techicals for my knowledge here :)

mitu

@djdiabolik said in Random game it's not to much randomly :):

i can also provide the gamelist.xml of my arcade system whit only mame2003-plus collection. here all roms it's inside a single subfolders and also here I can notice this strange randomness :)

It doesn't matter how many games are, as long as the issue occurs with that system.

dankcushions

@lolonois said in Random game it's not to much randomly :):

Major flaw is the use of rand() in the code which does not spread evenly in RAND_MAX (=not uniform random as a ideal coin). Your effect @DjDiabolik may be caused by a non synchronized clock (which is likely as the Rpi has no real hardware clock as a PC and if the Rpi fake-hwclock is disabled or not updated on shutdown the Rpi time "stands still"). If system time is not updated and your system boots up with a tolerance of +/-0.5 sec you will most likely get the same random numbers from rand() as the random number generator gets initialized with the same time (which then defines the sequence of random numbers).

using microseconds for the seed would seem like a simpler solution - http://www.guyrutenberg.com/2007/09/03/seeding-srand/

even if the clock isn't synced, the microseconds for a boot should vary enough i would have thought?

Lolonois

@dankcushions time has moved on (sorry for the pun) since then (referring to your blog post reference). I filed a PR which uses a permuted congruential generator, along with all other remidiations. I also like the approach that the PCG has getting more statistical analysis/correctness validation by a brain more knowingly than mine on that topic.

dankcushions

@lolonois yes, i've seen the PR which prompted my reply. to me it seems cool but a bit over engineered if a 3 line fix would more or less fix it (if my thinking is correct), but i'm also at the mercy of smarter people's opinions :)

DjDiabolik

I guys are following the discussion :)
Whit my bad english it's already difficult to made an example........

Damn... when i made the video whit GB and CATRAP for the other my thread I could show you the example of this too :)

I also had to post the gamelist.xml but it just passed my mind ... really sorry ...