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

[Volker Wysk]

Am Montag, dem 28.08.2023 um 13:02 +0100 schrieb 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.

What you describe seems to be a case for unique modes. See section 6 in the
Language Reference Manual.

Cheers,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20230828/1f67e6cb/attachment.sig>