Sure, the low-level mechanisms for actually gathering the input are different, but the rest of the engine is not supposed to care about that.Īfter studying the initial release, and then all the various ports, the D_DoomLoop function is slightly different in all of them. But I'm left with wondering: How does vanilla get away with not needing it, as it's calling the same high-level functions to poll for input, write tic cmds, etc. This would ever so slightly change the vanilla behavior but would allow for a consistent experience across all operating systems Chocolate Doom can run on. Perhaps when you use the -record feature the engine should start with a special tic -1 that draws the initial setup of the map for the melt effect, but doesn't actually run any thinkers or player input or begin the gamesim until the melt finishes. I know that in vanilla Doom the melt effect is basically its own loop that nothing else in the engine (including player input) interacts with, but couldn't Chocolate Doom change that and watch for input during the melt?Įdit: I suppose I am discounting that tic 0 has to be completed before the melt even begins because otherwise the game will have no idea what it is supposed to be drawing. Since Doom has the melting screen effect, it seems like you ought to be able to queue up a command while the melt is happening and instantly apply it on tic 0. Isn't this what we're talking about? And, because it's difficult to debug vanilla, it seems to me that using and verifying demos is a decent way to get tic-level, input command debug information out of the vanilla engine, in a format that can be directly compared to Chocolate. Vanilla.LoadDemoCmdCount = Chocolate.LoadDemoCmdCount.Īt this stage, from the reported bug above, I cannot claim to know which of the statements I list are not true. Vanilla.SaveDemoCmdCount = Chocolate.SaveDemoCmdCount, and Vanilla.InputCmdCount = Chocolate.InputCmdCount, InputCmdCount = SaveDemoCmdCount = LoadDemoCmdCount. So, I think the first step is to be able to determine if this statement is true:
My theory is that, if working properly, InputCmdCount = SaveDemoCmdCount = LoadDemoCmdCount.
Likewise, in demo playback, X number of cmds should be able to be applied, before the 3D screen is visible. So, if a given engine can queue up InputCmdCount number of cmds before showing the 3D view, a demo recording should also be able to store X cmds, before the 3D screen is visible. Stated differently, there are X chances for input, before the 3D screen is visible. Reading demo bytes is roughly equivalent to reading inputs - these actions should occur at roughly the same point in time, during execution. The theory is that if an engine can queue up inputs, and apply them in tics, surely it can store them in the demo. Any input events recorded in the first tics of a demo get properly replicated on playback in Chocolate Doom. Modern OSes and Chocolate Doom don't really have a way to replicate this, though there are suggestions of adding an artificial delay to starting up Chocolate to emulate it a bit.ĭemo compatibility is unaffected.
The "problem" is basically just that you can queue up input events while the game loads (eg, the text loading screen), that get sent immediately when the game starts.
0 kommentar(er)
