Re: [m-users.] A question about in-place updating...
"Sean Charles (emacstheviking)" <[email protected]>
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 > [email protected] > https://lists.mercurylang.org/listinfo/users _______________________________________________ users mailing list [email protected] https://lists.mercurylang.org/listinfo/users