[m-users.] di / uo -- some clarification please.

[emacstheviking]

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.

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.

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!

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.

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.

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.

I think Mercury could be a viable game writing language.

Sean.


On Tue, 6 Aug 2019 at 03:38, Julien Fischer <jfischer at opturion.com> wrote:

>
> Hi Sean,
>
> On Mon, 5 Aug 2019, emacstheviking wrote:
>
> > I seem to have somehow conflated the use of the state variable form !X
> > with the use of the modes "di" and "uo" because so far the the only
> > place I have used such notation has been with the special !IO state
> > variable.
> >
> > I now have a game loop:
> >
> > :- pred game_loop(
> >     app_state::di,  app_state::uo,
> >     game_state::di, game_state::uo,
> >     io::di,         io::uo)
> > is det.
> >
> > game_loop(!AppState, !GameState, !IO) :-
> >      :
> >      : game state and app state code...
> >      :
> >     game_loop(!AppState, !GameState, !IO).
> >
> > This is condensed for clarity(!) but have I understood the concepts
> > correctly. My intention is that after one pass of the game loop the
> > "old" (di) application and game states can be junked i.e. their memory
> > deallocated as the new incarnations are now the current ones, ready
> > for the tail-cail back into the next iteration of the game loop.
>
> In *principle*, that's the idea.  In practice, the current implementation
> won't re-use the dead game_state and app_state values there.
> (See
> <
> http://www.mercurylang.org/information/doc-latest/mercury_ref/Limitations-of-the-current-implementation.html#Limitations-of-the-current-implementation
> >.)
>
> *If* destructive update is important for performance there, then you may
> want to consider the use the standard library's store module.  Something
> like:
>
>      :- type app_state
>          --->    app_state(
>                     thing1 :: io_mutvar(int),
>                     thing2 :: io_mutvar(settings),
>                      ....
>                  ).
>
>      :- type game_state
>          --->     game_state(
>                      position  :: io_mutvar(position),
>                      inventory :: io_mutvar(inventory),
>                      hitpoints :: io_mutvar(int)
>                    ).
>
>      :- pred game_loop(app_state::in, game_state::in,
>         io::di, io::uo) is det.
>
>      game_loop(AppState, GameState, !IO) :-
>          ...
>          % Remove 10 hitpoints from the player's total.
>          store.get_mutvar(GameState ^ hitpoints, HitPoints, !IO),
>          store.set_mutvar(GameState ^ hitpoints, HitPoints - 10, !IO),
>          ...
>          game_loop(AppState, GameState, !IO).
>
> (You don't necessarily need to use the I/O state as the I have here.)
>
> Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20190806/4ae36abb/attachment.html>