<div dir="ltr">The game I am planning (a space shooter) I wrote a lot in Haskell already and to be honest, the update FPS was fine, in fact I was using the SDL FrameManager to limit it to 60FPS.<div><br></div><div>I see no reason that Mercury's C code should be faster and... part of the attraction for spending all this time wrapping SDL2 in it so far, is the bonus that as I understand it, unlike Haskell, Mercury executes with no laziness afoot so when I call a function, it gets called (predicate reordering notwithstanding), maybe I should say "threaded IO code" runs immediately and also in the order that I write it because of the threading. I amaware of the compiler options to enforce that mode but I want to stay with the default as part of my learning exercise.</div><div><br></div><div>The game per se is almost to the point where I have a vertically rolling star field and a "laser base" that moves left and right and has a working laser cannon...when it's "stage ready" I will shovel a bit of video onto YouTube or something!</div><div><br></div><div>I would like to thank everybody so far, including the other Julian, as well as Zoltan and McDonough/FLyingTHing/Amelia wassname for all your great answers and feedback that have kept me motivated.</div><div><br></div><div>THe long term... I plan to write a simple game (maybe the current one) and then get it onto Android using the NDK route as that is proven ground with the SDL2 library.</div><div><br></div><div>I did consider the Java grade too, which is why I am deliberatly wrapping my own wrapper in another wrapper to abstract away the graphics too! So much to hack so little time.</div><div><br></div><div>I think Mercury could be a viable game writing language.</div><div><br></div><div>Sean.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Aug 2019 at 03:38, Julien Fischer <<a href="mailto:jfischer@opturion.com">jfischer@opturion.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi Sean,<br>
<br>
On Mon, 5 Aug 2019, emacstheviking wrote:<br>
<br>
> I seem to have somehow conflated the use of the state variable form !X<br>
> with the use of the modes "di" and "uo" because so far the the only<br>
> place I have used such notation has been with the special !IO state<br>
> variable.<br>
> <br>
> I now have a game loop:<br>
> <br>
> :- pred game_loop(<br>
>     app_state::di,  app_state::uo,<br>
>     game_state::di, game_state::uo,<br>
>     io::di,         io::uo)<br>
> is det.<br>
> <br>
> game_loop(!AppState, !GameState, !IO) :-<br>
>      :<br>
>      : game state and app state code...<br>
>      :<br>
>     game_loop(!AppState, !GameState, !IO).<br>
> <br>
> This is condensed for clarity(!) but have I understood the concepts<br>
> correctly. My intention is that after one pass of the game loop the<br>
> "old" (di) application and game states can be junked i.e. their memory<br>
> deallocated as the new incarnations are now the current ones, ready<br>
> for the tail-cail back into the next iteration of the game loop.<br>
<br>
In *principle*, that's the idea.  In practice, the current implementation<br>
won't re-use the dead game_state and app_state values there.<br>
(See<br>
<<a href="http://www.mercurylang.org/information/doc-latest/mercury_ref/Limitations-of-the-current-implementation.html#Limitations-of-the-current-implementation" rel="noreferrer" target="_blank">http://www.mercurylang.org/information/doc-latest/mercury_ref/Limitations-of-the-current-implementation.html#Limitations-of-the-current-implementation</a>>.)<br>
<br>
*If* destructive update is important for performance there, then you may<br>
want to consider the use the standard library's store module.  Something<br>
like:<br>
<br>
     :- type app_state<br>
         --->    app_state(<br>
                    thing1 :: io_mutvar(int),<br>
                    thing2 :: io_mutvar(settings),<br>
                     ....<br>
                 ).<br>
<br>
     :- type game_state<br>
         --->     game_state(<br>
                     position  :: io_mutvar(position),<br>
                     inventory :: io_mutvar(inventory),<br>
                     hitpoints :: io_mutvar(int)<br>
                   ).<br>
<br>
     :- pred game_loop(app_state::in, game_state::in,<br>
        io::di, io::uo) is det.<br>
<br>
     game_loop(AppState, GameState, !IO) :-<br>
         ...<br>
         % Remove 10 hitpoints from the player's total.<br>
         store.get_mutvar(GameState ^ hitpoints, HitPoints, !IO),<br>
         store.set_mutvar(GameState ^ hitpoints, HitPoints - 10, !IO),<br>
         ...<br>
         game_loop(AppState, GameState, !IO).<br>
<br>
(You don't necessarily need to use the I/O state as the I have here.)<br>
<br>
Julien.</blockquote></div>