<Promit> so, let's say i'm running two threads, one is rendering and one is updating junk
<Promit> should the update thread run as fast as possible?
<Promit> or should i clamp it to some max frequency?
<sirob> I'd use a fixed frequency
<sirob> ala XNA
<Promit> in that case, should the renderer be interpolating values?
<sirob> I think I'd just use a frequency high enough so it doesn't matter. Say, 100hz
<sirob> interpolating at that freq would seem a bit useless :-/
* LtJax (Jax@HSI-KBW-091-089-006-126.hsi2.kabelbw.de) has joined #graphicsdev
<Promit> well i was thinking the game update generally runs slower, not faster
<sirob> that would depend on your FPS :)
<Superpig> I'd have it run as fast as possible, but using a fixed timestep
<Superpig> if you can generate the next few seconds worth of simulation in half a second, great
<sirob> what happens when the workload increases?
<Superpig> makes no difference
<sirob> your game would go into slow-mo
<Superpig> no it wouldn't
<Superpig> I said you use a fixed timestep
<Superpig> you generate snapshots of render data at t=0, t=1, t=2, t=3, etc
<Superpig> interpolate between them
<sirob> yeah, but you use the smallest possible timestep
<Superpig> you don't /have/ to
* vox has quit (Ping timeout)
<Superpig> you could write half-decent integrators instead
<sirob> So you plan to predict how updates would look x time into the future?
<Drilian> No, you're just one frame behind.
<Drilian> render-wise
<Drilian> It's not noticeable.
* vox (denis@voxelsoft.com) has joined #graphicsdev
<Superpig> actually, I /do/ plan to predict how updates look x time into the future
<Superpig> but yeah, you can ignore everything after the next frame's data
<sirob> then why generate it?
<Superpig> because you don't have to ignore it
<Superpig> you could use it for useful things instead
<Drilian> i.e. AI prediction models
<Superpig> more importantly
<Superpig> it helps you amortize your workload
<Drilian> Though having an AI based on something that may or may not be there is not a good idea :)
<Superpig> it's probably faster to generate three frame's worth of data for one thing than it is to generate one frame's worth of data for three things
<sirob> hmmmm, this is interesting. So how do you handle user input?
<Superpig> Drilian, can you say "reaction times" ? :)
<Superpig> sirob: you do find yourself throwing away calculated data in response to user input, yes
<Superpig> but truth be told
<Superpig> user input doesn't affect very much
<sirob> for the whole scene?
<Superpig> no
<Superpig> for affected entities
<Drilian> Player's input also changes alot less than 60 times per second on average.
<sirob> you need to redo collisions?
<Superpig> sirob: yes
<sirob> damn, I need to go. I'll be back in like an hour, I guess.
<Promit> so...you should probably clamp how far ahead the update gets, right?
<Superpig> yes
<Superpig> if you've generated more than, say, 10 updates ahead, you can sleep
<Superpig> or you can dedicate the time to other things... like going back and generating extra data between the timesteps
<Promit> so if you've updated up to time t, and you're rendering t - 4 when an input comes in, then ideally t-3 would reflect that
<Superpig> yes
<Promit> so you need to back up to t-3 and re-run partial updates?
<Superpig> yes
<Promit> and those updates will cascade through all the future update frames
<Superpig> yes
<sirob> Sorry, apparently I didn't have to go yet :-/ So how would you store different time-slices?
<Superpig> it's basically a memento pattern
<Superpig> each object generates the minimal data needed to render it at a given time
<Superpig> position, orientation, animations and blend weights
<Superpig> say each object has a linked list of those attached
<sirob> ah, that's interesting.
<Superpig> when it comes to rendering, you find the two snapshots that are either side of your 'render time'
<Superpig> and interpolate between them
<Superpig> obviously, you need to be careful about synchronisation
<Superpig> but in general the locks are very small
<sirob> How do you handle physics in this? I don't see this integrating well with a prewritten engine
* quak (unknown@Uf389.u.pppool.de) has joined #graphicsdev
<Superpig> you need to save the data necessary to restore your physics sim as well
<Superpig> and no, this doesn't integrate well with a prewritten engine
<Superpig> you don't try and bolt multithreading onto something that wasn't written for it
<Superpig> (well, you might try, but it won't end well)
* string has quit (Quit)
<Promit> well you would have to reset the entire physics state backwards
<Promit> and doing that cleanly will be a pain
<Superpig> you might not need to
<Superpig> you only need to do things that are nearby, for example
<Superpig> in fact, do you even need to do that, I wonder...
<Superpig> you might be able to test against the generated snapshots
<sirob> btw, the memento pattern has a very cool name :)
<Superpig> hehe
<sirob> I don't see how keeping data into frames not yet displayed relates to multithreading, I mean, you could just as well not generate the data in advance and avoid problems with the physics engine
<Superpig> because it avoids sync issues
<Superpig> it means that the renderer is never waiting for the update thread
* vox has quit (Ping timeout)
<sirob> hm, but in all practicality doesn't just calculating say, one frame ahead, avoid most such syncs?
<Superpig> well, yeah, you /could/
* RickA (chatzilla@dhcp0441.gradacc.ox.ac.uk) has joined #graphicsdev
<Superpig> but what's your update thread going to do the rest of the time?
<Promit> read a book?
* vox (denis@voxelsoft.com) has joined #graphicsdev
<Superpig> :P
* quak has quit (Quit)
<Superpig> having data about what is /going/ to happen is just generally a good thing
<Superpig> you can do things like preloading resources
<Superpig> make your AI look smarter
<Superpig> etc etc
<sirob> well, how far ahead are we talking here? frames? seconds?
<Superpig> depends on your situation
<Superpig> the last time I implemented this it was just a couple of frames
<Superpig> if you do it longer you could, for example, start spinning up the game disc to play some music or something
<Superpig> because you know that the player's going to hit a music trigger in a little bit
<RickA> ooh, this sounds interesting
<sirob> sounds like too much work :p
<RickA> anyone got a log of the start of the conversation?
<RickA> oh, and hi btw :D
<sirob> yeah, lemme post it.