English Amiga Board - I need a program to randomize wallpapers

English Amiga Board (https://eab.abime.net/index.php)

- request.Apps (https://eab.abime.net/forumdisplay.php?f=12)

- - I need a program to randomize wallpapers (https://eab.abime.net/showthread.php?t=94908)

I need a program to randomize wallpapers

I'm looking for a program to be placed in Startup-Sequence to choose a random wallpaper for the Workbench screen. I already tried rndwbpix.lha and RandomBG.lha and both do not work because they almost always choose the first image of the directory. Is there a program that has already been tested and that implements a better algorithm?

Leandro.

Sounds strange that both randomization work the same for you. Where do you start the tools? Maybe it helps to start them later or with a small delay. What happens if you start it after boot from WB?

I don't know if Stephan Rupprecht is still active but Thore should be. So you might ask them for help or an update.

Hi daxb!

When I start the rndwbpix program, it does not seem to work, even when I put it to change the wallpaper every 3/10/15/60 seconds!

The RandomBG program seems to have started to work again, but before that it did not seem to work either.

I start one of the two always one line before the "C:IPrefs". I tried to start them inside AmigaShell in the Workbench, as you said, and only RandomBG worked.

Hmm, I need to get more wallpapers for my Workbench, because that "might" be what's causing the problem...

Thank you for your attention! ;)

Maybe SnoopDos can help you understand what is going on.

Quote:

Originally Posted by Leandro Jardim (Post 1281445)

both do not work because they almost always choose the first image of the directory

You should get in contact with Retrofan. A while ago he got something from me for a similar purpose. I don't remember exactly what it was but I know we discussed exactly this issue.

The problem with programmed random number generators is that they can only generate a new pseudo-random number from the previous one. The first one has to be taken from a truely random source, otherwise you would always get the same series of numbers.

Now there is nothing in a computer like the Amiga which is truely random. You might think that for example the microsends portion of the current time or the current beam position of the display would be random at any time.

Well, they are, if you run the program in the middle of the day by double click. Because the time you need to select the icon and double-click it is random. But believe it or not, if you run the program from startup-sequence and use one of the mentioned sources, you always get the same or at least a similar starting value.

One could also use the number of seconds since 1976 as a starting value, but then if you run the program twice within one second, you get exactly the same series or numbers.

I don't remember exactly how I fixed it for Retrofan, but I believe on the first call my program reads the directory, puts the files in random order and then saves the list. On subsequent calls it just uses the next entry from the list. This way you always get a different file until the whole list has been run through. The disadvantage is that you have to recreate the list whenever you add or remove a file from the directory.

Many thanks to you too, Thomas! ;)

Funny to note that today from another thread I red something similar on uridiumauthor.blogspot.com
(you will have to turn off the Firefox tracking protection to see the blog :guru) :

Quote:

Random Numbers
I`ve seen people ask questions such as: "how do I get a random number between 1 and 3 quickly?" The fact is that most random number generators are algorithm-based, so no random numbers are delivered all that quickly. In fact, the only time I`ve found a hardware way of getting a random number was on the C64 SID chip. You could set the third channel to noise waveform, rack up the frequency, and read out out the current waveform value. I used to direct all the noise sound effects to that channel, and when it had finished I switched the sound channel to play silent high-frequency white noise. Any time you need a random number; just read it off the SID chip: 1 assembler instruction, nothing faster!

The advantage of algorithm-generated random numbers is that they can often be seeded, so you can get the same set of numbers out every time. In my latest game I could watch the first titles sequence, with supposedly random things happening, and every time the first demo sequence ran, it did exactly the same thing. To change that, I now get a timestamp of when the program starts, and seed the system random number generator with that. Now I get a different demo every time I start the program. I`m still not happy about the time that the system algorithm takes to supply a random number. Firstly, I have no idea actually what algorithm it is using, but secondly, that might change at any time if someone decides to alter the C library.

In order to supply my game with random numbers faster than the system can, I get an array of 256 numbers in advance from the system. I refresh that every time a game starts. Getting 256 numbers at the beginning of a game doesn`t take a great deal of time in the grand scheme of things, the player is just getting ready to play and likely you`re doing some kind of arrival sequence anyway. I then keep one index pointer into the array of random numbers and my fast call pulls out the next entry and shifts the index along by one. It just has to make sure it doesn`t fall off the end of the table. Actually an assembler optimisation for that would be to start at the end of the table so you decrement the index and easily detect the underflow case that resets the index to the end. It saves a compare. In C, the get a random number function is so short that on a RELEASE build it`ll likely drop in the code in the function rather than calling it.

Coming back to the random number between 1 and 3 then... I would always try to avoid anything that doesn`t involves powers of 2. Scaling our 32-bit random number to a lower power of 2 is again just a case of logically ANDing the random number with a mask to reduce the scale. ANDing with 0x03 gives you an equal chance of 0, 1, 2 or 3. None of the powers of 2 are divisible by 3, strangely enough. If you do want to do that then you could do it quicker by, say, getting number between 0 and 255, and testing it for being less than 86 for 1 route, less than 172 for the second, else the third. The only faster way is to set up a specific array of random numbers between 0 and 2 for later diving into.

The process of setting up an array with answers to complex calculations in advance is nothing new. On the C64 the screen was 40 characters wide, and there was no multiply instruction, so a little table of 25 entries with multiples of 40 in it was great for calculating the screen character address at a particular co-ordinate. You would divide the Y pixel co-ordinate by 8 by using the logical-shift right instruction 3 times, then look up the multiple of 40 in your table, then take the X pixel co-ordinate and divide by 8, and add that on.

Quote:

Originally Posted by Leandro Jardim (Post 1281445)

I have tested RandomBG on both PAL and GFX systems end RandomBG choose a random background for the Screen and for the Workbench.

Also RndWbPix choose a random background for the screen and it works well

Thanks everyone for the answers. I was using too few images I think (only three seems is not sufficient), because with 51 images now it works. :)

Thanks again! ;)