[m-users.] A question about in-place updating...

[Sean Charles (emacstheviking)]

OK, I am now creating flight-path / animation / tweening system, that on every iteration of the game loop, will have to process every single instance of display objects and update their coordinates and set flags, alpha values etc etc. The number of such objects could become high, not punishingly high, for now I can't see it being more than a thousand, even with a primitive particle system generating explosions using texture maps it should not be massively high.

Currently I am just 'making it work', gut I am wondering longer term about what techniques might be open to me in Mercury given that it manages memory, does the garbage collection for me etc. such that I can minimise object allocation etc as instances are updated frame-by-frame.

1) When I use list.reverse(), is it a shallow or deep copy of the original? I am assuming a shallow copy, with may be copy-on-write behind the scenes?

2) If I have a list of say a thousand instances of a tween object, then as I process them, they will need to be updated as I save the current value in the instance along with a done flag, so either the values changes or the done flag changes, either way it means that a new instance will be created. Is there a way to make it so that Mercury can in-place update these instances rather than allocating new ones, so that it reduces memory thrashing and heap activity etc?

It's an interesting question for me to ponder at the moment! Given all that Mercury does, I am guessing that there are no ways to 'pin' a block of memory such that it can then be reused over and over, I have played around with bitmap but that's not really built for generic structures etc. I guess if it came to the crunch I could always re-code those things that need maximal performance in C but that kind of negates the reason I decided to write this game in Mercury.

Thanks,
Sean.