Here's one simple method to keep _SETAPLHA from slowing down your code too much, like I was telling bplus in a thread somewhere before -- Do all the prerendering of you alpha levels once and be done with them.
'Snowflake effect using transparency and rotozoom.
'Dav is trying to speed this up...
flakes = 1000 'number of flakes
Dim Shared flake.x
(flakes
), flake.y
(flakes
), flake.ys
(flakes
) 'x/y values, y speed Dim Shared flake.r
(flakes
), flake.rs
(flakes
) 'rotation and rotation speed Dim Shared flake.a
(flakes
), flake.s
(flakes
) 'alpha value & flake size
'generate random snowflake vaues
flake.x
(f
) = Rnd * _Width + 30 'make randowm starting x position
Case 2: flake.ys
(f
) = 1.5 Case 4: flake.ys
(f
) = 2.5
flake.r
(f
) = Rnd * 360 'make random rotation sstarting value
flake.a
(f
) = (Rnd * 128) 'random alpha value
flake.s
(f
) = Rnd * 1.75 + .1 'randomw snowflake size
'Cls
If mode
Then 'use the spacebar to toggle alpha methods RotoZoom3 flake.x
(f
), flake.y
(f
), snow&
, flake.s
(f
), flake.s
(f
), _D2R(flake.r
(f
)) RotoZoom3 flake.x
(f
), flake.y
(f
), snows
(flake.a
(f
)), flake.s
(f
), flake.s
(f
), _D2R(flake.r
(f
))
flake.r
(f
) = (flake.r
(f
) + flake.rs
(f
)) Mod 360 'increase rotation
flake.y(f) = flake.y(f) + flake.ys(f) 'lower y position
'if flake goes off screen, make a new flake above
c = c + 1
' _Limit 30
' This assumes you have set your drawing location with _DEST or default to screen.
' X, Y - is where you want to put the middle of the image
' Image - is the handle assigned with _LOADIMAGE
' xScale, yScale - are shrinkage < 1 or magnification > 1 on the given axis, 1 just uses image size.
' These are multipliers so .5 will create image .5 size on given axis and 2 for twice image size.
' radianRotation is the Angle in Radian units to rotate the image
' note: Radian units for rotation because it matches angle units of other Basic Trig functions
' and saves a little time converting from degree.
' Use the _D2R() function if you prefer to work in degree units for angles.
Dim W&
, H&
, sinr!
, cosr!
, i&
, x2&
, y2&
' variables for image manipulation px(0) = -W& / 2: py(0) = -H& / 2 'left top corner
px(1) = -W& / 2: py(1) = H& / 2 ' left bottom corner
px(2) = W& / 2: py(2) = H& / 2 ' right bottom
px(3) = W& / 2: py(3) = -H& / 2 ' right top
sinr!
= Sin(-radianRotation
): cosr!
= Cos(-radianRotation
) ' rotation helpers For i&
= 0 To 3 ' calc new point locations with rotation and zoom x2& = xScale * (px(i&) * cosr! + sinr! * py(i&)) + X: y2& = yScale * (py(i&) * cosr! - px(i&) * sinr!) + Y
px(i&) = x2&: py(i&) = y2&
To test this, simply let it run for a few seconds and watch the number that pops up on your top-left corner of the animation. See what it averages to be for you after 5 or 6 updates. Mine starts out around 110 FPS or so.
Then hit the space bar and watch how that number changes over the next five or six seconds. Mine tends to drop down to about 80 FPS or so.
That's an increase of what? From 80 to 110.. about 40% faster, just by doing the pre-alpha work once and being done with it?
Now, if we *really* wanted to see an increase in speed and performance, couldn't we also do the scaling in a similar manner? (Scale is .1 to 1.75, size is 30x30, so that's a max scale range from 3 to 53, so only a total of 50 actual levels in sizing, which is a small enough array of images to keep in memory.) Once the scaling is predone, we no longer need RotoZoom at all. We can stick to a single simple _PUTIMAGE for our snowflakes....
And in that case, we can then _COPYIMAGE(image,33) everything to swap over and make them HARDWARE images and then let the GPU do all the work with that _PUTIMAGE command, which will run much, much faster than software rendering everything like we're currently doing.
It'd require more memory usage up front to store all the pre-rendered and pre-sized images, but these are small images (30x30 is only 900 pixels or 7200 bytes of information) and really shouldn't cause that big of a footprint for memory usage in modern systems. For example, the 256 pre-rendered alpha images I'm using above only uses a total of 7200bytes * 256 alpha levels = 1.8MB of memory... PUHH! If your modern computer can't handle 1.8MB of memory usage, then it's time for you to upgrade! Even if I pre-rendered and pre-sized to match every possible combination, we'd only be looking at 1.8 * 50 = ~92MB of memory usage for the whole shebang!
QB64 can work blazingly fast with modern systems and modern memory limits, if we want it to. It's a little more programming to make it do so, and to swap everything over from software (which most of us old school programmers are used to) to hardware images, but *when necessary*, it can make one helluva difference.
