Confirmed Mount bug leading to drastic slowdown

#1 Dude you only need to post a bug once.

#2 Could you describe exactly what you mean by slowdown? For example, you are basically making an infinite loop here, and doing an action every 2 milliseconds. That in and of itself is going to cause some "slowdown".

At what $Count values do you see the slowdown, and is it progressive, or simply slows down to a lower, but stable performance level?

Finally, you are never wrapping your $Count value to circular clock math, so it's going to become -huge-, and depending on the inner workings of the trig functions, especially if they don't wrap themselves, you are going to have progressive slowdowns for sure. This isn't a bug in TAP/T2D, but in how you are valuing $Count, (edit) and more importantly, the fact that you aren't using clock math to wrap it. Eventually, you are going to be doing something like:

mCos(12345.1)

and that's pretty intensive.

#3

Quote:I have edited the code so that Count wraps at 360

Ok, with that being said, it does sound like a problem either in trash collection (which is possibly basic TAP), or a possible leak in the mount/dismount stuff. Hopefully Melv, or even better someone else here can find it!

If you are feeling adventurous, you may want to enable profiling and see if you can detect where exactly the issue is occuring.

#4 Mount positions are cached and are not destroyed until the object is destroyed. Mounts can be very expensive operations, especially if you have silly amounts of them on lots of objects. The system is not designed for you to continuously mount/dismount objects like you do. Mounting is designed to be a permanent/semi-permanent feature, not something you do ith lots of objects at the rate of 2ms (500 times a second). If you have a need to use an object to do something like this then you need to find a different method to do so.

I can load/save hundreds of small files every ms and things will slowdown. This is not a bug, it's just a daft thing to do. ;)

There could be an option to not cache the results but doing stuff like this will still be slow. Doing mount/dismount hundreds of times a second is a bad thing to do.

- Melv.

#5 Just what kind of overhead ARE we looking at Melv for repeated mounst and unmounts? I do similiar operations in tileIt. Everytime the game board is rotated all the game tiles are mounted, the board rotated, then they are unmounted. I haven't seen any major problems yet but i'm curious if I will in longer games?

#6 I guess my question is that Robert and John are both accomplishing something using mount() that maybe should be implemented with a different technique?

To answer that, it would be important to know what it is exactly from a functional definition point of view they want to accomplish.

#7 @Stephen: If there were a cameraRotate() function then John's usage in TileIt wouldn't be necessary (from my understanding of that whole discussion previously). What he does is to mount all objects to a central pivot point and rotate it so that the game board can be turned 90 degrees without changing the relative positions between objects. The fact that mount/unmount has a problem with this just adds weight to the suggestion I made to add such a function ;^)

There may be another way of accomplishing what John's doing, but the only one that comes to mind is to programmatically determine each object's incremental position. A perfectly valid solution, but not very elegant IMO. If I were put in that position I would implement a cameraRotate() function instead ;^)

I can't speak as for Rob's usage.

#8 @Tim: From what I recall of Johns usage, when he rotated the board, the tiles then fell into empty spaces.

From a technical point of view, rotating the camera is not quite the same. You may be looking at the board from a different angle, but will the direction of gravity have changed to match it? If not (as in the real world) John would need to manually force his tiles to fall sideways into their new positions.

If a rotating camera has the option of changing gravity to match it then things should work out. But it shouldn't be forced. If you wanted to spin the camera around as a fancy effect, you wouldn't want all your game tiles and sprites spinning off into the distance!

#9 Rob ... chill. This is not personal.

Quote:Not critictising, but mounts should be able to be moved around on the fly to be truely useful

They can Rob and not to put to fine a point on it but your code is not helping here. Mounting/Remounting to the same position(s) is fine. Everytime you mount to another position, it creates another mount-node to be reused. In your questionable example, you're using math functions to generate mount-points and each of these, due to precision, isn't the same. You're creating lots of mount-positions here, irrelevant of the rate and each frame they are being recalculated.

Create a set of mount-point or just one and mount/dismount them as much as you like and everything will be fine.

Also, as in the thread I referenced above, you're using mount-coordinates as if they we're world-space coordinates which is again, wrong. Using "- mSin($Count)*8" as a mount-point is telling the object that you want it 8 times the half-size of the object away, which you don't set.

Everything in the world has constraints. How high can you jump? There are constraints in the mounting. They are a valuable feature nevertheless.

Really, if you wanted objects to orbit like this, you wouldn't do it this way. If your game mounts/dismounts to objects then are they to a set of mount-points that are regular around an object? If so, can you precalculate them? If so, then ensure you're using the mounts correctly and select them from a predefined set. This way you don't end up, creating thousands of mount-points.

Quote:I would have thought hierarchical stuff like this would have been flexible. I did not know it was a one shot operation. Thanks for telling me though, and I have now removed mounts from my code completely.

That's your choice Rob but I will not be pushed into making performance decisions based upon how much you shout. The decision are made based upon how we perceive things will be used. If that changes then we can reevaluate that decision. I've just attempted to tell you why T2D is reponding to your code that way it does, nothing more.

This system is here for a reason but it can be used incorrectly and cause problems. It can be changed but your approach to when you get a problem is to post the same thing again and again and get slowly more aggresive. I'm trying to explain how the system is, I'm not ignoring any suggestions here. I cannot change it overnight for you.

Be assured that I take notes on all posts reported in "Report Bugs", even if most of them are people resolving issues in their code.

... and Rob, I'm am trying to help you (seriously I am) but all I can really do is explain the issues in your code and explain how T2D works and hope you get it.

- Melv.

#10 Okay, maybe I misunderstood your tone. I AM trying to help, honest. :)

Okay then..

Quote:* If I can't mount past 0..1 why is it letting me mount past that point?

Well you can do it but in the code you sent me previously (and I've mentioned this so many times now), you use the mount-coordinates as if they we're world-unit coordinates, which they are not. If the size of the object you're mounting to is 10x4 in size then mounting with an offset of "1 1" is "5 2" world-units from the objects center.

Quote:If mounts have a dismount function why have you said it is perminent/semi perminent?

I have explained this about as good as I can above. I can't explain it any better. Mounting was meant for constructing aggregate objects. Ships with guns. Players with shields/arms. Attaching FX to objects. In other words, permanent/semi-permanent mounts. Permanence in relation to the lifetime of the object.

Quote:* I just don't "get" it :)

I know. ;) I just don't know how to explain that there are constraints on features that don't invalid their purpose.

Nothing is fixed in T2D. Things can change but quite often, there are consequences to that change. A change would help you here but would cause problems for a majority of people.

Let me have a final attempt at discussing how it works...

You mount B onto A @ "1 0" (T2D creates a mount-node @ "1 0") - Mount Node #0
You mount C onto A @ "1 0" (T2D reuses the mount-node that already exists which means it only has to calculate one node per-frame) - Mount Node #0
You mount D onto A @ "1 1" (T2D creates a mount-node @ "1 1" which means it now has to calculate two nodes per-frame) - Mount Node #1
You mount E onto A @ "1 1" (T2D reuses the mount-node that already exists which means it still only has to calculate two nodes per-frame) - Mount Node #1

From the above, we've got four mounts but only two mount-nodes are being calculated each frame.

So why don't we destroy these nodes when we "dismount()"? Simple. Currently, T2D passes you back the mount-node index, as does "addLinkPoint()" because they are the same system. If we destroy "Mount Node#0", then the index for "Mount Node#1" is invalid. To get around this, I'd have to provide some kind of abstracted hash so that it wasn't invalidate which isn't a problem but that's more code and a change that needs to be justified.

Having objects where you mount to almost random positions and doing this constantly at a high-frequency is beyond what it was designed to do. In other words, you're hitting a constraint.

I am NOT saying it cannot be changed, I'm just involving you in the reason.

I could've just posted "Thanks for mentioning it. See ya.". ;)

- Melv.

#11 So, back to "what's the best way to do this": I can't remember trig enough to really grasp what the original 'bug example' code does--looks like you are rotating objects a lot, but that's all I get from it!

@Robert: could you describe, in words, the game functionality you want to have in your game that originally lead you to the "random" mount points implementation that we've now seen is probably not the best technique due to mount system constraints?

That way, someone may be able to say, "OHH, that's what you mean--try this {...}", and it may solve all your problems, and/or introduce a new set of thoughts in Melv's head!

#12 For gun recoil... Why not just use an animated sprite?

#13 Harold has a good point (as usual)