more haskell 3d rendering
oh yeah i guess i should make a proper reportback
the problem with working on javascript games is i immediately want to work on 3d stuff, and i don't really want to work on 3d stuff in javascript. so for this 2-week project i ended up recoding a bunch of my haskell game code to be simpler and more robust. well, 'more robust' is still up for debate i guess.
this time i actually posted the code, although it's not really in much of a state to use yet.
at first i looked at a few other FRP libraries to see if anything was better than
so i ended up removing all the FRP code and just writing my own input/render/physics loop with no library help aside from some TVars & TChans. this, in turn, ended up simplifying my state & rendering code a lot, since a big part of getting that to work with my other haskell project was managing the render updates within the game state, since all that ran in IO and not the GLFW gl context monad.
(the rough concept for this 'engine' was something based on breath of fire 3 or 4, with free movement and maybe some light platforming. i didn't get around to getting the platforming part working since i stopped around when i needed to start doing collision detection, but this turned out well enough that i'd like to revisit it again in the future and actually try to put together a simplistic game out of it.)
the problem with working on javascript games is i immediately want to work on 3d stuff, and i don't really want to work on 3d stuff in javascript. so for this 2-week project i ended up recoding a bunch of my haskell game code to be simpler and more robust. well, 'more robust' is still up for debate i guess.
this time i actually posted the code, although it's not really in much of a state to use yet.
at first i looked at a few other FRP libraries to see if anything was better than
reactive-banana, but ultimately i came to the conclusion that i think FRP is a poor suit for real-time game programming -- yampa or dunai, two other haskell FRP libraries, seem to be designed for physics use since they have more involved timing-based continual integration code, which is neat, but the task of saying "i have certain code i want to run normally, and different code i want to run when a menu is up" seems near-impossible, so while it might be a good suit for using in my 'physics' update, it seems like a bad choice for handling basic event IO.so i ended up removing all the FRP code and just writing my own input/render/physics loop with no library help aside from some TVars & TChans. this, in turn, ended up simplifying my state & rendering code a lot, since a big part of getting that to work with my other haskell project was managing the render updates within the game state, since all that ran in IO and not the GLFW gl context monad.
(the rough concept for this 'engine' was something based on breath of fire 3 or 4, with free movement and maybe some light platforming. i didn't get around to getting the platforming part working since i stopped around when i needed to start doing collision detection, but this turned out well enough that i'd like to revisit it again in the future and actually try to put together a simplistic game out of it.)
