It's sad that after all these years, Java is the only mainstream (and powerful beyond doubt) platform that has not been blessed with a full-fledged Doom source port (intended as something recreating the engine, using original IWAD data, playing demos etc.). Stark remained at the stage of a 3D engine (although it could use IWAD data) and Doomcott was probably a non-functional hoax all along (decompiling the jar revealed just a bunch of smallish .class files with stub methods, and there are no accounts of it actually functioning).

To be honest, unless something can use or follow the original C code directly or indirectly (as is the case of Delphi Doom and "Flash Doom" using Flex), a direct source port is not always technically possible: too many C-isms, as pointed out in the countless threads about "Java Doom".

Super Jamie said:It's platform specific and is not a "true Java VM" but it's close :P

doom-for-android said:JNI

GTFO

OTOH, I'm trying to persuade a colleague (senior Java Grunt) to give the Doom SC a try and tell me what he thinks. With the state of Java when DoomCott and Stark were developed (no enums, no generics, etc.) it would have been a clusterfuck just to get past all of those #define constants, if it ever worked, but now it appears more plausible. If we ever decide to get our hands dirty on it, we'll probably get rid of the fixed point arithmetic, or implement it as a secondary fork.

I gave DoomCott a partial disassembly to see what the fuck they were trying to pull BTW...which is not much. The WAD parser is about the only useful part, as well some methods that emulate Doom's raw "drawbitmaps"

Gave DoomCott's decompilation a closer look: it appears to have been caught in the "let's try and stay close to C" pitfall: too many static classes, methods, primitive types and not enough reusable/instantiated objects.

All the code is one -kinda small- clusterfuck of static methods and singletons, with binary values fist-fucked into char and int array, which is really ten levels below what you'd call "bad practice" for Java.

It's obvious that the guy tried to stay close to the original source code, and even if the method names were obfuscated, the functionality of some is very obvious. However it looks fugly in Java, and it wouldn't look any better in C# either.

No wonder the guy behind it dropped as far back as 2002.

P.S.: Heh, those android guys really crossed the line. One of the download even contains Heretic.wad and D2XTREME.WAD, which itself is a warez of Plutonia or TNT. What were they thinking?

Well let's hope the Wolf3D clone with Doom slapped on it is at least a little better than that atrocious Wolf5K for cellphones. I know of where to load it into my phone so I'll try it and say if it's good.

EDIT:
For those who wish to try it out, stick the JAR somewhere on your HDD, upload it to this site, and enter the code at the URL it gives you. That's how I got Pokemon and Sonic on my phone.
EDIT2: It's a little better than Wolf5K, but not by much.

Kagemaru_H said:For those who wish to try it out, stick the JAR somewhere on your HDD, upload it to this site, and enter the code at the URL it gives you. That's how I got Pokemon and Sonic on my phone.

Or just get a non-broken phone with removable storage and/or USB connectivity, and stuff it with whatever you want without charge, and without giving away your phone number for little or no reason :-p

"Making Doom run on a new platform is only a couple days of work," Carmack said. "Making it a really good game on a platform that doesn't have a keyboard and mouse or an excess of processing power is an honest development effort."

I don't see how any this is relevant to Java development. The iPhone port is notoriously C-based. What Carmack said about porting may be true for any platform having a C compiler or an equivalent language. Porting the source code (this means no recreations or half-assed Maze War/Wolf3D engines) requires either a C-capable system (this includes Pascal and Delphi, as proven by the existence of DelphiDoom, which are able to preserve the C-isms to large degree). Just by examining carefully the source ports that are around will confirm what I said, with no exceptions.

Those that actually use the Doom source code are either C, C++ or Delphi/Pascal, or use a way to import it as-is (e.g. Flash + Alchemy). Those that don't can be in other languages, but are just Maze War clones or recreations from scratch, like Doom.NET.

Again, not relevant to the problem at hand, unless someone has already found a way to get rid the SC of its C-isms and transform it into a way that is acceptable by Java standards in the first place. The rendering subsystem is but an aspect of the problem, when much more essential features of the Doom engine are fucking hard to translate to a language without pointers, structs, unions, abusable enums/defines etc.

One of the very first challenges a Java developer will encounter when transforming the Doom SC into a "tamer" OO language, is that while certain aspects of the SC just SCREAM to be turned into pure managed OO (things, map elements and methods that work on them), others are just fucking hostile (fucktons of defines, enums used as integers, fixed point arithmetic with abuse of implicit operator overloads, function pointers, global methods, etc.) so the very first step would be a top-down redesign of the class hierarchy, the data structs, method calling conventions, and certain -perhaps painful- design choices like getting rid of the fixed point arithmetic.

The "easiest" way to port Doom to Java would be, perversely, to turn Doom itself into some kind of DLL with an internal state, leaving any major C-isms inside it and use it externally via JNI. But that would be just fucking stupid, IMHO (even though it's what "Flash Doom" actually does). It would be just the illusion of a "Java Doom".

If I ever get seriously started on such a project, my aims would be to make it a sort of reference implementation, aimed at being:

Well documented, pure Java with an all-new class hierarchy and objects/methods following Java conventions and doing away with C-isms as much as possible, so future enhancements and ports to other OO languages with similar features can be built on solid ground. My experience and DoomCott's proves that trying to copy C closely into Java is fugly, and usually a losing proposition.

Software rendered. The Original engine is too cool to just waste away for a platform-specific OpenGL or whatever wrapper, or -God forbid- for some "generic" 3d engine. Also, processing of data arrays (which is what Doom's "screen" actually is) is actually pretty fast, clean and efficient in Java, and arrays can substitute for pointers almost entirely.

Use of new 1.5-1.6 Java features for enums and enhanced control structures, where possible.

Faithful to the original source code for what regards gameplay mechanics, aiming for gameplay preservation within limits. With some effort, DEH compatibility can be achieved by using a static code pointer-java method key-value database and a "method dispatcher".

The sound subsystem would be a pain, but Java has stream playing methods already, if one doesn't wish to use external binaries. Pure Java sound mixers and OPL3 emulators are available, so in theory it could become entirely self-contained for what regards sound.

Rest assured that if someone manages to pull just half of the above together in one working port, it will be a world's first.

Doom's use of function pointers is almost completely restricted to the same type of use that can be directly implemented via polymorphic inheritance, so I would mark that one off your list of hostiles.

Just take a cue from ZDoom and you have a significant portion of the class heirarchy worked out for you already :)

Quasar said:
Just take a cue from ZDoom and you have a significant portion of the class heirarchy worked out for you already :)

Thought about that too, e.g. that existing source ports may have done a great part of the work already, but they might still be too close to the original SC and its C-isms (I'll have to actually see them though). I had studied DelphiDoom for example, and it was anything but OO: it was basically a procedural C-to-Pascal close translation, possible because of the language equipotency to C.

Still not the point. You could slap Doom's graphics on it and it would look like Doom, be more complex than ROTT or Wolf#D but it still would not be Doom, would not be able to play demos or PWADs and so on. It would just be a hack job/recreation, just like that older ShockWave project that exists since 2001.

I am aware there are functional 3D engines for Java mobiles (and desktop 3D Java games as well) that match or exceed Doom's engine in complexity. However if you just patch those to use Doom graphics and sort of recreate the gameplay, that's still a far cry from calling it a Doom "source port" in my book.

The facts remain: none has created a source-equivalent Java (or .NET) version of Doom (and before you trump Doom.NET...that's a recreation, with the explicit intent of not reusing ANY of the original SC) that can work with PWADs and DEHs. And of course this has nothing to do with original 3D games being created for the platform.

Whoever makes a complete, functionally equivalent port of the Doom's SC to Java will be a world's first. With calls to p_random and all.

The difference with Java and a platform that can use the C source in one way or the other is this: in the former you have to rewrite everything from scratch, adapt a lot of C-isms to Java's way of doing thing etc. while in the latter you maybe change a few things here and there in the SC, add your own code to adapt audio and video to the platform you're using, and bingo, a new Doom source port is born, without touching 95% of the original SC. No wonder none has attempted the former so far (at least to the bitter end).

To give the Devil's due, I installed that POS on the first post on my cell phone and it played like a lame cow, horse, reindeer, goat, dog, cat, sheep and camel molester chasing elderly farm animals. WHERE ARE YOU AVGN TO PRAISE ME FOR MY AWESOME REVIEW????!!