Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Maes

Yet another "Java Doom" that ain't the real deal.

Recommended Posts

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".

That being said, here's yet another "Java Doom":

http://handheld.softpedia.com/get/Games/Action/Doom-for-Java-22864.shtml

Yup, it's just a "Doom like" Wolf 3D-ish engine with some ripped graphics and the name "Doom" slapped over it. Oh well...

Share this post


Link to post

Doom-for-Android is a port of PrBoom that runs in Android's Dalvik Java Virtual Machine.

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

Share this post


Link to post
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"

And...fuck @ warez. You didn't have to ruin the thread like that :-/

Share this post


Link to post
exp(x) said:

Nice Final Doom warez link there.

Nice spot, he claimed to have removed them in a previous Google Groups post so I didn't think much of it. I have modified my post and reported the violation to Zenimax.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
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

Share this post


Link to post

I asked my mate who is a full-time Java developer. He gave me this:

http://www.escapistmagazine.com/news/view/92014-John-Carmack-Talks-Doom-iPhone

"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."

He also pointed out JOGL may be of use.

Share this post


Link to post
Super Jamie said:

I asked my mate who is a full-time Java developer. He gave me this:

http://www.escapistmagazine.com/news/view/92014-John-Carmack-Talks-Doom-iPhone


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.

Super Jamie said:

He also pointed out JOGL may be of use.


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:

  1. 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.
  2. Platform independent, pure Java and thus JNI free. This excludes OpenGL rendering by definition.
  3. 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.
  4. Use of new 1.5-1.6 Java features for enums and enhanced control structures, where possible.
  5. 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".
  6. 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.

Share this post


Link to post
SoftPedia said:

The famous and known Doom for your Java compatible mobile. Pick up your chainsaw and kill some aliens.


NO

Share this post


Link to post
magicsofa said:

NO


At least "Doomguy"'s face looks hilarious.

Share this post


Link to post

There IS a C Compiler for Sega Genesis available, so running Doom on a Genesis or 32X could be a reality (besides that atrocious 32X adaption).

Share this post


Link to post

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 :)

Share this post


Link to post
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.

Share this post


Link to post
Kagemaru_H said:

http://www.youtube.com/watch?v=SRQYQTC7vsk
I have that game and it's definitely not just some Wolf clone. This is very close to Doom engine-wise.


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).

Share this post


Link to post

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????!!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×