Maes
I like big butts!
Posts: 8664
Registered: 07-06 |
I am continuously fixing stuff, even as we speak, now that I have some time.
In the upcoming version, I have implemented proper speed throttling via TryRunTics (that damn ticcmd_t packet bug....heh), demo playback/recording, and even Game LOAD functionality though a wholly new system of interfaces, which can be extended to load any type of savegame.
As a challenge, I tried to replicate Vanilla doom savegame loading exactly, and I managed to make it work. I used the IReadableDoomObject interface for that (with hierarchical calls to each object's read(DoomFile f) method) and I implemented just the stuff that vanilla read/wrote, but OFC it's possible to provide different implementations.
The new stuff is in package savegame, as IDoomSaveGame, IDoomSaveGameHeader, VanillaDSGHeader and VanillaDSG, with obvious meanings. Of course, it's possible to define other types of savegames. The only common thing between them is that they need access to the global doom status, level loader, map objects etc.
It has now almost perfect binary compatibility with vanilla savegames (on loading), and I even managed to reconstruct proper infighting targets by un-hashing the stored raw pointers. Yup, Mocha Doom actually loads vanilla savegames BETTER than vanilla Doom itself does ;-) Now I also gotta implement saving, also vanilla compatible.
As for the PIT/PTR stuff...well, eventually I will move on to them, after all I already use "functors" for the rendering subsystem, which is far more time critical. My tests showed that there IS a small speed difference (at least using a special tester that does 100.000.000 test calls, in testers package) And there's maybe a 10-20% difference but that's for a switch of only 2-3 options though, probably you're right in that it doesn't scale up all that well for 10+ options.
It would be cool to have proper action "pointers" too, but I will need to have every mobj_t being aware of Actions instance "A" (which they already are), and, more importantly, to change the way "functors" are assigned to map object types. Probably a good solution would be to dynamically link them when they are placed on the map, rather than use the static mobjtype_t enum... we'll see!
I also fixed the revenant missile bug, definitively fixed the think_t enum (now all entries have an assigned acp1 or acp2 type), and improved compatibility with handling TNT/PLUTONIA/Ultimate.
The only problem with doing side-by-side checks with your code is that there are so many other changes that most source files are now completely misaligned, however I manage to find your comments and notice most big things, luckily. :-p
Again, I must thank you for keeping the project from stalling while I had more pressing things to handle :-)
p.s.: another important change is that now finetangent overflows are eliminated by extending the table to 8K entries, and partially copying the finesine table over the extra 4K spaces (just like vanilla Doom). This gives some extra "overflow compatibility" and eliminates the need for explicit checks or bit cutting. Still, it would be MUCH better if Java had a proper unsigned int type which would avoid all that type fucking up with longs etc.
Last edited by Maes on 05-21-11 at 16:51
|
05-06-11 14:14 
