[Haskell-cafe] Correct way to record state in OpenGL?
mark.spezzano at chariot.net.au
Thu Apr 8 10:43:09 EDT 2010
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?
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 at chariot.net.au> wrote:
> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe