Resuming work on Mocha Doom

[Maes]

After my horizons cleared up, I resumed work on Mocha Doom, and started integrating _D_'s changes into it, trying to fix one thing at a time. However, it's going to take some time, because I really think the savegame system needs reworking (it may be a matter of personal taste at this point) and there are many undocumented changes, so I prefer inserting one bug fix/change at a time to my pre-D codebase and see how it works/what it does. Painstaking, but it's for my own sanity ;-)

While _D_'s work is admirable, there are a lot of changes that clash with the codebase's consistency and which will require major rewrites, as well as some internal design decisions which IMO are a bit too premature (e.g. use of Eternity-like rendering variables/flags).

So my priorities for fixes/integration are, in relevant order:

• Graphics (proper scaling of static graphics, status bar, multiresolution support, renderer codebase rationalisation).
  
• Gameplay/actions
  
• Saving/loading
  
• Sound (weak priority, will require changes to other subsystems too)
  

I put actual network playing and applet compatibility off this list for now, also because Applets + direct local file I/O doesn't work consistently across browsers and platforms (this is more suited to a JNLP/Java Web Start approach, like Jake2). The latest submission by _D_ also included exotic stuff like bot code (!) and some feature creeping by Eternity (?), which are a bit far fetched for now to implement.

With those things in mind, expect to see a service/intermediate release in a 2 months period or down that road.

[Csonicgo]

Posting to say awesome, keep it up.

[LexiMax]

Thanks for continuing. Can't wait to see more progress being made on this.

[Maes]

Gameplay integration is progressing smoothly. I have been able to play nuts.wad with the latest official CVS build (some stuff like radius blasts don't work properly though, and revvie missiles do wacky orbits).

However what surprised me was the performance, which was unexpectedly good, better than, say, certain older versions of ZDoom, and almost prboom+-smooth. I am now experimenting with a parallel sorting algorithm to speed up similar maps whenever possible.

Anytime, I will release an intermediate "official" semi-playable techdemo which will allow trying actual gameplay.

[_D_]

Hi,

Don't hesitate to ask your questions when you don't know what the code do.

I almost copy/pasted linux doom source code, and also *Doom Legacy* (not ethernity) source code. So you have those references.

The game load/save should of course be recoded (though it already works, except the part on special I was too lazy to do it in case you would want to recode it anyway lol). The probleme there is I found the CachableDoomObject interface with unpack() function, but there was no pack().

If you have difficulty to see what I had changed in your code, your best bet is to Diff (Synchronize with repository) the two projects in Eclipse.

For the Revenant rocket bug: just copy my Actions.A_Tracer function, I had corrected it. This is because in "(exact - actor.angle > ANG180)", you are substracting two long, so the "unsigned int overflowing" was not working. I replaced those kind of lines by "(((exact - actor.angle)&BITS32) > (0x80000000 & BITS32))".

Oh by the way, I had changed the PIT and PTR switch for interface calling (function pointer), and it is *not* slower. It is faster to call a function pointer than checking 10 IFs in a switch.

[Maes]

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.

[shadow1013]

ummm although i doubt it will help much im currently working on a couple of classes to play mus files.

[Maes]

shadow1013 said:

ummm although i doubt it will help much im currently working on a couple of classes to play mus files.

It's my duty to inform you that _D_ has actually implemented a MUS2MIDI converter for Java (which I will merge with the main codebase) but I still think it would be nice to have an alternate implementation handy, just in case, so I won't discourage you from continuing your work. Just FYI, it's based on the classic MUS2MIDI utility for DOS.

Upcoming version 1.4 looks very good so far (some of the things coming are adaptiveness, savegames, proper scaling, proper endings, support for TNT/Plutonia/Ultimate Doom, selectable resolution, etc.) but I won't be adding sound and/or socket networking until the next major release, so take it easy. If you need more information please feel free to PM me.

[Swiss_Cheeseman]

Just wanted to say that I think this project is really neato. Just some words of encouragement :)

[mr fiat]

I hope version 1.4 comes soon I like the idea of mocha doom keep it up :D

[Maes]

mr fiat said:

I hope version 1.4 comes soon I like the idea of mocha doom keep it up :D

Ehm... 1.4 is already out :-) Although I'm working on an improved version with sound, gamma settings and some misc. fixes ...probably 1.45 or straight 1.5 ;-)