Chocothon (a Chocolate Doom-like source port)

[aperturegrillz]

I have been talking with certain members of the Marathon community about Aleph One bugginess and slow development pace, source ports in general, and related matters, and we thought it was time to post something here about it. While Aleph One allows you to play the series, including Marathon 1, development on it has taken a route similar to ZDoom/GZDoom. Most of the work that has been done on it lately is in the vein of modernizing the engine and making it more modular. This includes plugin support, Lua scripting, and support for OpenGL renderers and HD textures/sprites. Although this improves the overall user experience, it moves the engine farther away from being a straight port of the original games. Also, while Aleph One can now use Marathon 1's original game files, it does not behave the same as Marathon 1 on the Mac, nor does it support playback of film files created with Marathon 1. One more thing to point out is that Aleph One has never introduced any kind of tests, so there isn't anything to prevent changes that change behavior compared to the original games -- a notable example of this is when Aleph One "fixed" the limit on active AI and later reverted it.

Now, continuing the analogy with GZDoom, we can point to Chocolate Doom as a comparison. Chocolate Doom is a Doom source port that tries to recreate the experience of the original DOS Doom games, keeping the original code intact wherever possible and retaining the original behavior and look-and-feel, including bugs. The only changes are fixes to game-breaking bugs and improvements to quality-of-life aspects like controls remapping.

As for other ports of the Marathon engine, Old Durandal took a similar direction to Chocolate Doom (though it did expand the capabilities of the original engine a bit), but development seems to have petered out several years ago.

Given all of this, a couple of other community members and I are currently in the early stages of creating a Chocolate Doom-like port of Marathon. The working title of this project is Chocothon. At first, this would just be a port of the M2/Infinity engine, but a further goal would be to fork the code and create an engine that is an accurate reimplementation of Marathon 1, since no such thing currently exists. That portion of the project would obviously be a considerable undertaking, given that there is no source code release for M1, but the "anachronisms" folders tucked away in Infinity's source code release coupled with decompilation of the original PowerPC binary should give us enough clues to light the way on what needs to be changed. That's the hope, anyway.

High-level goals of the project would be:

• accurately reproduce the behavior of the original trilogy
• emulate the look-and-feel of the original games, including their menu interfaces
• fix major game-breaking bugs, like the bug in M2's engine which stops the game after 15 levels are finished in a row
• write a suite of tests for the engine code which ensures the behavior is not changed
• (eventually) provide an accurate reimplementation of Marathon 1

Specific non-goals of this project would be:

• running scenarios which are intended for Aleph One
• implementing hardware-accelerated renderers
• extending the capabilities of the original engines

We wanted to float the idea here to see what people think, and whether the Pfhorums community has any suggestions on such a project. While technically this doesn't fit any of the categories of things suggested for the "Projects" forum, it seemed the most correct place to post this.

[The Man]

I’d definitely be interested in many of these goals. I’ve been encoding M2/∞ films incessantly over the past several months and have noticed that a few desync and many won’t play at all. I assume some of this is due to behaviour introduced since A1 became a thing.

Regarding your last bullet point under goals, I would be super interested in someday having M1 film playback consistent with the original game’s. Obviously this is a thing that would occur far in the future, if ever, since AFAIK M1’s source code is lost to the mists of time. I’m not entirely sure how much one can analyse the contents of memory to guess how the game reads film data, but I think a lot of people would be very happy not having to emulate a 680x0/PPC box to view M1 films (although my goal is, once I get an emulator up, to start encoding the entire contents of the Vidmaster Page archive for M1). And of course, beyond that, if M1’s film engine can ever get reverse-engineered, it’d also be cool to see everyone’s old M1 vid films in modern graphics.

In any case, I love the HD graphics and advanced capabilities of A1, but there are definitely points where it behaves oddly, and it’d be nice to be able to have a benchmark to compare to the original games to ensure the behaviour doesn’t get inconsistent with the original games’. I find myself noticing a lot of new quirks in the games as I keep playing them – I never noticed the troopers would sometimes jump into the water in “My Own Private Thermopylae” until this year, for instance, – and while A1’s film engine is consistent enough with M2’s (I’ve encoded some 100 M2 films and never seen a desync) that I don’t really think this is new behaviour introduced in A1, I can’t know.

Plus, of course, there are things where the advanced features don’t help. Speedrunning, for instance, obviously. You’d want as bare-bones a setup as possible so you don’t waste time on loading screens. (Your speedruns are cool, BTW. I’ve definitely learnt some new strategies watching them.) And, as you said, the big game-breaking bugs. The 15-level thing in particular annoys the hell out of me.

Anyway, this is just to say, yes, I think this is a good idea.

[treellama]

Like the rest of the developers, I agreed to work on Aleph One because I believe the community is too small to support multiple source ports. I encourage you instead to contribute to the issues that you mention: bug fixes and tests for Aleph One, and reports / fixes of Marathon behaviors Aleph One gets wrong. I am not aware of any differences in behavior between Aleph One and Marathon at this point, for what it's worth--we spent a lot of time getting that right!

If you're convinced Aleph One is a lost cause, you could contribute to Aleph Modular instead. It is (currently) a pure port of the Marathon 2 / Infinity source code, which aims to modernize things so that features can be added in a clean way. It only compiles for 32-bit Macs, which should satisfy your desire to have the original interface. We used it as a reference when restoring / verifying film playback.

Lastly, I must say I appreciate your adherence to the tradition of giving Marathon source ports truly stupid names

[Wrkncacnter]

Some of your goals overlap with AlephOne, and I know I've talked about this with you guys before, but I still don't get why you don't just fix bugs in AlephOne rather than making some brand new thing.

If you were to actually implement m1 accurately and fix films, it would be extremely disappointing if the fixes weren't put into alephone.

Just about everyone likes the enhancements AlephOne has added and has come to rely on them, so I doubt there would be very much interest in a second source port that tries to recreate the experience of the original trilogy exactly, without also having these features.

However, if you guys really want to spend a significant chunk of your lives on this port rather than fixing bugs in the source port people will actually use, why are you asking us? Just go for it.

[TBCR]

Like the rest of the developers, I agreed to work on Aleph One because I believe the community is too small to support multiple source ports. I encourage you instead to contribute to the issues that you mention: bug fixes and tests for Aleph One, and reports / fixes of Marathon behaviors Aleph One gets wrong. I am not aware of any differences in behavior between Aleph One and Marathon at this point, for what it's worth--we spent a lot of time getting that right!

I dunno if it's just me thinking this, but I feel that in a way that kinda defeats the point of Open Source culture. The size of something should not limit content to a particular thing. I agree with you on whole sale that the community is too small; You could say that it is considered 'niche'. But at the same time, the mindset of working on just a particular port due to the size of the community seems a bit silly (at least in my head). But eh, to each his own.

In terms of contributing, we are planning on still filing bugs for problems in addition testing things out. And later on down the road if there is something in chocothon that would help in fixing things in A1, we do not have any issue in helping to fix said issue in A1.

In terms of behavior, a particular example is how you teleport out of levels in Marathon 1. In the original macintosh version, you immediately start teleporting the second you exit the logoff screen(The XBLA version of Marathon 2 exhibits this behavior too). The A1 version follows the behavior of mac M2/Inf where it waits a tiny bit after exiting the logoff screen before teleporting out.

If you're convinced Aleph One is a lost cause, you could contribute to Aleph Modular instead. It is (currently) a pure port of the Marathon 2 / Infinity source code, which aims to modernize things so that features can be added in a clean way. It only compiles for 32-bit Macs, which should satisfy your desire to have the original interface. We used it as a reference when restoring / verifying film playback.

We (the group behind wanting to do this) don't actually think A1 is a lost cause. Considering what it is trying to do, which as aperture mentioned, is analogous to GZdoom, it's doing a (ftmp) good job. It's just we thought that there should be a chocolate experience for non-Classic mac machines.

On the subject of AlephOne, I am personally working on trying to get the kinks worked out setting up A1 snaps in linux. At the current moment, the snaps CTD when you go to save, which is a problem that I sometimes see on compiled builds of the github-master. This also ties into the mirata project I am working on, which should hopefully support both A1 and Chocothon for launching.
In addition, for people that would not want to do that and go for a more traditional "configure->make->make install", I am trying to determine the source of a problem regarding installing A1 from source on Fedora machines. Unlike on Debian based systems, ffmpeg refuses to compile in the source and it keeps spitting "-fPIC" errors. When you are able to install, there are mouse problems that prevent both Left & Right mouse from being pressed at the same time( when i can recreate this, i will file a bug report along with a video to go along with it.)

In terms of Aleph Modular, I did not actually know about that. When I get home today, I will take a gander at that on my iMac. The CVS repository seems to not load; Is it primarily coded in C like the Marathon 2 source?