Has anyone tried porting Chocolate-Doom to DOS?

Since there's no source code for Doom.exe, has anyone tried to port Chocolate-Doom back to the limits of DOS mode? Too bad the sound library would still have to be emulated.

Reason I ask? To have the source code to a vanilla Doom engine that can be run in DOSBox. The idea sounds odd, but it's all about the portability, so that if someone makes their own Chocolate-Doom fork, they would simply produce one DOS binary, capable of being executed on any platform that can run DOSBox.

Share this post


Link to post

Don't you still need to release a binary specific for each platform?

Share this post


Link to post
printz said:

it's all about the portability, so that if someone makes their own Chocolate-Doom fork

Don't fork Choco, then. Fork Mocha.

That way, you'll produce only one single "binary", that can be run on any platform that can run a JVM.

Share this post


Link to post
printz said:

Don't you still need to release a binary specific for each platform?

Yes, but using a crippled DOS binary in DOSBox seems exceedingly lazy.

Share this post


Link to post
Gez said:

That way, you'll produce only one single "binary", that can be run on any platform that can run a JVM.


...and even for that one, I needed to code in some hacks to handle the differences between the unequal handling of AWT/Swing/mouse/Java2D/sound between platforms, or provide alternatives (in particular for sound) so that eventually one that works might be picked, even if not ideal.

Only the "core" functionality (everything not directly related to the video/audio/user input) is guaranteed to be portable across compliant JVMs. Luckily, this includes practically all gameplay code and multithreading/HiColor hacks. However, in order for it to e.g. work with Android, Swing components must be swapped for Views.

For a hypothetical DOS JVM, it would depend on how AWT/Swing/Java2D/Java Sound would be implemented.

Share this post


Link to post
Gez said:

Don't fork Choco, then. Fork Mocha.

That's a good point. It would also help beta test Maes' project.

Share this post


Link to post
Xtife said:

I think you're missing the point of chocolate doom


x2

Share this post


Link to post
printz said:

Don't you still need to release a binary specific for each platform?

Don't you still need to release a binary specific for each platform, for DOSBox?

Moving what's being ported (DOSBox or Chocolate Doom) seems like a stupid idea. Plus, no, unless fraggle changed things since last I checked, Chocolate Doom only comes in three flavors: Windows binary, Mac OS X binary, source code. Linux distributions sometimes make their own precompiled Chocolate Doom binaries, but there is a very large overlap between people wanting to use Chocolate Doom and people capable of compiling it themselves.

Share this post


Link to post

I've thought about this before, as one of those "because it was there" sorts of things. Sound would definitely be the hardest part, although starting with SB16 would support many legacy systems as well as DOSBox.

HX DOS Extender might be something to try with the existing Win32 binaries. I remember being unable to get other GUI applications working (can't remember what they were or if any used SDL), but that was several years ago...

Share this post


Link to post

I'm not understanding the advantages here.

Cross platform support off of one binary sure, but dosbox still requires a different binary per platform. Also you can currently do this with good old doom2.exe. The novelty of having a full source replica of the vanilla doom source would be cool, but that's just it. It wouldn't be a replica. The sound system would need to be rewritten so that would be different, and chocolate doom is only 99.9% accurate to doom2.exe. The other .1% could perhaps be emulated because AFAIK most of them involve DOS trashing memory with direct writes to ram.. but it would be quite tedious and platform specific to a binary that you could only run in an emulator.

It'd just make the source harder to use and be a huge pain for something that seems to only be reinventing the wheel. Perhaps efforts would be better suited to more ports of chocolate doom?(I'm assuming you must run dosbox on a platform that isn't a PC operating system)

Share this post


Link to post
chungy said:

Chocolate Doom only comes in three flavors: Windows binary, Mac OS X binary, source code.

Let's be clear here: does Chocolate Doom's codebase allow me to change it ONCE, and there are automated processes to compile the Windows binary and the OS X binary (at least from user's endpoint)? I don't want to need to have two computers available.

Share this post


Link to post

It's something I have thought about in the past. GhostlyDeath hacked together a DOS port a while back, but never released it publicly, and from what little I know, he did it by stubbing out the SDL API as a wrapper around Allegro, which is completely the wrong approach to take. You can see for example that at the end of the video, when the ENDOOM screen pops up it's using libtextscreen's half size font - ie. it's actually emulating a DOS text screen under DOS!

Doing a proper DOS port ought to be fairly straightforward and a fun project for anyone who's interested. In terms of the main code, to get a basic port running you need to implement DOS equivalents of i_video.c, i_timer.c and i_swap.h. None of these are hugely difficult to implement (I even have some old bits of code that I wrote a long time ago that show how to do DOS VGA/timer/mouse stuff). With a little bit of effort you'll get a working port without any sound.

Chocolate Doom has several "mini libraries" that emulate DOS hardware - textscreen (the emulated text-mode display), pcsound (emulated PC speaker) and opl (emulated OPL/Adlib card). Each of these basically needs a single file added for DOS support, and because you already have the DOS hardware available to you, they should be trivial thin wrappers.

Do all this and you'll get you music but no digital sound effects, so you'd have to write some SoundBlaster interface code and probably a mixer to get something "complete". That's probably the most difficult part, in fact. After that it's a polishing job of implementing other less important things: joystick support, networking, other sound devices, etc.

If you're lazy you could use Allegro to do some of these things, but having used Allegro in the distant past, my general opinion is that it's probably more trouble than it's worth.

Share this post


Link to post

BTW, a large amount of the original DOS code is available in Heretic and Hexen (now GPL), which would offer some ideas on how to do a few things that vanilla did.

Unfortunately that doesn't include DOOM's original video code, since Raven rewrote it in Heretic. Seeing how that was done requires reverse engineering (it is very standard "Mode Y" though - VGA is divided into four virtual screens, which are made the active screen buffer in a round-robin fashion - the screens are not linear, so the write pattern is planar in I_FinishUpdate).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now