Fastloops causing slowdowns. Workaround?

[Dines]

1) The animation swap trick is where you have a separate animation in your projectile which has the shape that you want to use when checking for collisions. You then do this:

Always (or some better optimised condition)
-- Bullet: Set animation to 'My Collision Shape'

Bullet Overlaps Backdrop
-- Do your collision detection stuff

Always
--- Bullet: Set animation back to 'Stopped' (or whatever the name of your standard animation is)

Doing this, the player sees the Stopped animation, but the collision detections work on the My Collision Shape animation. It saves you having multiple detector objects, but the down side is that it's harder to control animations for objects like this, because the animation frame gets reset each time you change the animation. That's why it's a good routine for bullets, which usually don't get animated, but not usually a good idea for characters and enemies.


Anyway, about bullets...

The method I use, rightly or wrongly, works this way:
Every bullet has an XPos, YPos, and TargetAngle in its Alterable Values. The XPos and YPos store decimal-point-accurate versions of the object's coordinates, and the TargetAngle is (obviously) the angle that the bullet is firing at. I also make a new Active to keep some values which are global to all bullets, like the distance they jump each loop (the 'Stride' value) and a value called 'Stop'. This last value is either 0 (No) or 1 (Yes). The Stop variable will tell the fastloop to stop, because all bullets have been processed.

I use an infinite fastloop, because I'm silly. Anyway, your loop works basically like this:

Start the Fastloop
Some condition
--- Start Loop 'Bullets' '-1' times (-1 makes it a scary infinite loop. While you test, put a value like 1000 here instead, so if you mess it up you're not stuck looping until Judgement Day)

Tell MMF this will be the last fastloop
On Bullets loop
--- Variables: Set 'Stop' to 1

Move those bullets using trigonometry
On Bullets loop
--- Bullet: Add to XPos variable:
-------- sin( TargetAngle ) * Stride
--- Bullet: Add to YPos variable:
-------- cos( TargetAngle ) * Stride
--- Bullet: Set X Position to value of XPos variable
--- Bullet: Set Y Position to value of YPos variable

Destroy bullets which hit a wall
On Bullets loop
+ Bullet overlaps backdrop
--- Make a spark or something, and a noise
--- Bullet: Destroy

Destroy bullets which hit an enemy
... Use a variation of the previous line, it should be easy to do ...

Check if there are still some bullets left, and if there are, keep the loop going
On Bullets Loop
+ Number of bullets is greater than zero
--- Vars: Set Stop to 0 (Keep the loop going)

If all bullets are gone, kill the fastloop. KaPow.
On Bullets Loop
+ Vars: Stop == 1
--- Stop the Bullets loop.


That should be more or less it. I've not tested the above, so sin() and cos() may be the wrong way round, and there may be some other horrible problem with it, but it's only intended as a guide. The usage of the Stop variable to stop the loop is a little awkward, and not strictly necessary if your loop ends when all the bullets are destroyed like this one does. But I kept it there because it's handy if you need to do a loop which has survivors. MMF is easier at testing whether something IS true, rather than if something ISN'T true, so this is a way I use to get around that. In our case, you could just as easily say 'Have all bullets been destroyed? Stop loop', but where's the fun in that? :p

Anyway, rather than using one loop per bullet, per step, this uses one loop per step, and uses ActionLoops to actually do the moving. So there's the same number of events being run if you fire 1 bullet as if you fire 1000.

Hope that makes sense.

[Kid_Roleplay]

Well, it definitely looks intimidating. Also kind of scared to run an infinite fastloop with math on all bullets appearing when even 100% pure action looped bullets with vector movements causes slowdown.

But will it work as an instant delivery kind of thing?

Also, congrats on ONE THOUSAND posts! *Audience cheers.*

[Konidias]

Dines, it's not too hard to control animation using the swap method. You just store the current frame of the animation in a variable before you change it to the collision animation, and then after you do collision stuff and set the animation back to normal, you set the frame back to whatever stored variable it was.

[Dines]

Hi Konidias I found there were other caveats in practice, but it may be better now, since I haven't tried using the system for anything other than bullets in years I think it tended to mess up animation speed too, if the maximum speed of one animation differed from the other or something, so in the end I just favoured using a detector, and keeping all the different detectors as animations in the detector object. Or something.

Kid_Roleplay: The infinite fastloop only means it won't stop till you tell it to. It basically works this way: Suppose the farthest that any bullet will travel is 500px. You're making your bullets 'stride' a step of 3px on each loop. So your loop will only run 500/3 times (167 times). And as the loop progresses, more bullets are being destroyed as they hit objects, so each loop is faster than the one before it. So maybe on the first loop, you're moving all 200 bullets. But by the time you reach the final few loops, there may well only be one bullet left, so those last few loops will blast through in no time.

But yeah, this method results in instant-hit bullets. Another way you can speed it up is when the bullet is first fired, instead of storing one 'Angle' value, you can store a 'Stride X' and 'Stride Y' value and do the sin(angle)*stride and cos(angle)*stride commands just once when the bullet is first created. Then each loop doesn't have to work out the sin() and cos() functions, it can just keep moving the bullets. This works because the bullets won't change direction in the air, so we can calculate their angles just once and then use the same value on each loop.

If you don't like the idea of an infinite loop, you can tell your loop to run 1000 times. It doesn't matter, because the code will stop it running long before it reaches that amount.

EDIT: OH, and one important thing - if you're using lots of objects, don't forget to increase the maximum object limit in the frame properties. Click the frame, and in the properties window in the 2nd tab (called Runtime Options if you mouseover it and wait for the tooltip to appear), scroll down a little and you'll see it says 'Number of Objects: 500' by default. If you're likely to have more than 500 objects, then increase this to something a lot higher. If you go over the maximum object limit, weird stuff happens.

[Kid_Roleplay]

Yup. I do have a looot of objects, but it only really gets high if something glitchy happens, like if the game randomly decides to trigger every kind of explosion at once instead of just on one target. All of a sudden, it shoots up to like 800 (there's still glitches about).

I think it'd be better if I stick to my projectiles for now. Infinite loops or even a high repetition time per bullet still sounds frightening. I'll just have to add less soldiers on screen at once is all. It takes about fifteen of them all firing at once to slowdown the game anyway, and fifteen is way more than the player should be able to handle anyway, unless they're elite... MOST of the game's slowdown is gone, finally. Though there is still quite a lot of slowdown when I spawn smoke effects (basically, bullets that shoot off in a random direction but grow and shrink and alter transparency values and the like). Even putting those on action loops didn't speed things up, so it seems I've yet another dilemma!

--- Oh, and the angle calculation was made one time only, by the way.