I've come up with another permutation of Chris B's #while loop idea, this one
using an array.

For a 200-frame animation, I create a 205-element array, then fill it with rand
values. (The extra values are for 'overhead', the reason for which will become
clear.) Each time the SDL scene is run, for each frame, those same rand values
are loaded into the array. (They're always the same from frame to frame
--that's the key to how the scheme works.)

---code---
#declare R = seed(72);
#delare rand_array = array[205];
#declare I = 0; // array[0] is a valid location
#while (I < 205)
#declare rand_array[I] = rand (R);
#declare I = I + 1;
#end

Then, to use them during animation, I do something like this:

#declare frame_number = F; // starts at 1, of course
object{my_object
 rotate 360*<rand_array[F - 1], rand_array[F], rand_array[F + 1]>
 translate <rand_array[F + 2], rand_array[F + 3], rand_array[F + 4]>
      }

(It uses six rand values from the array. For frame 200, rand_array[F + 4] is at
array location 204. Remember that the array itself starts at location 0, so
that's 205 total elements needed.)

You'll probably notice that, during each new frame of animation (and an
incrementing F), five of the six rand values are used again. But they are
applied to different axes (thanks to the ever-advancing F value), so the visual
result still *looks* random enough.

Of course, this scheme is somewhat wasteful of CPU time and memory, but it has
some nice advantages:
1) The rand values are always there (in the array), waiting to be used.
2) It's possible, through some SDL coding, to create short 'repeating
animations' WITHIN the overall animation. I'm using that idea now, to generate
some 4-frame 'explosions' that show up every now and then in different random
locations. Without the pre-made array, that would be more difficult to code.
It's complex to explain, and probably a bit off-topic, but the general idea is
to create *another* 205-element array, look at rand_array's rand values, then
(with a #while loop) stick four 'ones' or 'ONs' into the second array wherever
rand_array has a value >= some value you choose. Those resulting sequential
'ones'--always there for each frame of animation, always the same--are used to
trigger one of four 'events' (by using some version of the incrementing F
value) that all show up in the *same* random location (again chosen from
rand_array--so it now serves two purposes!) My own 'events' are four image_maps
applied to thin boxes. Pulling the 'ones' out of the second array--in the proper
sequence--is somewhat complex, and so is picking the proper rand values from
rand_array to translate the four image_maps, so they all show up in the same
place. But both simply use various sequences of the changing F, as in the
example above. I do think the scheme could benefit from a #macro, though, to
make it easier to implement and change.

(This particular idea could probably be done in a simpler way, by initially
#write-ing the four image_maps to a different file, which is only #read when I
want to use one of the four events; but my present scheme is all contained in
the SDL file, no #writing or #reading required.)

Ken W.

Post a reply to this message