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

[Sean Charles (emacstheviking)]

OK, thanks for the tip off Julien.

I will just carry on as I am for now, I don't think it will be that much of an issue. Most of the things I update on every iteration of the game loop are probably going to change anyway, so in terms of memory churn, although the churn is a constant, it is also a constant... most of the entities have a clock value in them which is updated by the frame time, the tweens, timers etc, so internally, one array will be collected on exited and a new one created. That's as a clean as it can get I guess.

My game isn't an AAA FPS, it's a lowly proof-of-concept 2D space shooter (call me old fashioned) and I am doing it to create a 2D graphics engine which I will then extract and that is the core engine of my IDE for my transpiler. That's the plan so I figured writing a game would provide sufficient joyful motivation to get the job done.

Thanks all.
Sean


> On 29 Aug 2023, at 03:58, Julien Fischer <jfischer at opturion.com> wrote:
> 
> 
> On Mon, 28 Aug 2023, Volker Wysk wrote:
> 
>> Am Montag, dem 28.08.2023 um 13:02 +0100 schrieb Sean Charles
>> (emacstheviking):
>>> 
>>> 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.
> 
> In princple, yes. In practice, the limitations listed in section 6.3
> mean they're not really useful for that purpose.
> 
> Julien.
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users