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