[Haskell-cafe] threadDelay granularity
Peter Verswyvelen
bugfact at gmail.com
Tue Apr 7 12:37:51 EDT 2009
yes "get time" comes from GLFW; that is get comes from OpenGL, time from
GLFW.
I think the time provided by GLFW has a very high resolution but is not very
accurate in the long run, which is not a real problem for games I guess
On Tue, Apr 7, 2009 at 6:09 PM, Duane Johnson <duane.johnson at gmail.com>wrote:
> The Hipmunk 2D physics engine comes with a "playground" app which includes
> the following function:
>
> -- | Advances the time.
>> advanceTime :: IORef State -> Double -> KeyButtonState -> IO Double
>> advanceTime stateVar oldTime slowKey = do
>> newTime <- get time
>>
>> -- Advance simulation
>> let slower = if slowKey == Press then slowdown else 1
>> mult = frameSteps / (framePeriod * slower)
>> framesPassed = truncate $ mult * (newTime - oldTime)
>> simulNewTime = oldTime + toEnum framesPassed / mult
>> advanceSimulTime stateVar $ min maxSteps framesPassed
>>
>> -- Correlate with reality
>> newTime' <- get time
>> let diff = newTime' - simulNewTime
>> sleepTime = ((framePeriod * slower) - diff) / slower
>> when (sleepTime > 0) $ sleep sleepTime
>> return simulNewTime
>>
>
>
> I think the "get time" is provided by GLFW.
>
> -- Duane Johnson
>
>
>
> On Apr 7, 2009, at 9:25 AM, Ulrik Rasmussen wrote:
>
> On Tue, Apr 07, 2009 at 04:34:22PM +0200, Peter Verswyvelen wrote:
>>
>>> Do you want to cap the rendering framerate at 60FPS or the animation
>>> framerate?
>>> Because when you use OpenGL and GLFW, you can just
>>>
>>> GLFW.swapInterval $= 1
>>>
>>> to cap the rendering framerate at the refresh rate of your monitor or LCD
>>> screen (usually 60Hz)
>>>
>>
>> I just want to cap the rendering framerate. The game logic is running in
>> other threads, and sends rendering information via a Chan to the
>> renderer.
>>
>> I'm using GLUT, and have never heard of GLFW. However, that seems to be
>> a better tool to get the job done. I'll check it out, thanks :).
>>
>> /Ulrik
>>
>>
>>>
>>> On Tue, Apr 7, 2009 at 1:41 PM, Ulrik Rasmussen <haskell at utr.dk> wrote:
>>>
>>> Hello.
>>>>
>>>> I am writing a simple game in Haskell as an exercise, and in the
>>>> rendering loop I want to cap the framerate to 60fps. I had planned to do
>>>> this with GHC.Conc.threadDelay, but looking at it's documentation, I
>>>> discovered that it can only delay the thread in time spans that are
>>>> multiples of 20ms:
>>>>
>>>>
>>>>
>>>> http://www.haskell.org/ghc/docs/6.4/html/libraries/base/Control.Concurrent.html
>>>>
>>>> I need a much finer granularity than that, so I wondered if it is
>>>> possible to either get a higher resolution for threadDelay, or if there
>>>> is an alternative to threadDelay?
>>>>
>>>> I noticed that the SDL library includes the function "delay", which
>>>> indeed works with a resolution down to one millisecond. However, since
>>>> I'm using HOpenGL and GLUT, I think it would be a little overkill to
>>>> depend on SDL just for this :).
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ulrik Rasmussen
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090407/32f30325/attachment.htm
More information about the Haskell-Cafe
mailing list