Mocha Doom project page + Stark Engine

[Maes]

I went through a round of polishing and updating Mocha Doom's homepage, where I answer some questions about the project:

http://mochadoom.sourceforge.net/

As a bonus... anybody remembers the Stark engine?

Yeah, that earlier attempt at making a Java-based Doom, which actually got rendering to work, but was abandoned, and, worse, the SC was pulled/lost.

Well, there was this one project that actually used it, but it seems it never became more functional than Stark itself. I barely remembered peeking through the source code looong loooooong ago, and vaguely remembered how it worked, and considered it totally lost, which was also one of the reasons Mocha Doom was developed from "scratch" -well, based on linuxdoom anyway.

But, unexpectedly, I found it again, laying forgotten in one of the grimmest and most frostbitten corners of my HD.

As a service to the world, I put it back online, for great justice.

Enjoy.

I also discovered this older Java WAD management library and decided to take a look at it.

Now, as it's well-known I created Mocha Doom based on the linuxdoom codebase (it's mostly a C to Java affair), wrote the renderer and wad management "myself" (essentially converted it from C) and preserved much of its features such as lump caching, fixed-point arithmetic, BAM angles etc. but I always wondered how it would turn out if I used a combination of Stark + jwadlib

• There would be significant time saving in getting the renderer going, however it would be devoid of any game logic, and some glue code would be necessary.
  
• No thinkers code, no sector actions etc. and no apparent provision for them. ouch.
  
• Sprites support was incomplete when the project was terminated.
  
• Performance wouldn't be as good: Stark uses full floating point, has no functional BSP or blockmap, and a slightly slower method of transferring raw blits to the screen. All this combined results in it having 1/3rd-1/4th of Mocha Doom's performance under similar circumstances (35 fps @ 1280 X 800, vs 110+ for Mocha Doom on my laptop, which however is still much better than other Java engines I've seen).
  
• The WAD loading is too customized: it tries to load and decode EVERYTHING as soon as a WAD file is opened, rather than work on an on-demand basis like most source ports. Mocha Doom used Jake2's emulation of Quake 2's resource management, in this respect.
  

As for JWADLIB, its biggest disadvantage is that it has no lump search functions (so I would still have to implement those myself), and apparently has no support for "stashing" WAD files in an IWAD + PWADs + lumps fashion, so I would also have to reimplement those myself anyway. It sure looks much more "enterprisey" than my C-to-Java hackjob though ;-)

The only interesting thing about it was that an incomplete lump caching mechanism similar to Mocha's CacheableDoomObject was in place.

[arrrgh]

Would it be possible for this to be ported to Android? Becuase that would be super neato.

[Maes]

There would be two problems: first, it would have to compete for market share with this, which also got a bad rep for putting commercial IWADs online. However that's not a pure Java implementation (it uses a compiled prboom library), and I think it doesn't even work on all Android devices without jailbreaking, so it would make sense to have a "purer" port.

Secondly....I would need to see what tools Android provides for writing directly to the screen, which is the single most important feature a playable game needs to have (the game logic and file I/O could be adapted without problems, however), and whether some of the base Java libraries used by Mocha Doom have Android equivalents.

[tempun]

Would it be possible for this to be ported to JavaScript, as Jake2 was? ;)

[Maes]

I take you mean like this ? Calling this a "Javascript port" is kind of misleading, as it relies on nearly every buzzword about HTML5 you heard in the past 2 years :-p

Even if I consider the use of a cross-compiling utility like GWT "cheating", in a sense, I guess it would be even easier, since there is no OpenGL or audio to take into account (yet). The file reading system would have to be converted to a socket model beforehand, though.

The problem is, such a coding Frankenstein would lose all advantages that make Mocha Doom fast as a desktop Java application: Jake2 can get away with JavaScript's lack of appropriate primitive data types (byte, integer, float) somewhat, because they used WebGL and so most of the actual heavy number crunching is done in system libraries, rather than in cross-compiled Javascript code. Take note that the actual source code is still Java, even in this case.

Mocha Doom on the other hand uses a pure software renderer written entirely in Java and heavily optimized by hand, and so it needs all the power it can squeeze from the CPU alone.

GWT would just kill the performance, as it tries to emulate Java's primitive data type by casting everything to Javascript's mangled double precision floating point numbers (the only actual numeric data type used by Javascript), so every integer operation involving bitwise operations (quite a bit of them) would get a horrible overhead.

Imagine casting an integer to a double at the source code level, re-casting it to an integer at runtime, bit shifting it, re-casting it to a double, and adding it with other similarly shifted doubles, and then doing the same to their result. That's what it takes to render a single pixel to the screen. And at high resolutions, there can be over 1M pixel to update more than 35 times a second in this manner.

TL; DR: yes, it can definitively be done thanks to GWT. But it would have VERY poor performance compared to the desktop app unless the renderer is completely rewritten to use floating point and OpenGL, or Javascript is extended to include proper integer numbers and HTML5 gets a fast-write Canvas element for pure software rendering.

[tempun]

Maes said:

I take you mean like this ?

Yes exactly that.

Maes said:

GWT would just kill the performance, as it tries to emulate Java's primitive data type by casting everything to Javascript's mangled double precision floating point numbers (the only actual numeric data type used by Javascript), so every integer operation involving bitwise operations (quite a bit of them) would get a horrible overhead.

Well if that's true it means that GWT sucks :( Let's hope it will be improved by the time of MochaDoom release.

Maes said:

TL; DR: yes, it can definitively be done thanks to GWT. But it would have VERY poor performance compared to the desktop app unless the renderer is completely rewritten to use floating point and OpenGL, or Javascript is extended to include proper integer numbers

AFAIK, there's that typed array extension

Maes said:

and HTML5 gets a fast-write Canvas element for pure software rendering.

This feels fast enough for me.

[Maes]

tempun said:

Yes exactly that.
Well if that's true it means that GWT sucks :( Let's hope it will be improved by the time of MochaDoom release.

This is not GWT's fault entirely, but due to the way JavaScript works. Javascript only has a double precision floating point type which is limited to 53-bits (which also doubles as "long integer") and a signed 32-bit type. None of these can be explicitly used, because JavaScript is a dynamically typed language, and proper type is determined at runtime.

Now, GWT, on top of that, actually assigns TWO Javascript doubles to one Java double, in order to compensate for the precision. Plus, JavaScript doesn't have byte and word-sized types, which are needed in order to make (fast) screen rendering work.

tempun said:

AFAIK, there's that typed array extension

Like this? If it really delivers what it promises, then there might be some light at the end of the tunnel -assuming someone chooses to enter it-, as it would solve a lot of inherent weaknesses of traditional Javascript (and hoping that one doesn't have to use WebGL graphics in order to access that functionality).

Then again, cross-compiling tools like GWT are aimed at maximum compatibility and doing stuff nice, slow and accross the broadest range of web browsers, so I wouldn't count on something like GWT to handle that for me, at least in its current state.

Jake2 got away with it because unlike Doom, the engine had moved to a full floating point model already from Quake I. Perhaps a port such as Eternity, if ported to Java, would have a better chance.

tempun said:

This feels fast enough for me.

That's interesting, but I'd like to see its performance when faced witn at least SVGA resolutions and at least 35 fps framerates :-) It just might be acceptable for vanilla resolutions or little more, provided everything else ran acceptably as well. There's also the limitation that the Canvas element can't work with indexed graphics, so the engine would have to use full a full 32-bit color model, yet another slowdown.

So let me see....

1. no byte types for drawing into internal buffers
   
2. forced and unredictable casting up and down between integer and floating point types whenever overflows occur and bitwise operators are used.
   
3. Need to convert the internal screen buffers from byte to 32-bit before displaying
   
4. Actual displaying overhead...
   

yeah, sounds like a great weekend project ;-)

However, I don't doubt that it just might be possible for Javascript to "swallow up" the performance loss and still perform acceptably, at least if critical parts of the code are converted by hand.

The heaviest thing I've coded in Javascript is a Kriging interpolator directly ported from a Java implementation without using GWT, which is able to rival the original in performance when running under Chrome's engine, but that's purely floating point operation and, in order to get to display its results without using a Canvas element, most of the time is spent generating dynamic bmp or "table image" data and cluttering up the page's DOM.

Then again, Mocha Doom is open source, whoever wants to burn his brain out with this, hey, be my guest :-p

[Maes]

arrrgh said:

Would it be possible for this to be ported to Android? Becuase that would be super neato.

Now that I think of it, I could give it a shot and see how much of the current codebase is "Android friendly". I expect the most severe differences would be in the screen and user input, and file I/O, while the logic would remain mostly intact -I hope-.

An alternative implementation to the existing "Doom for Android" would be actually interesting, since that one depends on installing a device-specific, practically unsupported and undocumented binary, and AFAIK it can't even be installed on non-rooted phones. With Android 2.3 adding a better JIT and all, this could actually be viable.