Functional GLUT?

Question

I learn a bit of functional programming in the Gambit-C Scheme, limiting myself to not using set !. I thought it would be interesting to write a small OpenGL game using this environment, which seems to be well suited for game development.

However, it seems difficult to maintain a functional style and avoid a global state when using OpenGL and GLUT. I don't think this is a fundamental limitation of game programming, in fact, but a callback based API like GLUT does not seem to work with functional programming.

For example, I am trying to imagine the world as a stream of mutating state vectors, which is a function of an alternating list of time events and input events. This idea seems to be in order, but with asynchronous programming, it does not seem to go easy. For example, I have to register a callback for the GLUT mapping function, which must somehow have access to the "current" element in this thread. Meanwhile, there is nothing to drive the stream forward, taking from it.

Ideally, I need something like the “outside” of GLUT, the main function that somehow depends (possibly monadically) on the various GLUT functions that were executed at some point. How can I create this style of a game engine around GLUT, or another way to ask how I can most successfully isolate GLUT from my engine? Is it possible for GLUT to generate such a striped list of events for an external procedure? How does Haskell handle this, for example?

Answer 1

It will be very difficult for you to implement a functional graphics system. Even Haskell bindings to GLUT use imperative programming through the IO monad. The closest I heard from what you are trying to do is Functional Reactive Programming , but the libraries are not ready for downtime, time, and there is a serious lack of textbooks for the real world.

Answer 2

You can look at the FieldTrip library for some ideas on functional graphics.

Answer 3

This is pretty fundamental for a state machine, such as openGL, that has state!

I don’t see how you can have free functional programming with a side effect when a side effect draws a collection of materials on the screen.

Answer 4

Having written this question, I thought a little about it, and I begin to wonder if the answer lies in the use of shared procedures. If the game is a functional collaborative procedure that is triggered by inactive and displayed GLUT calls, this very well separates the game logic from the GLUT architecture. For example, it is very likely that a set! cannot be avoided, but if GLUT callbacks are used! just to change the flow that is fed into the joint procedure, it can create a very nice border. Any thoughts on this? I will need to get more experience with the joint lessons before learning more.