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

Doomcott Demystified

Recommended Posts

Anyone remember Doomcott? Yeah, that early attempt at making a Java Doom by Julien 'Gollum' Frelat, whose public demo I had never got to run, and which allegedly never got past the stage of displaying a wiper (the automap screenshot allegedly comes from a "WIP v0.5" version that was never relased).

Of course, me being involved in what I am, doing my homework and studying what was already out there was a priority. I had even tried to e-mail Julien Frelat an odd year or so ago asking him about the availability of source code....but no response.

So I took it upon myself to reverse-engineer the Doomcott applet, document its inner workings, reconstruct some bits that got lost in the translation (decompilation using jad), and finally release it to the world in all of its (heh) glory.

Here's a list of discoveries:

  • The primary reason why it's not working with modern Java plugins seems to be that it cannot read the doom1.wad resource that's embedded in the jar, at least not past a certain number of bytes. That's a severely cut-down doom1.wad which only has the TITLEPIC, and the help/shareware screens. Saving the applet locally and having doom1.wad as a file makes it work.
  • Functionality is quite limited: It only alternates between TITLEPIC and HELP1/HELP2 pages, with wipes.
  • The code appears directly lifted from linuxdoom, for the most part. It's easy to see e.g. the wiper code, menu codes, doomloop, wad management etc.
  • Horribly non-OO approach. Almost everything is a static class or a static array/variable.
  • In the code, there's a partial menu functionality and will display the Doom logo and first 6 menu options, if supplied in the IWAD. However, this functionality can only be enabled by decompiling and setting a flag to true.
  • It uses an interesting -though limited and wasteful- approach to resource management and to Java's problem of lacking unsigned bytes: all resources are forcibly blown to arrays of Java chars (16-bit). However, their management is done at the "byte" (or char) fiddling level, and there are no almost instantiated objects and structures.
All in all, it's nothing to get too excited about, but it's surely an important -even if potentially overestimated- part of Doom's history. Sadly, it contained very little that could have helped me in the development of Mocha Doom. It's essentially a one-time hack with little potential of ever being expanded.

With every due respect to Julien Frelat, I hereby release the decompiled, commented, and cleaned up source code to the Doomcott applet, organized as an Eclipse project, and supplied "as is". From within the IDE, it's fairly easy to get to run as an Applet, if you want to publish it...well, do your own homework.

I mostly kept the same package non-organization of the original and most of the (obfuscated) class names, but the methods/variables with well-known functionality have been aptly named and commented, so if you are even a bit familiar with the Doom source code, your will easily find your way around this one.

For fun, compare how simple -and cruder- it is compared to Mocha Doom, in which a completely different design direction has been taken (fortunately, otherwise I'd probably have quit too! ;-)

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
Sign in to follow this  
×