Doom 95: Yet more problems of mine...

[myk]

doomguy93 said:
I think the bug looks something like this: http://www.flaterco.com/kb/DOOM/DOOM95_Invis.png

Joe667 said:
OK. But in mine they didn't just look messed up, they weren't invisible. They were black with random glitch pixel garbage covering them. :)

Either way, these issues should go away if you launch the game from a command line or Run console with -emulate (typing doom95 -emulate instead of just doom95). Arguably, the easiest way to apply it is to add it in the command line in a shortcut.

[Avoozl]

I don't understand why Chocolate Doom has to be restricted to the older monitor sizes, Doom only used them as they were the only resolutions available at the time, I don't see why it has to remain that way now.

[dg93]

Megamur said:

Chocolate Doom is the port most accurate to the original DOS Doom's behavior. Almost every facet of the original game is emulated, and virtually all WADs created for vanilla Doom will work perfectly in Chocolate. Most other source ports add extra features that make them play slightly differently, and can cause incompatibilities with old maps, but that's not a problem with Chocolate. Chocolate Doom is also far more stable than Doom 95 ever was.

Thanks for the information. I'll look into that source port. I started off with doom 95 as a kid, then zdoom 1.22. My personal favorite is Zandronum.

[Maes]

Avoozl said:

I don't understand why Chocolate Doom has to be restricted to the older monitor sizes, Doom only used them as they were the only resolutions available at the time, I don't see why it has to remain that way now.

Supporting any resolution other than 320 x 200 at the engine level (before it's even rendererd to the screen) requires adding quite a bit of code to handle the scaling, even assuming that the aspect ratio doesn't change.

Strangely, the actual rendeder is the easiest part, you literally need just to change two constants in the source code (SCREEWIDTH and SCREENHEIGHT) and maybe fix a couple of column rendering functions, but the fixed-scale graphics like the titlepic, status bar, fonts, menus etc. are another matter, and require per-module hacks and additional rendering functions (different ports use different approaches). Changing aspect ratios to support widescreen or arbitrary resolutions/FOV is even more complex.

As you can imagine, this would stray Chocolate Doom quite a bit from its intended purpose. It's prime material for a fork, however.

[Gez]

doomguy93 said:

I've never used the source port "chocolate-doom"
What makes it more unique then all the other source ports?

Ports tend to try to fix bugs and add features. Choco is about preserving the Doom experience as exactly as possible, warts and all. So, if something made vanilla Doom crash? Then it'll make Chocolate Doom crash. It's not a bug that it crashes in Choco; to the contrary, it's a bug if it doesn't crash!

This is especially useful as a test engine for mod creators, because if they get something to work on Choco, they can be sure it'll also work on vanilla.

But Choco does have a few additional features compared to vanilla, though they're generally limited to emulating software with which vanilla Doom could be used (e.g., Dehacked) or hardware (e.g., OPL playback). The only real deviation is the netcode: the old IPX-based P2P code was replaced by a modern client-server code. That means you cannot connect Chocolate Doom to vanilla Doom in a netgame. That's about all.

More info

Avoozl said:

I don't understand why Chocolate Doom has to be restricted to the older monitor sizes, Doom only used them as they were the only resolutions available at the time, I don't see why it has to remain that way now.

Choco isn't restricted to monitor size. Just to 320x200 effective resolution, with pixels being scaled to fit the actual resolution.

[Wagi]

Maes said:

Strangely, the actual rendeder is the easiest part, you literally need just to change two constants in the source code (SCREEWIDTH and SCREENHEIGHT)

There are actually several different places where they use "magic" numbers like 320 and 200 (or divisions of that like 160 and 100) rather than the macros, so you have to hunt those down first.

[fraggle]

Avoozl said:

I don't understand why Chocolate Doom has to be restricted to the older monitor sizes, Doom only used them as they were the only resolutions available at the time, I don't see why it has to remain that way now.

Chocolate Doom is a Doom source port that accurately reproduces the experience of Doom as it was played in the 1990s.

Maes said:

As you can imagine, this would stray Chocolate Doom quite a bit from its intended purpose. It's prime material for a fork, however.

I'm hoping Doom Retro can fulfill this kind of use case.

[Guest Unregistered account]

Mike.Reiner said:

On my Windows 7 x64 system using Beetlejuice's mouse fix I have it working properly.

Same here. It's what allowed me to use source ports back when I had that crappy computer. I was overjoyed until I tried getting it working with anything other than the Ultimate Doom and couldn't. I hear it's possible, though. It doesn't matter anyway, because that was in the past.

myk said:

Either way, these issues should go away if you launch the game from a command line or Run console with -emulate (typing doom95 -emulate instead of just doom95).

I'm aware... so yeah.


Hey, that rhymes.

[bradharding]

fraggle said:

I'm hoping Doom Retro can fulfill this kind of use case.

So do I... I'm working on it!