Mocha Doom v1.6 released: Fullscreen, Truecolor n' stuff

[Maes]

More than a year has passed since the last update, and I just kept fixing and adding features whose volume eventually accumulated but I kept saying to myself "No, it's not ready for a release yet, I must first fix bug X/implement/add feature Y!". But as we all know, this kind of thinking results in a deadlock, and features just piled up.

Throw in a couple of major refactorings and my research on HiColor & TrueColor modes, some rushed features like fullscreen support, ZIP & URL loading support (yes, it's true, it can load ZIPs, PWADs and zipped pwads off the INTERNET!), a proper cvar system (still hidden deep inside though) and it was just way, way too much to keep holding back.

Then I said to myself, hey, it can't be worse than v1.5, which is over a year old by now, and so went ahead and released it. So there you have MochaDoom v1.6, mean, ugly, dirty, raw and uncut. Hopefully, v1.7 won't take as long...

New features? Too many to mention. Just a few of the most important:

Changes since v1.5:

• Added a fullscreen mode, however limited by Java's and the host OS's
  limitations.
  
• Added a HiColor and TrueColor software rendering mode, which give more color
  depth to the classic Doom renderer
  
• Added support for extended size maps and large blockmaps (up to 512 x 512
  blocks). Now giant maps like Europe.wad are playable without problems!
  
• Added support for .zip files and using URLs are data sources.
  
• Functional settings saving
  
• Fixed 22 KHz sound playback for certain sound effects (super shotgun)
  
• Fixed some lingering limit removing stuff.
  
• Several small and large bugs here and there.
  
• Fixed Mancubus action functions.
  

But don't take my word for it....try it.

https://sourceforge.net/projects/mochadoom/

Just a friendly advice: once you try the truecolor software renderer mode in high resolution and in full screen, you might find it hard to go back to 8-bit or even OpenGL ;-)

[Gez]

Maes said:

ZIP & URL loading support (yes, it's true, it can load ZIPs, PWADs and zipped pwads off the INTERNET!)

If you haven't already, you need to implement the idgames protocol, so that for example one can use mocha -idgames://13851 to automatically download and play Suspended in Dusk. :)

[Maes]

Heh, one more thing to add to v1.7 (hopefully released much sooner!).

Oh, and for those of you eager to try the hicolor/truecolor modes: use the -hicolor and -truecolor switches or, if you like it that much that you want it permanently on, set the "color_depth" setting to "hicolor" or "truecolor" in default.cfg

[Dragonsbrethren]

All of the batch files cause this to crash on my PC. Running Windows 7 x64 and Java 7. Video card is a GeForce GT 240 with the 306.97 driver. Running the jar itself by double clicking it or through the command prompt works fine, but fullscreen mode is entirely black as expected. Using the command line in the readme makes it crash too. I don't see anything useful here, but pasting it anyway:

C:\DOOM\mochadoom-alpha-16>java -cp mochadoom.jar i.Main
M_LoadDefaults: Load system defaults.
Indexed 8-bit mode selected...
        added ./doom.wad (zipped: false network: false)
ITicker: Using nanosecond accuracy timer.
                         The Ultimate DOOM Startup v1.9

V_Init: allocate screens.
Z_Init: Init zone memory allocation daemon.
W_Init: Init WADfiles.
        added ./doom.wad (zipped: false network: false)
VI_Init: set colormaps.
Enough data for 14 palettesEnough data for 5 gamma levelsInput context successfu
lly set to US.
===========================================================================
                 Commercial product - do not distribute!
         Please report software piracy to the SPA: 1-800-388-PIR8
===========================================================================
Tables.InitTables: Init trigonometric LUTs.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon -
R_InitData
Init Texture and Flat Manager
InitTextures[.....
InitFlats
InitSprites............
InitColormapsColormaps: 35

R_InitPointToAngle
R_InitTables
R_InitPlanes
R_InitLightTables
R_InitSkyMap: 53
R_InitTranslationsTables
R_InitTranMap: Translucency map found in default tranmap.dat file. Attempting to
 use...
R_InitDrawingFunctions: AM_Init: Init Automap colors -
P_Init: Init Playloop state.
false NUKAGE1 NUKAGE3 8
false FWATER1 FWATER4 8
false LAVA1 LAVA4 8
false BLOOD1 BLOOD3 8
I_Init: Setting up machine state.
D_CheckNetGame: Checking network game status.
startskill sk_medium  deathmatch: false  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
S_Init: Setting up sound.
I_InitSound:
 configured audio device
I_InitSound:  pre-cached all sound data
I_InitSound: sound module ready

C:\DOOM\mochadoom-alpha-16>

[Maes]

@Dragonsbrethren: sound more like a JVM bug (yes, they do exist, otherwise the Direct3D workaround wouldn't be needed). It surprises me to see that it completes sound initialisation successfully, but crashes without ANY error messages soon after. After InitSound, the next thing in line would be InitMusic, so try and disable that with -nomusic and see if anything changes.

Otherwise, it would be most helpful to see if you get the same exact type of crash with PREVIOUS versions of Mocha Doom (I don't have Windows 7 x64, only x86) and with 32-bit/64-bit JVMs, and also with older versions of the JVM (v1.6x).

Usually those "silent" crashes indicate insufficient privilege levels or some fuckup at the JVM-OS interface (the "gray screens of death" inside applets are infamously cryptic, which is why I abandoned the idea of an applet version pretty soon), but that "write once, write anywhere" bullshit goes out of the window once you start mixing OSes, windowing and sound subsystems.

[Dragonsbrethren]

I tried the 32 bit versions of jre6 and 7 first and Mocha Doom runs fine in them without crashing. (I guess Windows is set up to use the 32 bit version when running the jar itself, hence why that didn't crash.) -nomusic does the trick on the 64 bit version of jre7, no crash when using that parameter.

Are spectres supposed to be rendered HOM-like in truecolor mode? They look pretty bizarre and are nearly impossible to see.

I love the sound in this port, it actually rivals ZDoom, which sounds much better than any other ports I use.

[Maes]

Thanks for your input, so that nails down the problem to jre 7 + windows 7 x64 + MIDI...what a piece of work...I'll need a debug version running in an x64 env. or a testing volunteer in order to file a bug against it, though :-/

Dragonsbrethren said:

Are spectres supposed to be rendered HOM-like in truecolor mode? They look pretty bizarre and are nearly impossible to see.

Hmm...yeah, that's a little easter egg I left in ;-) It's possible to make them look just like vanilla, but I thought I'd try something different (it's supposed to gradually alpha-blend with the background, they become the more invisible the more YOU HOLD STILL ;-)

I might make it a selectable option, if enough people like it (TBQH, I almost forgot it in ;-)

Dragonsbrethren said:

I love the sound in this port, it actually rivals ZDoom, which sounds much better than any other ports I use.

Maybe it's due to its doing its own mixing through a mixer which replicates the one of vanilla/linuxdoom, including original volume scaling & pitch variations.

[Gez]

Dragonsbrethren said:

I love the sound in this port, it actually rivals ZDoom, which sounds much better than any other ports I use.

The one thing in common between ZDoom and Mocha Doom, sound-wise, is that neither of them use SDL_Mixer.

[Quasar]

Gez said:

The one thing in common between ZDoom and Mocha Doom, sound-wise, is that neither of them use SDL_Mixer.

The only thing EE does with SDL_mixer is play music. Sound effects are mixed in-app and pumped out through a post-mix callback. So if it doesn't sound like liquid gold it's not the fault of that.

[boris]

When the window opens over the mouse cursor I start to turn insanely fast. I have to move the mouse out of the window and back in to get it down to normal speed. Happens with and without grabmouse.

[Maes]

boris said:

When the window opens over the mouse cursor I start to turn insanely fast. I have to move the mouse out of the window and back in to get it down to normal speed. Happens with and without grabmouse.

What OS? What JVM? I know it's an vexing issue with certain linux distros and/or some window managers (especially if using multi-screen). Ubuntu is well-behaved enough, Debian sometimes does that. Again, it's due to how the JVM interfaces with the OS (in particular, the Robot class that controls mouse input).

Edit: ah, I thought you were referring to complete lack of control....this one is a window focus issue that might occur cross-OS, but for some reason happens more in Linux distros. Pressing on a mouse key before the titlepic shows up usually prevents it. Again, "write once, run anywhere" my ass. Maybe for "Hello World".

[boris]

Windows 7 x64.

Java:

> java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)

Pressing a mouse button does the trick. Actually anytime (i.e. when you're already in the game world), not only before the title screen shows up.

[Triple_sSs]

Once again I'm very impressed with the work you've done on this port. :)

I really like the new color modes. Truecolor mode looks much like hardware rendering yet still feels like software, and though the Hicolor mode is more subtle, distant objects and such look less "washed out" than in normal mode.
Now if these could be implemented in other source ports like ZDoom and such, that would be awesome!

[Xtife]

I hope stuff like this will become a call to arms for true color software mode in zdoom like with what happened with voxels someday