So...remood is dead?

As far as I know, remood is the only source port with 4 player split screen AND software renderer support. Sadly, the latest "stable" release is fairly buggy, and anything newer seems impossible to compile. 3dge supports 2 player splitscreen, but requires opengl. JDoom plans to support split screen eventually, but it too will also require opengl. Doom3d, aside from being garbage, requires directx and thus, only works with windows. This leaves Doom Legacy, which doesn't support vertical split screen, only supports 2 players, and has really odd midi support (at least the last time I used it).

Is remood truly dead? Do the latest versions of remood support BEX? Has Doom Legacy's music support improved at all? Can Doom legacy support ARM, PowerPC, MIPS?

Are there *any* decent split screen ports that can run with a software renderer and on any system? (except for computers that can't handle vanilla doom of course :P) I don't care if it's just a modified chocolate doom with 4 player split screen, as long as it's decent.

http://remood.org/
The last news update on the website ; Tuesday, September 10, 2013 by GhostlyDeath.

Danfun64 said:

This leaves Doom Legacy, which doesn't support vertical split screen, only supports 2 players, and has really odd midi support (at least the last time I used it).

While the results are sometimes imperfect, you can always have a renamed duplicate of your desired wad wherein you convert each MID file to a MUS file. This is really easy to do with XWE and midi2mus.

Also worth noting, a 4 player Legacy game can be had over 2 computers that are both using splitscreen. Simply start a network game, have both computers join the server, then type 'splitscreen 1' in the console. Definitely not as easy as just having all 4 on one PC, but it works.

Legacy has its quirks, and to be honest I'm still using 1.42. Newer versions erase my config each time and don't have an included launcher, two serious blows, for me at least. I've been meaning to send wesleyjohnson a plea to reinstate the launcher and attempt adding 4 player support, I'm really glad he's keeping the port alive. It was my absolute favorite in 05/06 before it sorta fell off the radar, and I still use it for all the unique features it brings to the table.

Better joystick support, improved MIDI playback, optional vertical splitscreen and a fix for the "segment handler violation" crash in splitscreen games with deep water would be excellent, but I would imagine they're quite a few bars up in terms of difficulty to implement. Maybe I should also contact bond and inquire about Legacy server support in the next version IDE, that could really kick some new life into this great source port.

Necrobump, I know, but I feel that this thread is fitting, and it was *my* thread.

It's been a year and a half since I made this thread, and apparently GhostlyDeath made a lot of progress in Remood lately, like being in the process of converting the port to Java. Is there any guide to build the latest version? Right now I'm using Xubuntu 15.10 with oracle-java8-installer and oracle-java8-set-default installed from the webupd8team repo, yet I still fail to build the new version. Is it build-able? Are there any dependencies I'm missing?

Listing...
Compiling...
/home/danfun64/Documents/freedoom/remood-src/org/remood/remood/plugin/BasePlugin.java:45: error: cannot find symbol
			throw new NullPointerException(BUN.getString("na"));
			                               ^
  symbol:   variable BUN
  location: class BasePlugin
1 error
Compilation failed.

Danfun64 said:

Necrobump, I know, but I feel that this thread is fitting, and it was *my* thread.

It's been a year and a half since I made this thread, and apparently GhostlyDeath made a lot of progress in Remood lately, like being in the process of converting the port to Java. Is there any guide to build the latest version? Right now I'm using Xubuntu 15.10 with oracle-java8-installer and oracle-java8-set-default installed from the webupd8team repo, yet I still fail to build the new version. Is it build-able? Are there any dependencies I'm missing?

Listing...
Compiling...
/home/danfun64/Documents/freedoom/remood-src/org/remood/remood/plugin/BasePlugin.java:45: error: cannot find symbol
			throw new NullPointerException(BUN.getString("na"));
			                               ^
  symbol:   variable BUN
  location: class BasePlugin
1 error
Compilation failed.

What command did you type to get that error?

Also provide

javac -version

Danfun64 said:

GhostlyDeath made a lot of progress in Remood lately, like being in the process of converting the port to Java.

Really? A full SC conversion to Java from scratch starting from a Legacy codebase? I'm surprised I wasn't asked for any advice since I have made Mocha Doom, but that has made me curious enough to check out the repo. Maybe it was done using some kind of automation...?

Coincidently, remood.org just shut down for no reason.

remood used fossil. To try to compile, I did this:

mkdir remood-src
cd remood-src
fossil clone http://remood.org:8080/remood remood.fossil
fossil open remood.fossil
./build.sh (The log text was provided through "./build.sh >&log.txt")

The results of javac -version

javac 1.8.0_60

...and because I don't know when remood's website will be up again...

*link removed*

edit: The website is back up again, but I'm keeping the link for now.

edit 2: removed link.

From a quick glance, the "Java" portion seems to consist of stub code for the most part, with large chunks missing and no actual Doom functionality implemented. The compiler level compliance is also variable: some classe use constructs which are allowed only in Java 7, other use Java 8 features, and some use both (!), making them impossible to compile. Loading it up in eclipse results in a wall of red errors, without any obvious "clean" compilation paths.

No Mocha Doom code or design is used anywhere. Actually, if the word "Doom" wasn't used every now and then, there aren't any references to Doom's source code in general, period. This looks more like an attempt to an independent, from-scratch recreation with minimal functionality, more closely related to the old DoomCott project, or a means to implement a lightweight Java wrapper over an external "Doom library".

TBQH I'm surprised that anybody would attempt a Doom to Java reconversion from scratch after my adventure with it.

Danfun64 said:

Coincidently, remood.org just shut down for no reason.

VPS issues, appears it has been resolved.

Danfun64 said:

Necrobump, I know, but I feel that this thread is fitting, and it was *my* thread.

It's been a year and a half since I made this thread, and apparently GhostlyDeath made a lot of progress in Remood lately, like being in the process of converting the port to Java. Is there any guide to build the latest version? Right now I'm using Xubuntu 15.10 with oracle-java8-installer and oracle-java8-set-default installed from the webupd8team repo, yet I still fail to build the new version. Is it build-able? Are there any dependencies I'm missing?

ReMooD Java is very primitive right now, just base skeletons for the most part, not exactly playable.

Maes said:

Really? A full SC conversion to Java from scratch starting from a Legacy codebase? I'm surprised I wasn't asked for any advice since I have made Mocha Doom, but that has made me curious enough to check out the repo. Maybe it was done using some kind of automation...?

Today, I program (mostly) exclusively in Java (although I still am rather good at C (in fact, knowing Java made me a better C programmer), and still despise C++). I wanted to port ReMooD to Java about 5 years ago but the language just got good enough last year with the release of Java 8. I do plan on getting your input/advice, however it is far too soon as all I currently have now is essentially a "Hello World".

Maes said:

From a quick glance, the "Java" portion seems to consist of stub code for the most part, with large chunks missing and no actual Doom functionality implemented. The compiler level compliance is also variable: some classe use constructs which are allowed only in Java 7, other use Java 8 features, and some use both (!), making them impossible to compile. Loading it up in eclipse results in a wall of red errors, without any obvious "clean" compilation paths.

No Mocha Doom code or design is used anywhere. Actually, if the word "Doom" wasn't used every now and then, there aren't any references to Doom's source code in general, period. This looks more like an attempt to an independent, from-scratch recreation with minimal functionality, more closely related to the old DoomCott project.

TBQH I'm surprised that anybody would attempt a Doom to Java reconversion from scratch after my adventure with it.

Yes, it is currently just stubs for now. As for compiler compliance, requires Java 8. As for like-DoomCott, if what you are saying is "writing a Doom-like engine from scratch using no existing source code" then no. As for minimality, it would not be minimal just an expected feel of how ReMooD 1.0a should be (if it were like Chocolate Doom I would port Chocolate Doom and not ReMooD). I would be writing it as it would be if it were a Java project and not a C one, my goal is to translate and not transliterate.


--

ReMooD is not exactly dead. I did start it 10 years ago (when I was 16) and changes to life occur and such (jobs mostly). I also have a (bad) habit of rewriting everything because crufty code is bad and requires perfection. Simple Doom Editor is dead though, and you will not be seeing a release of that however.

Well, if you follow on with this project, it would be interesting to see what you would do differently (or similarly) to me.

When I created Mocha Doom I had to contend with a few annoyances like the lack of unsigned types (except for char used as "unsigned short"), the desire to keep the fixed point arithmetic even though I couldn't typedef stuff, and some personal design decisions like wanting to keep it "pure" (no JNI, OpenGL, etc.). OTOH these choices kept it compatible with humble Java 6, and got functional to the point of having demo compatibility with the IWAD demos, at least.

I also discovered some neat hacks to allow for fast indexed graphics with palette changes on-the-fly, and later a generalized system to allow increased bit depth and extended colormaps. Thanks to other people it eventually got sound and music.

Perhaps the most important design change is how everything was compartmentalized in classes and mapped to objects to avoid the use of static globals everywhere, and how the lump caching mechanism was implemented. The end result is a weird hybrid between C-style and Java-style code, which for what I'm concerned offered the best compromise between the original source code's authenticity and "object oriented" practices. It's Java, but it's also Doom ;-)

Now, I'm not familiar how Legacy's (and thus remood's?) internals are...they may just be too different, different enough to warrant a from-scratch reimplementation.

GhostlyDeath said:

ReMooD is not exactly dead. I did start it 10 years ago (when I was 16) and changes to life occur and such (jobs mostly). I also have a (bad) habit of rewriting everything because crufty code is bad and requires perfection.

Well to be fair, Doom Legacy as a port is garbage, and in hindsight I wish that Sonic Robo Blast 2 used a different port as it's base, as despite the long time it took in between SRB2 forking Legacy and today it still shares many of the same problems. If someone made splitscreen support for crispy-doom or dos boom, I would use those in a heartbeat compared to Doom Legacy.

...That being said GhostlyDeath, can you say which pre-rewrite revision made after 0.8a is the most stable?

Maes said:

Well, if you follow on with this project, it would be interesting to see what you would do differently (or similarly) to me.

When I created Mocha Doom I had to contend with a few annoyances like the lack of unsigned types (except for char used as "unsigned short"), the desire to keep the fixed point arithmetic even though I couldn't typedef stuff, and some personal design decisions like wanting to keep it "pure" (no JNI, OpenGL, etc.). OTOH these choices kept it compatible with humble Java 6, and got functional to the point of having demo compatibility with the IWAD demos, at least.

I also discovered some neat hacks to allow for fast indexed graphics with palette changes on-the-fly, and later a generalized system to allow increased bit depth and extended colormaps. Thanks to other people it eventually got sound and music.

Perhaps the most important design change is how everything was compartmentalized in classes and mapped to objects to avoid the use of static globals everywhere, and how the lump caching mechanism was implemented. The end result is a weird hybrid between C-style and Java-style code, which for what I'm concerned offered the best compromise between the original source code's authenticity and "object oriented" practices. It's Java, but it's also Doom ;-)

Now, I'm not familiar how Legacy's (and thus remood's?) internals are...they may just be too different, different enough to warrant a from-scratch reimplementation.

Luckily for us, Java REQUIRES two's complement integer values. This means that signed/unsigned add, substract, and multiply are the same. The only difference is division , but there is a static method for that (a JVM if it is smart enough could see calls to that division method and just use a plain straight division and remove the call). As for purity, the whole thing will be pure and the only JNI things I plan for are plugins (Windows joysticks for example).

For fixed_t, I could use a mutable class or I could just use plain integer. fixed_t only gets funny when you multiply or divide.

For Legacy's internals compared to ReMooD, most of the game logic has remained the same with some optimization and customization (profiles for example). Various bug fixes and compatibility (can play vanilla demos better). I did complete rewrites of most of the core subsystems.

With the Java code however, I can easily serialize and deserialize save games rather than having
a gigantic confusing mess of code to do the same thing in C.

Danfun64 said:

Well to be fair, Doom Legacy as a port is garbage, and in hindsight I wish that Sonic Robo Blast 2 used a different port as it's base, as despite the long time it took in between SRB2 forking Legacy and today it still shares many of the same problems. If someone made splitscreen support for crispy-doom or dos boom, I would use those in a heartbeat compared to Doom Legacy.

...That being said GhostlyDeath, can you say which pre-rewrite revision made after 0.8a is the most stable?

There are rather stable revisions, but I do not know off hand. And with the move to fossil (from hg and then from svn) the numbers would be off too. There is tip's __old__ directory, which is in pretty good shape. However the caveat with that is the redoing of the menu system, so everything must be done via the command line, console, and configuration files. Multiple joysticks are supported, if you configure your profile correctly that is.

There are graphical glitches though such as flashing however.

GhostlyDeath said:

Luckily for us, Java REQUIRES two's complement integer values.

Well, I'd like to see an (efficient) programming language that doesn't use what every CPUs has been using for the last 40 years ;-)

GhostlyDeath said:

This means that signed/unsigned add, substract, and multiply are the same.

Doom's "fixed_t" type is a good example: it's basically nothing more than a signed integer, and for what regards addition and subtraction, it actually behaves "as it should" (with numerically correct results) whether one interprets it as a 32-bit signed integer, or a signed 16.16 fixed-point number. For multiplication/division, ofc, one must use Doom's FixedMul/FixedDiv (and internally, precision is temporarily blown to 64-bit). That being said, it's possible to "losslessly" convert to and fro floating point numbers using some bit shifting.

For angle_t, things were a bit trickier: most of the time, I had to emulate "unsigned int" behavior with Java longs, e.g. by ANDing any ops involving "angle_t"s a bit mask (0xFFFFFFFFL), except for a few tricky spots in the code where angle_t's were actually meant to be interpreted as signed (!) integers.

GhostlyDeath said:

For fixed_t, I could use a mutable class or I could just use plain integer. fixed_t only gets funny when you multiply or divide.

A design goal I had set for Mocha right from the start was performance and compatibility: I could have got around many headaches and ambiguities like using "int" for "fixed_t" and "long" for angle_t (which should have been unsigned int...) by using specialized classes/wrapper objects, but especially in the case of arrays of angles or fixed values (e.g. sine tables) it would be a performance killer. Another solution would be to take the plunge and move definitively to floating point arithmetic for everything, but that would kill compatibility. I even went as far as allowing for overflow emulation in some cases (e.g. tan table accesses frequently overflow, and then then end up in the cosine/sine table).

GhostlyDeath said:

With the Java code however, I can easily serialize and deserialize save games rather than having a gigantic confusing mess of code to do the same thing in C.

C'mon, it's not that bad ;-) Plus, I wanted it to be compatible with vanilla savegames (and not only it is, but it also adds some "perks" like reconstructing infighting targets from any vanilla savegame).

A final note about WAD/lump management: though there were some WAD libraries written in Java even at the time I started Mocha Doom development, I opted not to use them because they lacked some functionality which is essential in-game, like the ability of opening and "lumping" several PWADs, overriding lump priority, and Boom-like namespaces (which I ended up using). Also, many of them had to read everything in memory right away upon opening a file, rather than lazily loading stuff when requested. Since in Mocha Doom loading a lump also equals unmarshalling it to Java classes (and possibly arrays), keeping a binary blob preloaded in memory and using twice as much memory (at least) didn't sound very appealing. So I went ahead and copied Jake2's resource management system ;-)

Still, the more Java Doom ports, the better, and the more different ways of doing something, again, the better. Feel free to "borrow" any solutions/code or ask me for specific advice, when the time comes.

Maes said:

keeping a binary blob preloaded in memory and using twice as much memory (at least)

For WAD files, I am planning on using FileChannels and MappedByteBuffers for WADs. Legacy had previously modified lumps it would W_CacheLump*() into memory, I had forced them to be read-only. It did not make much difference though because I had to read some entries byte by byte anyway (0 padding hacks are ugly). Then for individual lumps I can just position(), limit(), and slice() from the WAD's MappedByteBuffer. However this does not work for stuff in ReMooD.jar. Most modern OSes when using stuff such as fopen(), will map the file into memory anyway.

Maes said:

C'mon, it's not that bad ;-) Plus, I wanted it to be compatible with vanilla savegames (and not only it is, but it also adds some "perks" like reconstructing infighting targets from any vanilla savegame).

In ReMooD, due to networking code, the savegames had to be "perfect" (loading a savegame would be as if you never restarted the game). There is also tons of state to be saved such as game variables, script locations, etc.

The wad lump handling in DoomLegacy got some serious fixes several months back. If ReMood still have some of the code around, then you should look at some of the DoomLegacy patches in that area.

DoomLegacy 1.42 is really old now. The config file handling of the latest DoomLegacy has not changed from 1.42, so for config files to get erased there has to be something else happening too. For as long as I have worked on it, it has rewritten the config file from the user settings, which can be altered from the menus. Very likely a problem with finding the config file, a problem that was addressed by some patches made in April 2015 (sorry, not in a released binary yet).

DoomLegacy on Windows machines: only running the Win98 binary, that has an old SDL version, is not going to be representative of what you could get if you compiled DoomLegacy yourself. This is specific to Windows users. Experiences vary widely, and seems to depend on the user's effort.
Note: DoomLegacy compile detects the version of SDL present and there is a difference in how music is played. Compile it for your machine if this is important.