Slashdot Mirror

Would you like to revise your information? DOOM engine renders at 320x200 (16:10 aspect ratio). You'll also find that the memory space for 320x240 is the SAME (it's a VGA mode which uses a more efficient algorithm) as the CGA 320x200 mode (which in 1993 was STILL the most common graphics mode available to MOST PC users hence the denominator for developers). Also, the only reason to split the screen was during multiplayer mode on console (eg Saturn, N64). It makes absolutely no sense to bank the screen quadrants when you're using the same amount of memory to render and MORE memory (and processor clocks) to stitch the quadrants.

If you wanted a native linux Doom with OPL midi without DOSBox, you could use Chocolate Doom... It's designed to be cruft-less.

If you wanna play Doom like it's 1993, there's always Chocolate Doom...

Better to use chocolate doom for playing your Doom games, it has a good OPL styled music playback and the original setup program that works on Linux with Ncurses.

Get it here. Works very well on Fedora Core 16.

I don't have any, but there is a proof:

http://www.chocolate-doom.org/wiki/index.php/Command_line_arguments

Networking options
-left
    Run as the left screen in three screen mode.
-right
    Run as the right screen in three screen mode.

This doesn't seem much smaller than Tom Fine's Atari-Small font (maybe a pixel shorter?). I expanded this font to a full DOS extended ASCII version for my Doom source port.

Chocolate Doom, at least doesn't screw up the physics and doesn't try to look 'better'.

Ironically the submitter of this news wrote this port. If only more games had truly purist ports like these... Wolf3D, ROTT, Quake and Descent suffer badly without them.

I'm the author of Chocolate Doom, which deliberately maintains the low resolution of the original game, but has to run in modern, high resolution screen modes. One of the problems with Doom is that the graphics are designed for non-square pixel modes (the original game ran in 320x200, stretched to a 4:3 aspect ratio screen), so there's the double problem of having to scale everything up to work in a square pixel screen.

I developed a technique that does a blocky scale-up, interpolating the edges of the blocky "pixels" appropriately, so that you end up with a fairly decent looking result. I don't know if this is useful to the developers of programs like DOSBox, but the code's there if anyone wants it.

I'm the author of Chocolate Doom, which deliberately maintains the low resolution of the original game, but has to run in modern, high resolution screen modes. One of the problems with Doom is that the graphics are designed for non-square pixel modes (the original game ran in 320x200, stretched to a 4:3 aspect ratio screen), so there's the double problem of having to scale everything up to work in a square pixel screen.

I developed a technique that does a blocky scale-up, interpolating the edges of the blocky "pixels" appropriately, so that you end up with a fairly decent looking result. I don't know if this is useful to the developers of programs like DOSBox, but the code's there if anyone wants it.

I'm the author of Chocolate Doom, which deliberately maintains the low resolution of the original game, but has to run in modern, high resolution screen modes. One of the problems with Doom is that the graphics are designed for non-square pixel modes (the original game ran in 320x200, stretched to a 4:3 aspect ratio screen), so there's the double problem of having to scale everything up to work in a square pixel screen.

I developed a technique that does a blocky scale-up, interpolating the edges of the blocky "pixels" appropriately, so that you end up with a fairly decent looking result. I don't know if this is useful to the developers of programs like DOSBox, but the code's there if anyone wants it.