I'm messing around with the source and I want to know if soundfonts are a thing in mochadoom so I can use my own.

Best regards,
Me.

When macubus hears you, the sound driver crashes. Just IDCLEV07 or IDCLEV30 and it will crash very soon. The game, however, will continue to work without sound, but will hang on quit.

What jdk does it need to be compiled in for it to run properly ?

I've tried 17 and it says verify error
11 and 17 says it was compiled for a higher version (v60)

I don't know if you're still working on this, but the original controls don't work -- its not nostalgia, I find that Doom engine games are just easier to play using the control scheme they were designed for, so old and new (for new comers) should both be supported.

If you're not still planning on working on this sorry to have bothered you.

Definitely should be possible:
http://archive.is/FWfVF

However, would require some investigation and brand new skills (no Android development experience yet)

Here's a checklist for the multiplayer support. It's the most important feature to add.

• Add deathmatch 3.0 (youtube test video)
• Write the multiplayer code (4 players must be able to play)
  -> The parameter -nodes # starts a server that waits for #-1 of players (the server is one node)
  -> -port # changes the server port to # (default is 2345)
  -> -net ip port could also be used. If no port is specified, then the default is used.
  -> Clients use -join ip port to connect (port is optional, default is 2345)
  -> Game options must be sent to the client(s)
• Register games on master.chocolate-doom.org to help people play over the Internet

List of TODOs (for version 1.7), copied from the old README.md:

• Fix a bug that allows the player to see through walls.
• Fix a crash between Doom II MAP20 and MAP21.
• Fix game settings not being saved.
• Adjust the default settings.
• Display the correct quit messages.
• Fix the different details of rendering.
• Fix a bug where the player keeps moving forward after the automap has been activated.
• Fix other input problems with the keyboard and mouse buttons.
• Add back the mouse vertical movement. Allow it to be disabled using '-novert'.
• Detect FreeDM and FreeDoom has IWADs.
• Aspect-ratio correction.
• Make sure the .jar file executes without the need to specify where the 'main' is.
• Fix the wall-wiggle glitch / long wall error.
• Fix the size of the 'pause' message.
• Make the sound pitch better
• Fix desync of DEMO1 and DEMO4 of The Ultimate Doom.
• Restore the classic fuzz-effect (depends on the bitdepth).
• Write the network code and add multiplayer support. (see #7)
• Can't use the spy key during multiplayer demos (don't take a screenshot)
• Can't play demo files without loading it first with -file
• Add an OpenGL renderer on version 1.8?

There are couple of bugs that was in vanilla DOOM due to limitations of engine combined with the attributes of the language it was written in - pointer arithmetic, manual memory management and so on.

Of course, in Mocha Doom there is little or no of these bugs. An emulation of them is not simple task, but the Chocolate Doom took approach and succeeded in emulation of most of them.

We lack such emulation. But eventually I would like to implement it.

For now, I'll post a little bit of "bugs we do not have".
If you open this wad in vanilla, the sky would glitch and the demo should crash after the first respawn (visplanes overflow). However, Mocha Doom does behave well beyond this point and show no hall-of-mirrors effect on the sky.
whitehouse.zip

I think this info could be useful for others too.

To play a custom WAD, e.g. square.wad from here, first get e.g. plutonia.iawd from here.

Then use command line switches: -iwad plutonia.wad -file square.wad

Example in my Java dialect.

@AXDOOMER @GoodSign2017

I would like to play Doom in my xterm.

I have a Java library that can handle the images and mouse, and I can get something to work for the keyboard. What would it take to instantiate Mocha Doom, pass it AWTEvents for keyboard and mouse, and grab a BufferedImage of its screen? Could it also work when sound is unavailable?

Thank you for any help you can provide.

We could add LEFT-ALT + ENTER like many other programs.

He looks at the mancubus, but he should look at the right where the lost soul exploded.

To be able to debug vanilla incompatibilitites, the D_DoomLoop and all that is called by it that relates to the Loop itself, the ticks, game object modifications, mode changes and so on, MUST be preceded by a label, containing original underscored naming of the method in Doom Source Code.

Do not make labeled blocks inside the methods of your-written library classes, completely new functionality, only mark the place where you replaced or can replace something in future in the existing code.

It would have absolutely no impact on performance, the only limitation is local variable visibility. The variables declared inside the labeled block will not be accessible outside directly, however you can, if you need, declare the variable outside of the labeled block.

Example of labeled block:

M_CheckParm: {
  ... your precious new code doing some work of old...
}

Remember the label blocks will retain their name even in case of automated refactoring.

Consider the situation with old code:
I_InitGraphics ();

After translation to Java:
VI.InitGraphics();

After automated refactoring:
view = sceneRenderer.getView();

And if we use the underscored-named labels:

I_InitGraphics: {
  I_InitGraphics ();
}

After an automated refactoring:

I_InitGraphics: {
  view = sceneRenderer.getView();
}

Thus if you rename some method and update it throughout the whole codebase, the named label will still be named the same underscored original method name.

Do it the most verbose way you can - preserving both, or all brackets of all blocks containing and contained in the label and the brackets of the label itself, with one exception:

If there is no more function to do the task was given to the function in original Doom Source Code, the label stull MUST be present, just type a semicolon to end it without actions.

Right way (some obsolete original method):
I_StartFrame:;

Right way (replaced way the part of method work):

M_CheckParm: {
   if (cVarManager.bool(CommandVariable.DEBUGFILE)) {
     ...new code...
   }
}

Right way (look into future, prevent name changes to break search for old code):

if (advancedemo) {
   D_DoAdvanceDemo: {
      DoAdvanceDemo();
   }
}

Right way:

D_ProcessEvents: {
   ProcessEvents();
}

Right way is unambiguous, readable and easily distinguishable. The syntax is short (but verbose) and is easy to understand. Remember, Java is a verbose language and that makes it strong.
In contrary to it:

Wrong way - easy to miss the labeled block:

if (advancedemo) D_DoAdvanceDemo: {
   DoAdvanceDemo();
}

Wrong way - ambiguous:
D_ProcessEvents: ProcessEvents();

Wrong way - unambiguous, but easy to miss end of labeled block:

M_CheckParm:
   if (cVarManager.bool(CommandVariable.DEBUGFILE)) {
     ...new code...
   }

Wrong way - original block inheritance messed up:

if (cVarManager.bool(CommandVariable.DEBUGFILE)) M_CheckParm: {
  ...new code...
}

For the methods declarations themselves, it is better to use @annotations, like:

@D_Main.C(D_DoomLoop)
public void DoomLoop() throws IOException {
   ...
}

"-nosfx" acts as "-nosound"
See 'DoomMain.java' line 1225.

The game does seem to work fine if we replace
this.S=new DummySoundDriver();
with
this.S=new AbstractDoomAudio(this,numChannels);

I guess Maes wanted to write a sound driver that doesn't do distance calculations when the sound is off.

Would this.S=new AbstractDoomAudio(this,0); do the trick???

How do I compile this? The instructions provided are extremely vague and make no sense. When I try to build the project, the resulting .jar file crashes and doesnt run. I have tried it before and after deleting files with errors (as said in the README.)

Here's how to use the cursor keys to strafe (like any sane person does!).

Put these values in mochadoom.cfg (in current dir):

key_strafeleft    105
key_straferight   106

BUT: Make sure there is no extra space at the end of the line (!). This should really be patched (in ConfigManager)...

When the game is paused, a demo is playing or the player is in the menus, the mouse should be ungrabbed to let the player do other things. (Just like Chocolate-Doom)

Ah, I can see that the cross-OS-platform source port is coming along. In its current state, it is like the original DOS version of the doom engine. Multiplayer support is a coming, so are the multiple iwads. Still, I wait for custom iwad support for this cross-platform source port.

Probably would do some good if a more stable version forks a flatpak version. Why? You know, containerization technology and stuff like that. In case something breaks as a fatal computer crash?