Maes
I like big butts!
Posts: 8664
Registered: 07-06 |
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.
Last edited by Maes on 06-30-10 at 10:45
|
06-30-10 10:34 
