I sort of understand what people are getting at.
My basic question is now, given that I have a bunch of parameters that represent state should I bundle up ALL of these parameters in one data type (DemoState, say) and have ONE IORef variable that references the lot, or have an IORef for each piece of state, separately.
What are the disadvantages of each approach?
Also, is reading and writing to an IORef expensive computationally?
Thanks,
Mark
On 05/04/2010, at 2:25 AM, Tobias Brandt wrote:
HOpenGL uses Data.StateVar. One can define the following function:
newStateVar :: a -> IO (StateVar a)
newStateVar val = do
ref <- newIORef val
let readAction = readIORef ref
let writeAction = \newVal -> writeIORef ref newVal
return (makeStateVar readAction writeAction)
Now one can use StateVar consistent with HOpenGL:
create: foo <- newStateVar bar
read: get foo
write foo $= baz
On 4 April 2010 11:03, Mark Spezzano
<mark.spezzano@chariot.net.au> wrote:
Hi
What is the correct way to record "custom" state when using OpenGL?
By this, I refer to, say, properties of a square--say it's x,y coordinates as it moves across the screen. This requires that the program keep track of the object's state as it moves. These coordinates are _not_ part of the OpenGL state machine, so is the correct way to use the State monad?
If so--or if not so--how would I proceed to keep track of the state of my objects as they move about the screen? Maybe the HOpenGL implementation comes with such state-tracking devices?
Please post code snippets if necessary.
Thanks in advance,
Mark Spezzano
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe