AutoHotkey Community

Zippo · Joined: 21 Apr 2006 Posts: 56 Location: East Coast, USA

I put this script together to see how well the Generating unique random integers script posted by Laszlo performed.

This script breaks up a 300x300 .jpg image and draws it back randomly, pixel by pixel, in real-time.

Even though this isn't really the best test for this type of code (a lot of overhead is added in every time a new random number is generated by the DLL call to paint a pixel to the screen...etc), it does give a visual idea of how fast this runs.

Remember, 90k pixels here. All done in an avg. of about 14 seconds on my machine.

Thanks Laszlo for the great code Smile

jonny · Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota

At first I thought you meant it drew each pixel in a random place, to get a jumbled picture. Very Happy

This is much nicer. Very neat effect. It reminds of a BASIC program I wrote when I was 12, that drew random colors on random pixels. I think it was supposed to be a screensaver.

Too bad it isn't faster. Maybe you could draw 3x3 chunks with each iteration, or compute the random order beforehand and then loop only the DllCall... of course, that could potentially use a lot of memory for the storage of each position.

jonny · Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota

Alright, here's my version that first determines the random order in full, and then uses it to draw the picture. The good news is that it draws it very fast, and at a consistent speed since the repetitions don't take longer to get over as the picture fills up more. The bad news is that it still takes just as long to compute, so you're sitting there staring at a blank screen until it's done. This might not be a problem, if you preload it while you do something else and then draw it when it's called for later on, but I doubt that would be the normal situation.

Added lines are in violet.

PhiLho · Posted: Thu Feb 08, 2007 4:13 pm Post subject:

I first tested jonny's version, and thought it was broken, as I saw an image on bottom left and nothing happened.
Then I tried Zippo's version and saw what it was supposed to do.
So I came back to jonny's, waited more, and saw the result!
Suggestion: do like I did and add:

Zippo · Joined: 21 Apr 2006 Posts: 56 Location: East Coast, USA

This script is a bit slow towards the end. But all-in-all, for its size and complexity, Laszlo's function is really great.

If you quote out all the extra math/dll calls, it goes thru all 90k random numbers in about 8 seconds on my system.

But like I said.. for its size it is hard to beat Smile

_________________
____________________

skrommel · Joined: 30 Jul 2004 Posts: 180

May I suggest using
Sort,list,Random
to speed things up?

Skrommel

skrommel · Joined: 30 Jul 2004 Posts: 180

Here's a different approach, with no delays!

It seems the slowest command of the scritps above is the PixelGetColor.
I tried BitBlt and StrechBlt, but they were even slower.

I ended up using two windows, one with the picture, and one transparent one above it.
By painting on the topmost window, the bottom one is revealed!
I was actually surprised that it worked!

You can make any kind of transition, just paint with a black brush on the topmost window!

Skrommel

jonny · Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota

It's not as smooth, though. I suspect it takes some more time for the OS to grab the alpha channels and compute transparency in the background. It could also just be that this computer is slower, but it isn't that slow. With the transparent version, it seems to draw them in groups of several dozen pixels at a time, whereas with the per-pixel version it clearly drew each one separately even under load (after the list is computed).

skrommel · Joined: 30 Jul 2004 Posts: 180

What graphics card are you using? I've got a Radeon 9600SE.

Skrommel

skrommel · Joined: 30 Jul 2004 Posts: 180

To speed things up in your script, jonny, the pixel list could be saved to a file, or included in the script itself. Then you wouldn't have to include the picture, either.

Skrommel

jonny · Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota

This is not the kind of effect that should require a good graphics card. It's not even using transparency (not unless you use that other method) or anything advanced, just pixel drawing.

And I thought of generating the list beforehand and storing it, but then it wouldn't be a true randomized effect.

jonny · Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota

Alright, done. Still not usable, just proof-of-concept. You can process the image once with the first script and then use the effect instantly with the second one. I also added a progress bar, which makes it easy to see that it slows down a lot near the end, when you have to go through a lot of duplicates before getting to an unclaimed spot.

jonny · Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota

And yet another version. Very Happy

I realize that this was originally written to demonstrate Laszlo's code, but I can't resist doing a better version of the effect itself.

This one processes linearly rather than the run time increasing exponentially as N increases (this only happens because we need to check for and re-process duplicates). Also facilitated by this version is the much faster 'Sort,,Random', probably better suited to this task than a generic randomizing algorithm.

svi · Joined: 09 Oct 2006 Posts: 126 Location: Finland

I made a modification to Zippo's code, to use arrays to not have to cast lots (randomize) more than the amount of pixels, as the original one made about a million randomizes for 90 000 pixels.
It's nearly five times faster and doesn't slow down towards the end, still slower than Skrommel's version, but I think fast enough.