🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Inertia

Published May 02, 2006
Advertisement
I've sort of been posting a fair bit in here lately, so I figure it'll be easier to keep posting regularly than to go back to posting rarely but with massive entries. At least, that's what this guy Newton keeps telling me - insists it's some kind of law, even. Dunno. I'm not sure I really believe him, seeing as he looks to have been dead for a while.


The cutscene engine stuff continues to go well. I've nearly finished the data loading/representation side of things - the bit where you actually have running code that is storing the runtime manifestation of a cutscene. Basically, it's the input half of the wood chipper: it funnels the wood down towards the swirling blades, and sets off the little warning light if the sensors detect an abnormally high human-arm-to-wood ratio.

OK, maybe that's a bad analogy.


Once all the data structure stuff is done, the next step is to make a few passes over the in-memory "live" data and simplify some timing information. Specifically, the cutscene data format lets you control timings based on the timings of other stuff - so for instance you can have a shot of an exploding freighter that automatically cuts in when the explosion starts, then automatically cuts back to whatever was going on before after the debris cools a bit. You can also trigger a sound effect to play after the third shot transition in a particular scene, and so on. Basically it's just a framework for coordinating timings.

Essentially, what needs to happen is the cutscene engine has to go through these implicit timing references and turn them into hard-and-fast numbers. That way, when the rendering code comes through each frame, it can say "hey look, this event was supposed to begin at 458 milliseconds, and it's now 473. Time to start that event, and maybe fudge it a bit to make up for lost time."


I fully expect the timing resolution stuff to be ugly and messy. I haven't really had much of a chance to plan out the logic side of it yet because I realized last week that I needed to get the data into memory first and then worry about how to traverse it and compute timings. In reality, I suspect that it'll be a lot easier than I think, but it never hurts to be careful - I'm assuming a worst-case scenario and estimating it'll take a couple of days to plan and code the timing logic.

After the timings are done, the next phase is to put in dummy rendering hooks. For the moment they'll just draw little colored boxes to show where things might actually go in the final render. That'll be enough to help get the content creation team introduced to the system, so once that is finished, I'll be putting out an XML schema for the cutscene data, updating the team wiki a little bit, and then sending out a sort of "alpha build" of the whole system.

It might be a little optimistic, but I'm hoping to get all this finished by the end of the week, or at least by Saturday, because after that it's E3 and I'm sure as liver juice not taking work to E3 [grin]



Haven't looked at Milton again since the other night; I did end up staying up a little later than I'd planned and hacked out a couple more tweaks, including fixing the CD drive issue (just needed to hack a quick insmod into the init.d scripts). I would have liked to have had the wiki up for Epoch by the time I leave next Monday, but I don't see that happening, especially not with the broken port forwarding on my router (which still perplexes me quite a bit).

Not sure I'll have the motivation to do much more with that this week, but we'll see.
Next Entry Triumph!
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement