Mocha Doom: vanilla with some coffee ;-)

[Maes]

Relese early, release often, they say...

So far I've only hinted at me working on a Java source port of Doom,
which as I've written time and again, seems to be a programming Columbus Egg or Holy Grail of sorts, and none ever quite pulled it, let alone that all known projects either started with the wrong foot, are hoaxes/fakes/recreations. For that matter, none has ever pulled a source port of Doom in a language that was not C or C++ (with the notable exception of DelphiDoom, which however maps almost 1:1 to C).

Yes, I know it's possible to make a Doom-like 3D engine in Java (there are several proof-of-concept applets out there). Yes, it's possible to rip some resources from Doom or slap the name "Doom" over a generic 3D Maze/Wolf 3D engine. But so far, none has made a REAL source port in Java. One that uses only the IWADs and eventually PWADs for its resources, according to my "purist" definition of source port. There are several reasons as to why, but they're not to discuss right here and now.

THE GOAL: Make a playable, reference pure Java implementation of the GNU Doom source code with the ability to use real IWADs and PWADs, save/load games and play demos, and replicate the internal workings of the Doom engine itself as much as possible. Also, define a more OO API for Doom's code, departing from the traditional (and hacking) pseudo-OO/semi-procedural model of the original source code and making it into something more suitable for Java and perhaps other languages. I'd like this to be a sort of "stepping stone" for other projects and non-C languages as well, but maybe it's still too early :-p

WHAT IS NOT A PRIORITY:

• Applet form. I'd go for a standalone Java application first, then (hopefully) exploit the modularity to "appletized".
  
• Sound. I'll leave this one for last, and then I will only try to use pure Java libraries. In theory, it should be possible to thrive only on java's sound playing abilities (which now include MIDI) and there are some pure Java OPL3 emulators too...but as I said, not a priority.
  
• Working around inherent vanilla limits/premature optimizations. Once the thing works, then I'll consider making a limit removing/advanced port out of it. For now I'd be happy with near-vanilla compliance.
  
• OpenGL. This will require studying actual OpenGL source ports and using platform-specific extensions to Java, and may be part of some future branch.
  

Fact is, this last month I've been tinkering on-and-off, converting a few functions here and there, studying the code to understand how the data structs are supposed to work, and how they could map to an OO paradigm. I had made a similar (false) start 2 years ago but I had to interrupt because of the army.

Anyway, at a certain point it "clicked" to me that, yeah, perhaps this is actually viable:

• WAD loading works. Parsing binary blobs into well-behaved objects is possible.
  
• Fixed point arithmetic works viable, and benchmarked almost on the par with C (using gcc).
  
• Many things can be packed into objects, and globals can be ditched.
  
• Many stray functions e.g. HU_initSText can be properly made into methods of a well-defined object (hu_stext_t)
  
• Software rendering is viable, as demonstrated by other applets. Java can be quite fast with raw number crunching on already-allocated arrays.
  
• Some things like pointers and arrays are actually simplified in a managed language, and in some cases the resulting Java code is more readable than the C original.
  

So...I think I can share my (still preliminary) work with the world.

The project's name is a homage to the "ice cream flavor" tradition of Doom source ports: just like Vanilla and Chocolate Mocha is also an ice cream taste...only more coffee flavoured (reflecting Java and the intended closeness to the original code).

I set up a SourceForge project: http://sourceforge.net/projects/mochadoom/ with its own CVS, which is somewhat of a mess.

I suggest that you use Eclipse to jack in and tinker (that's what I'm using for development), and start from the testers package so that you see how some stuff is supposed to work. There is a LOT to be done, there are still unprocessed C and H files there and a lot of scary red "X"s but what I did so far was enough to convince myself that there is some real potential here, and that it's worth sharing, even at such an early phase.

I therefore invite anyone interested to check out the code, and, why not, join in the project/reuse the code/take ideas/port it to something else.

BTW, the Jake2 codebase is a VERY good reference/starting point: many of the ideas I applied here come straight from there.

[entryway]

Not really good port name for Russians.

Transliteration for 'mocha' is 'моча' which means 'urine'

[Maes]

Well, I had to put up with Jodwin's "Paskal" before, so...

TBQH there's some confusion as to how "mocha" is spelled: in Italian it is usually "mocca" or even "moka", while the proper Russian term for it would be "ΜΟΧΑ" or "ΜΟΚΚΑ", but in most of the Western world "mocha" is universally accepted. Think "ch" as in Loch, not as in Chernobyl ;-)

[Never_Again]

Don't think "Loch", 'cause "ch" there is pronounced as "kh" (like in "khan"). Worse yet, Russians use the same word for "twerp". =) Think "ch" as in "chemistry".
Anyway, why not "Mocca DOOM"?

[RestlessRodent]

"Mocca" is not a word to me: http://dictionary.reference.com/browse/Mocca . "Mocca" would be said as "Mock, ah" whereas "Mocha" would be "Moe, ka".

Also, you should use SVN instead of CVS, much cleaner and more revision based.

[Graf Zahl]

Well, either way, thank god I don't like coffee! :P

[Never_Again]

GhostlyDeath said:

"Mocca" is not a word to me: http://dictionary.reference.com/browse/Mocca

Technically, neither is http://dictionary.reference.com/browse/GhostlyDeath.

[Maes]

GhostlyDeath said:

Also, you should use SVN instead of CVS, much cleaner and more revision based.

Eclipse only supports CVS and I'm already acquainted with it in my workplace :-( (and I'm too lazy to look for alternative plugins)

To verge on the more technical...I'm working on completing patch_t reading support. It's pretty fucked up, since you don't know a-priori the number of post_t's inside a column_t you have to read when you're reading procedurally, and each column_t actually has a bunch of variable-length bytes appended to it.

These bytes do NOT show up in the C code in the struct definitions themselves: they are only implicitly addressed with pointer magic, however in order to pre-split post_t's and read the correct amount of bytes each time, it's required to do a tentative read of each column_t, determine how many post_t's it contains, and then allocate properly sized structures and read them in... A NIGHTMARE!!!!

Also, there are some implicit splits on long columns:

If length<128 = a single column_t + FF terminator (and fist/last bytes of the "data" are padding or somesuch).

With larger lengths, it's split in multiples of 128 (e.g. TITLEPIC is split in 128+ 72 -length blocks.

[Use]

entryway said:

Not really good port name for Russians.

Transliteration for 'mocha' is 'моча' which means 'urine'

When you put it like that I think it's perfect.

[Maes]

Hmm..actually I think that column_t's is one place where I'll concede some C-ish hackism: for the sake of memory efficiency I'll read whole column_t's from disk into a byte array (the fact that the indexes are known makes this possible), and then let the gory post_t separation take only place in the renderer. This way I will avoid a column having perhaps 100 children objects ;-)

Another thing I thought about was having pre-rendered "non-sparse" whole bitmaps/columns and ditch the sparse column format entirely (instead, keeping only fully unpacked columns with "transparent" pixels in place), but I don't know if any source ports do that or if it will eventually break some effects.

[Graf Zahl]

ZDoom is storing patches like that but then it creates a column list on top of that. The original column data is never used in the renderer.

I don't think it'd break any effects but if you store textures like real bitmaps it'll become a lot easier later to add support for other graphics formats and handling composite textures without the nasty bugs they have in Doom.exe

[Maes]

Thanks for the clarification! BTW, is this uncompressed format fully truecolor or is it still indexed? I recall there is still some trouble with classic-style renderers and true colour...

[Graf Zahl]

It depends.

The 3D view still uses indexed images but since the 2D stuff is drawn with hardware acceleration ZDoom also can create true color images from textures. But these are no longer organized in columns and posts because they are only used as hardware textures.

For 3D drawing all graphics formats will be converted to the game's palette.

[_D_]

Hi,

I added a few things to mochadoom. It's more playable (can open doors, exit level, kill monsters, monsters now do something...). Also added music/sound and load/save game.

Since I don't a permission to commit the project to the CVS server, I posted it on: http://www.megaupload.com/?d=TUP4U389

[Csonicgo]

_D_ said:

Hi,

I added a few things to mochadoom. It's more playable (can open doors, exit level, kill monsters, monsters now do something...). Also added music/sound and load/save game.

Since I don't a permission to commit the project to the CVS server, I posted it on: http://www.megaupload.com/?d=TUP4U389

Well, holy crap. if you did.....

That's amazing.

[Maes]

Under review ;-)

I'd appreciate some contact over sf.net or any other private channel of your choice though.

Edit: I had a first reply here, but I thought it'd better stay private, for now. Stay tuned ;-)

[_D_]

Did an update, and almost everything from the original game is functionnal (it is of course very playable). Also included "doom.html" to run it as an applet form.

http://www.megaupload.com/?d=NJYC8KA1

[Csonicgo]

Holy.


SHIT.


that was awesome. I played about 10 levels of doom2 with that. color me impressed.

[Maes]

After 13/4/2011 I'll be able to go back to working on Mocha Doom full time -or at least with the "before" pace-, and will merge _D_'s changes into the main branch. I simply haven't touched the thing since December, because of other priorities which, luckily, seem to be near their definitive solving.

[_D_]

I don't plan working on it anymore because of other priorities, though I enjoyed it. I posted it so anyone who wish to play or improve/takeover the code can do it. I will still answer questions on the code if any.

[Maes]

No problem man, what you did was awesome :-)

If my response was somewhat chilly, it was only because I was hard pressed to finish my M.Sc. (which occured on 13/4, as I said). Easter has passed too...and I will be back to my regular job with the -usually plentiful- free time which allowed me to start Mocha Doom in the first place. I just hope merging your changes won't be too hard ;-)

[mr fiat]

very interesting port. I tried it out its a bit tricky bot it works and I like it.

[Maes]

I'm trying to release the next version with playable speed and a whole host of other goodies, that will make it much more worthwhile than until now. Just be patient...