Maes
I like big butts!
Posts: 10176
Registered: 07-06 |
Super Jamie said:
I asked my mate who is a full-time Java developer. He gave me this:
http://www.escapistmagazine.com/new...lks-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:
- 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.
- Platform independent, pure Java and thus JNI free. This excludes OpenGL rendering by definition.
- 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.
Last edited by Maes on 01-12-10 at 13:56
|
01-11-10 10:10 
