Ask me about my source port
If you can maintain 100 fps, that's great. I suppose I should pull out my Visual Basic reject builder code. It's reasonably fast considering - naw, it's slow. The first version used raycasting, and was sectors * sectors * lines * lines * traces. The latest version uses intersection of a plane code, eliminating the traces, but requiring slower math. Problem is, it's married to another project at the moment.
Graf Zahl said:
...Caverns of Darkness...
Awesome! Here's how to found the remaining desyncs:
If you mean compatibiliy with vanilla demos, there's a partial one: some play back just fine, others (most of them) desync. Some "known good" ones are DEMO2 and DEMO3 (and maybe DEMO4?) from Ultimate Doom. I think a couple from Final Doom also play back correctly.
However, unless I figure out what's precisely causing the desyncs at certain points (the actions of certain monsters? the movement of certain monsters? A call to P_Random too much? A small error with my integer-wishing-it-was-fixed_t arithmetic?) I can't do much. Who knows.....if I could make a proper test map that isolated certain kinds of causes, then maybe.
The only clue I have so far is that, with a -nomonsters map with the player just navigating it (recorded in vanilla doom), so far I couldn't induce desync. With monsters present, it's just a matter of time, but not always. I can't reconduce it positively to one kind of monster or action yet.
1. Open PrBoom+ source
2. Find every instance of P_Random(). Add a unique number to every instance: P_Random(22).
3. Modify P_Random to accept the number, and append it, the random number, and the random index to a file: "PR 22 1 252".
4. Modify TryRunTics to write gametic to the same file.
5. Modify XYMovement to write doomednum, x, y, z, momx, momy, momz to the same file.
6. Compile. Run it against failing demo. Save file.
7. Make the *exact* same changes in your port, to the end that it produces an identical file. EDIT: (be sure to use corresponding integers for your P_Random calls!) Run failing demo on your port. Compare.
This will give you at least some of the following information (9 times out of 10):
. The actual function that's incompatible
. The tic that deviates
. The type of monster
. Possibly exactly what's wrong
I used that to discover and fix a great many desyncs from a project that I had been recklessly modifying for over a year with disregard for demo sync. It now plays most vanilla demos. Good luck!
EDIT: If you're interested, I could probably post my "syncdebug.txt" file from my port, running against a demo of your choice. Of course, you'd have to pattern your files and P_Random integers exactly as I did. If so, please create a new thread, and let me know.
Last edited by kb1 on Oct 25 2012 at 21:34