the neverending search of carlos (author of cdoom)

I'm sure you already know about the source port cdoom, made by carlos (or so he claims) and is a derivative of MBF. I have been trying to get in contact with this" carlos" since 2010 and every E-Mail I have sent is suspiciously" lost" as the E-Mail addresses are invalid. Funny that, as the E-mails change with every release and have asinine names like" Robocop".

My guess is that the E-mail addresses are valid just long enough for Ty to approve the submission into/ idgames and then pulls the plug on them. Very unprofessional.

So here is my plea: anyone here that knows this" carlos" please get in contact with him. I've been trying to send him bug reports for years and nothing doing.

it's a pity that he's so hard to find. The weird thing is that he does upload levels made for cDoom from time to time, and apart from some of the early ones, the most recent one I reviewed (multi.wad) was actually pretty decent (converted from an EDGE level), and port itself was not half-bad either, feeling like a sort of "poor man's ZDoom".

Well, I could always add support for the cDoom map format in Mocha ;-)

And there is zero documentation on it. Cdoom supports hires mode but the commandline switch was never documented.

Well, at least the SC has been released, even in it has been purged even of the linuxdoom comments -_-

I actually gave it a glance once, to see how he pulled that fake 3D trickery (which was fairly convincing BTW), and it was not actually that hard to figure out (assuming of course you're familiar with The Code of Doom).

Oh? Can you make a short list of the commandline params?

ROFLMAO

const char *const standard_iwads[]=
{
  "/Robocop.wad",
  "/doom2.wad",
  "/plutonia.wad",
  "/tnt.wad",
  "/doom.wad",
  "/doom1.wad",
};

Holy shit, I better update Mocha right now, I didn't know Robocop.wad is one of the standard iwads :-p

printf("\nCredits to Jesus Christ\n");

...ok, I guess it beats me making sly remarks about John Romero's bitch-making abilities in my code...

To the point: d_main seems to have no additional parameters stuffed in, other than the usual vanilla Doom ones. I will check the whole source tomorrow with dev-c++ to see if M_CheckParm is called elsewhere with more fancy parameters, but don't hold your breath.

Another Cdoom fail: no stereo sound effects. Hell, even doom legacy had stereo.


If there was a good DOS port with dehacked support and good music (and cdoom's music support is amazing) I wouldn't have to use robocopdoom.

MBF with every single comment removed.

*shudder*

And it looks like he uses a custom crt0.s?

I wouldn't even want to try to compile this behemoth, let alone understand it.

Csonicgo said:

Another Cdoom fail: no stereo sound effects. Hell, even doom legacy had stereo.


If there was a good DOS port with dehacked support and good music (and cdoom's music support is amazing) I wouldn't have to use robocopdoom.

Best bet would be to chop out the music code and backport it to MBF. According to the one paragraph of documentation in the entire archive, the music player is from some other dude's "musplay" library.

http://www.fit.vutbr.cz/~arnost/muslib/index.html

This is a slightly older version of it than what's in cdoom, but it has comments, which is probably worth quite a bit.

That backporting idea sounds doable. Unfortunately I have no idea how to compile under DOS, nor do I know the doom sourcecode well enough to backport things like that....any volunteers? :3

Any particular reason? CDoom never seemed a particularly interesting port.

fraggle said:

Any particular reason? CDoom never seemed a particularly interesting port.

There are actually one or two interesting maps, and an easily understandable "3D" map format extension, but other than that, it's just like a poor man's ZDoom.

@Csonicgo: there's nothing in the whole codebase suggesting that it ever took a "-hires" or similar parameter, or that hires modes were ever supported: it uses the same old hardcoded SCREENHEIGHT = 200 and SCREENWIDTH = 320 everywhere (sometimes, there are even hardcoded literal "320" or "200"!). The only "exotic" parameter compared to vanilla is "-blockmap", which forces regenerating the blockmap, and even that is not something CDoom-exlusive.

fraggle said:

Any particular reason? CDoom never seemed a particularly interesting port.

Because I am stuck with a POS computer all summer, and every DOS Doom port seems to suck. :P

Vanilla doom also locks up in windows on the Timer.

If tjere was a port of Chocolate Doom to DOS with doom+ extended limits.....:P

CDoom always struck me as a bit of a joke. This "Carlos," even if you manage to reach him, is unlikely to have the interest or skill to take your concerns seriously.

Creaphis said:

CDoom always struck me as a bit of a joke. This "Carlos," even if you manage to reach him, is unlikely to have the interest or skill to take your concerns seriously.

Well since he was using fake email addresses its enough to get his submissions removed! That will bring him up from the depths!

You could always use EE 3.31 beta 7 lol lol lol. :P

Csonicgo said:

If tjere was a port of Chocolate Doom to DOS

I've actually thought about doing this in the past, but I've never been able to justify it as anything other than a huge waste of time.

Csonicgo said:

Well since he was using fake email addresses its enough to get his submissions removed! That will bring him up from the depths!

Probably not. I'm sure many PWAD authors that uploaded stuff long ago have moved on and don't even play Doom anymore. And a lot of email addy's probably aren't valid anymore (esp. stuff like .edu, .mil, .aol, etc.) This guy seemed to have a handful of subdomains on zzn.com. Who knows why, but it doesn't mean they were bogus. Back in the day, I changed my email domain many times, for frivolous reasons (dyndns made it so easy), and that's not even counting dozens of ISP changes over the years.

Heck, this guy might even be dead, for all you know. You need to rethink the usefulness of an email addy in the TXT file past a certain point in time. ;)

Anyway, why don't you take this as an opportunity to port chocodoom to DOS? The SDL libraries are already ported, and lots of other GNU tools also. It shouldn't be that hard. Maybe you can learn something in the process.

Edit: oh I just checked and I was wrong, there's no SDL for DOS or Win9x. I guess you're out of luck, unless you want to port it yourself, or convert the SDL calls to another API (there should be a bunch of those, check DOS demoscene sites).

fraggle said:

Any particular reason? CDoom never seemed a particularly interesting port.

Says you. I find it pretty interesting to dig through a rarely-used port for neat features, like the 3d mode Maes was mentioning.

fraggle said:

I've actually thought about doing this in the past, but I've never been able to justify it as anything other than a huge waste of time.

Well, dehacked and NWT wads are amazingly annoying with vanilla doom. :P


And at the moment, im stuck in the boonies with a 90s DOS machine. Wahhh.

Csonicgo said:

Well, dehacked and NWT wads are amazingly annoying with vanilla doom. :P


And at the moment, im stuck in the boonies with a 90s DOS machine. Wahhh.

How slow is this computer that it can't run any non-msdos doom ports? If you can run even win95 on it, you can use prboom and earlier zdooms.

Whatever you're using to post messages to doomworld should be fast enough too (if not computer, some sort of smartphone?)

If my Nintendo DS (4 MB RAM, 67 & 33 MHz ARM chips) can run this, then any decent DOS box should be able to handle PrBoom. Maybe not the MP3/OGG stuff, but at least the basics and regular MIDI music.

And actually, why are you choosing to limit yourself to DOS/Win9x anyway? That kind of old hardware sounds like the perfect candidate for running a Linux distro or something that can run modern Doom ports (Chocolate, PrBoom, Odamex, Doomsday, possibly others...) You don't even have to completely replace the current OS. One common strategy is to repartition (or add second HD) and dual-boot. Another is to install onto a USB key or other removable disk. Another is to use a live CD, like Knoppix. If the BIOS is ancient, you might have to create a boot floppy, but nothing is unsurmountable.

Yeah I am using a smartphone. The reason I can't upgrade to WIN95C IS DUE TO DRIVERS. Seriously hate that, but meh.


Edit: had no idea prboom was in DOS. Is it the most recent?


Edit: hell no I am not putting linux on it. 850 MB HD, 48 MB RAM, you must be joking. I know how to use DOS pretty well, not linux, and in the woods with no docs ain't the time to learn linux to the point of making my own distro.

And I know zero about programming in DOS. Not everyone here is that gud at computer. At least, not yet.

And before you ask, no, not gentoo, not Arch. The only problems with cdoom are the mouse and the oddity of the sound effects being in mono. But since no one can understand the code, I guess I am screwed and will have to play mods the old school way: with dehacked and NWT. :P

Well at least mouse isn't critical in Doom. I always play with the keyboard only, since I don't like mice (and they don't like me). If you use these keybinding, it actually works quite well:

ESDF for movement (or WASD if you prefer that)
J : turn left
L : turn right
I : use (doors, switches, etc.)
K : for special port functions, if any (example: 180-degree turn in PrBoom, jumping in Odamex)
SPACE : fire

Interesting port, but as soon as I move the mouse - it hangs.
Ran it via DosBox0.74.

hex11 said:

If my Nintendo DS (4 MB RAM, 67 & 33 MHz ARM chips) can run this, then any decent DOS box should be able to handle PrBoom.

Define "decent DOS box". Some might say a Pentium 75, some may not wish to step below a Pentium-166, while other will consider a "high-end" 486 (e.g. DX2/80 or DX4/120) to be the "ultimate in real DOS", while some might even consider the Pentium II to be the last true DOS platform.

And let's not even get started about RAM, which was ridiculously expensive and rationed those days. Typical DOS/Windows 95 era RAM was between 8 and 16 MB of RAM or even less. And that is definitively not enough to run any modern Linux distro, as even DSL will not run with less than 12 MB of RAM, and then it will only do so with no graphics. For those, you'll need the "luxury" of 24 MB, and then again I'm sure it will lack way too many libraries and functionality to even run something like prBoom.

And, BTW, wasn't the original Boom actually too heavy for an otherwise vanilla-capable 486 to handle?

BTW, CSonicgo, you haven't laid out the specs of the machine you're stuck with yet. If it's not too old as not to be able to run Windows 98, then you could use prBoom or even ZDoom natively (I've done it on a Pentium 200 with 64 MB of RAM, and at 640x480 it's OKish).

Decent (for me anyway) is like a P120 with 32 MB. Back in the day (1996), that was sufficient to run even OS/2 comfortably. Linux only needed 8 MB (16 MB if using X) to run great. And with those specs, regular DOS gaming was awesome, except the config.sys and related stuff (QEMM, Deskview, meh...)

These days you want more RAM, because Linux has gotten more bloated. But you don't need tons. Slackware will install on 64 MB, and so will OpenBSD. My OBSD laptop has 1/2 GB, but hardly any of it is being used at the moment, in fact only about 64 MB if you subtract the 128 MB RAM disk I have mounted on /tmp (a luxury). The rest of my memory is sitting idle, and no swap is used. And that's while running Xorg, twm, some xterms, tmux, a bunch of shells, graphical web browser (Links 2.2), and mplayer (playing OGG file). Oh Yadex shell is still running too, but not the GUI. :) Of course the typical system daemons are running also (syslogd, pflogd, lpd, inetd, dhclient, sendmail, and some other things).

If you went with Linux, you could even do away with Xorg completely and use the framebuffer console. Sadly OpenBSD doesn't have that option on i386 architecture (on Sparc and some others it does). So I think you'd probably manage fine with just 64 MB, even today. Just don't run daemons/programs you don't need, don't load unnecessary drivers, and stay away from Gnome/KDE/etc. "desktop environments" and other memory hogging junk. ;)

Edit: Oh, and of course the obvious solution for the really old, "only 8MB RAM" 486: just download an ancient Linux distro. I did have such a machine in 1995, and it had no problems running contemporary Slackware, svgalib doom port (id's binary compiled by Dave Taylor), with OPL3 music provided by musserver. :)

Linux wont help. No port that I know of would even run in those conditions so why bother? It sounds more crippling than DOS.

SPEC:
P133
850MB HDD
48MB EDO RAM
Windows3.11 w/ MS-DOS 6.22
Sound Blaster 16
Motorola Modem (dunno the model no. yet)
40x Backpack External CD-ROM (parallel connection )

printz said:

Says you. I find it pretty interesting to dig through a rarely-used port for neat features, like the 3d mode Maes was mentioning.

Not a criticism, just an honest question.

Csonicgo said:

Specs

That's just BEGGING for Windows 98, which will give you access to at least ZDoom and prboom (dunno about prboom+). You can also probably safely overclock the CPU to 166 MHz for some extra bang. Exactly what driver issues would prevent you from doing that?

Windows 3.11 is just too crippling: it will only "see" 16 MB of RAM, and will run practically nothing using even the earliest DirectX. Unless you are ready for looooong sessions of solitaire ;-)

hex11 said:

Edit: Oh, and of course the obvious solution for the really old, "only 8MB RAM" 486: just download an ancient Linux distro. I did have such a machine in 1995, and it had no problems running contemporary Slackware, svgalib doom port (id's binary compiled by Dave Taylor), with OPL3 music provided by musserver. :)

I had seen some 486DX4/120 running Redhat in 1998 with only 12 to 16 MB RAM (uni lab, heh), but lower than that? Doom itself needs 8 MB of "clean slate" RAM to comfortably play large stuff without trashing, anything heavier than plain, single-tasking DOS ain't gonna help.

linuxsdoom (svgalib) worked well enough on my 8 MB 486 that I didn't boot back into DOS to run Doom. Of course, I was playing 1995 PWADs, not the ultra-detailed huge levels of today...

My 486 actually used to have only 4 MB RAM, and there was no way to run Doom like that, not without ending up in swap hell. Compiling 1.2.x kernels took about 7 hours. The only way to run X11 was via the TinyX distribution.

Anyway, with Windows 3.11 he could run this:
http://en.wikipedia.org/wiki/Castle_of_the_Winds
:)