Intro

Table of Contents

This is part of a series where we’ll be writing a roguelike using FRP and Haskell. This article is about setting up the main loop and rendering.

This version of the article uses SDL2 for the gelatin backend and only addresses the differences between GLFW and SDL2. Please see part one for thorough tutorial.

Get the Code

This is a Literate Haskell file which can be downloaded from the github repo. To build, run stack build from the project directory. Go here for help with stack .

Main

For the SDL2 version our imports are identical except we switch out the backend. You can see that SDL introduces some conflicts with Control.Varying that we need to work around using qualified imports and hiding.

Everything else here is business as usual :)

Types

The only changes needed here are a couple additions to our UserInput . We have to encode a bit more window handling for SDL2, which is neither good nor bad. On the good side it makes window handling explicit instead of GLFW’s convenient but mysterious windowShouldClose function.

All other type level stuff stays the same for our refactor.

The Network

Here you’ll see there are absolutely no updates to our network. This is great! We’ve organized our code so that the network only depends on game events and in this kind of situation we get to reap those benefits … by doing nothing at all. Score one for FRP and Haskell in general.

Our Game Loop

Most of the changes happen in our main loop. Window management is a bit more complicated, but not bad. Most of our setup is the same.

One expected difference is in how SDL2 handles input. GLFW allows you to set a callback and then waitOdin for events to come in, keeping you from having to poll. GLFW could be polling under the hood, but with SDL2 that polling is explicit.

Instead of using callbacks we’ll write a function that handles our special input cases or simply push s our input. The special case to handle is when the window manager requests that the window should close.

All other input can simply be pushed into our queue.

Instead of callbacks we need a function that unwraps SDL events and turns them into our game events. You’ll see here that SDL gives us much more information than GLFW. Most of this function is unwrapping the event. We return a list so we can concatMap this function over all of SDL’s events in one fell swoop.

Now we write our own version of GLFW’s waitOdinEvents function. This function reads our app’s event queue - if any events have been added from any other threads (like a timer/render request thread) it will exit. If there are no events in total we should delay for ten millis and then loop. In this way we can “put the main thread to sleep” and defer rendering until something happens. Not quite (we’re still running the thread and polling) - but good enough. In both cases we poll for SDL events and run addInput over any newly received events.

Our stepOdin function is near identical to part one but we need to swap renderWithGLFW with renderWithSDL2 .

In applyOutput we have to push an event in order to get waitOdin to find a new event in its queue. This will cause waitOdin to break and then loop will stepOdin . We can use a simple InputUnknown as the event.

Then we stick our waitOdin function in place of GLFW’s waitOdinEvents .

Conclusion

To recap, we updated our UserInput type, made slight changes to rendering and switched out the way we poll and add input events. What changed from a player perspective? Hopefully nothing! If you ran the two programs side by side you would notice some differences. The first is that the GLFW version has nicer edges on our circle. This comes from the fact that I’m not quite sure yet how to query the framebuffer size in SDL, so my SDL backend for gelatin (which provides ctxFramebufferSize ) just returns the window size. This is fine unless you’re on a retina or 4k screen. Another difference is that we’ve lost the ability to quit with Command+Q or Ctrl+Q. Fixing that is easy enough and we’ll fix it later in the series.

All in all this refactor ended up being pretty easy. This is one of the strong points of Haskell. We just swapped out the entire windowing system and OpenGL context underneath our app - in under an hour. Truth be told, it took me a bit longer to research the SDL API, write the gelatin backend and to write the article but it was still an insignificant amount of time. Another major plus is the total absence of fear during refactoring. At no point was I afraid I would edit myself into a corner and have to git stash; git drop my changes and restart. That happens to me sometimes in lesser typed languages, but Haskell’s type system is a real friend.

Please comment at HN or Reddit