Chocolate Doom

why would any 1 want to remake doom95 with bad graphic's

Thorgrim103 said:

and skulltag keep the experience but enhance it.

Skulltag barely keeps the original doom feeling anymore, which is to be expected with a modern day doom engine sourceport.

Risen3D is the closest thing to Vanilla Doom.

Or just run Doom.exe in Dosbox

David_Dweedle said:

Risen3D is the closest thing to Vanilla Doom.

Somehow I doubt that. Mabye unless you don't have any of the high-res stuff and it has a software renderer to fall back on, but that's unlikely given the intentions of the port.

(and what's with the edit button being so close to the quote button? I hit it too many times by accident :P)

I'm pretty sure he was just trolling as usual.

I like playing natively in DOS, you get fancy OPL3 sound and there's something about the way framebuffer 320x200 scales up on my monitor that makes the lighting look way better than PrBoom or DOSBox in Windows or Linux.

You also get to spend about half an hour fucking around with CONFIG.SYS and AUTOEXEC.BAT whenever you change anything, have to try several different mouse drivers to find one whose acceleration options you like, and then once you get into the game you have to quit and restart when you find you've forgotten to launch NOVERT.

The old display res does take a bit of adjusting once you get used to playing at modern screen modes, but recently revisiting DOS play has made me change back from 1024x768 or higher to 640x480 for a more classic feel.

Super Jamie said:

you get fancy OPL3 sound

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

exp(x) said:

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

I have seen. Does that compile and work yet? I was under the impression opl-branch was just Fraggle's non-functional hackings so far.

Edit: Well, whaddya know, it does. It's not perfect (E1M8 wtf) but what's there is a really good emulation. That's the ScummVM OPL code, what does ZDoom use? The non-GPL MAME code? The two sound different to me.

Super Jamie said:

The two sound different to me.

Just like the real OPL cards I had...

Of course :) Hardware OPL might be "the real thing" but all the 15 yearold analog circuitry and cheap preamps does tend to produce a more muffled sound. Quality-wise, I think ZDoom/DOSBox is more pleasant to listen to than my old ISA SB16.

LogicDeLuxe's Dual-OPL3 Maestro recordings are pretty good, but he's also a professional sound engineer so no doubt they've had a bit of remastering.

That being said, an actual Roland Sound Canvas blows everything else out of the water!

exp(x) said:

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

OH DAMN SO CLOSE

David_Dweedle said:

Risen3D is the closest thing to Vanilla Doom.

quake2 is the closest thing to vanilla doom, get it rite, homosex.

Found something which I would consider a bug.

Whenever I play CDoom in fullscreen mode (resolution does not matter) and the screen flashes (picking up something, getting hurt) as well as when the level end wipe is done there is some serious lag for half a second or so.

I got a GeForce 9600 GT and I just installed new drivers to make sure that's not the problem.

It does only happen in fullscreen, windowed mode is fine.

That's probably an SDL bug.

It's actually an NVIDIA bug; they have huge issues with paletted color modes.

I also heard that this is caused by bad coding in SDL.

Windows or Linux?

This also happens in non-SDL games (Try Winquake). This is nVidia's fault. It has happened for new drivers for the entire Geforce line for a very long time (2005).
The only workaround for this, is to show the game into some 24/32-bit video mode so modern video hardware doesn't whine.

leileilol said:

This also happens in non-SDL games (Try Winquake). This is nVidia's fault. It has happened for new drivers for the entire Geforce line for a very long time (2005).
The only workaround for this, is to show the game into some 24/32-bit video mode so modern video hardware doesn't whine.

There was a point where nvidia's drivers completely broke WinQuake.

Windows. And Winquake runs perfectly fine here and does not jerk at all at any given moment.

@Ptoing:

Have you tried switching Chocolate's preferred display driver from DirectX to Windows GDI via the Chocolate Setup? The GDI seems to work a whole lot better at least for me.

Wow, thanks. This works like a charm.

If that's the problem you're having try using fraggle's SDL patch and switch back to DirectX.

Thorgrim103 said:
I'm just saying this due to the fact i played the window's version of doom. I found it odd that the older version wasn't really the same to say doom 95.

Doom95 was made later, by Microsoft employees, using Window's Direct X technology to render 640x400 or 640x480, which would have lagged horribly in DOS when DOOM came out. Early on few few systems could use 320x200 without slowing the game down too much, so some people had to use low detail mode (try it; it's even blurrier) or a screen blocks setting under 10, where you see the action in a smaller window within the game. By the time more powerful tech was getting more common, id Software had pretty much left DOOM behind, being busy with Quake.

myk said:

Doom95 was made later, by Microsoft employees, using Window's Direct X technology to render 640x400 or 640x480, which would have lagged horribly in DOS when DOOM came out.

... if the hardware was even capable of displaying higher resolutions at all.

myk said:

Early on few few systems could use 320x200 without slowing the game down too much, so some people had to use low detail mode (try it; it's even blurrier) or a screen blocks setting under 10, where you see the action in a smaller window within the game. By the time more powerful tech was getting more common, id Software had pretty much left DOOM behind, being busy with Quake.

The memories...
On the first system I played Doom on (80386, 40 MHz, 6MB RAM) anything more than screenblocks 8 with low detail was completely unusable. It was a major improvement when I upgraded that and suddenly could play fullscreen with high detail.

Still, by the time DN3D came out it went downhill for me because I couldn't stand the low resolution anymore and I only picked Doom up again when I got my hands at the first decent source port that implemented high resolution support (Doom95 was close to useless, even in 1995...)

I'm not really bothered by the original resolution, but I won't use Vanilla/chocolate doom for anything that isn't the original iwads.

Honestly, the sheer fact that I despise waiting for my monitor to change resolutions is enough for me to just play PrBoom+ instead at my monitor's native resolution, which looks great now thanks to the recently added widescreen support.

Thorgrim103 said:

I was playing chocolate doom, and i was surprised to see at how the line of sight was so blurry. I'm thinking this is due to me playing skulltag for so long but it felt odd and strange. the graphics felt inferior to doom95.

I just find it odd that i suppose what i'm talking about is the draw range is so low for the original doom. while doom 95 and skulltag keep the experience but enhance it.

Chocolate Doom renders everything at 320x200, regardless of the resolution. The purpose of it is to be an accurate recreation of DOS Vanilla Doom. If you don't like it, I suggest you use a different port (there are certainly plenty to choose from!). I don't mean that in an arrogant way, it's simply not intended to be for everyone. Basically, it's a nostalgia trip, but if you're perhaps young enough to never have played under DOS, you're unlikely to understand.

Super Jamie said:

Edit: Well, whaddya know, it does. It's not perfect (E1M8 wtf) but what's there is a really good emulation. That's the ScummVM OPL code, what does ZDoom use? The non-GPL MAME code? The two sound different to me.

I'm still working on it :-) The MIDI playback isn't perfect yet, the most obvious thing missing is pitch bend, which I've figured out but haven't written the code for yet.

I'm using the ScummVM code for the time being because it's something I know is GPL compatible. I'm looking at other options, though (and leileilol has been giving me some useful tips). I've also had it driving the hardware OPL on my YMF724 sound card, but hardware OPL support only works on Linux so far. Hardware OPL is more difficult on Windows (you need a port I/O driver) but it will be added.

Mike.Reiner said:

I'm not really bothered by the original resolution, but I won't use Vanilla/chocolate doom for anything that isn't the original iwads.

Honestly, the sheer fact that I despise waiting for my monitor to change resolutions is enough for me to just play PrBoom+ instead at my monitor's native resolution, which looks great now thanks to the recently added widescreen support.

Why is this a problem? Run it at your native resolution and set startup_delay to 0.

That ScummVM code sounds pretty good, more accurate in parts than ZDoom's emulation. It would probably be difficult to do a whole lot better.

After that you should totally implement OPL3 emu as a Linux driver which presents itself as an Alsa MIDI port :) Well, I can dream.

fraggle said:

Why is this a problem? Run it at your native resolution and set startup_delay to 0.

startup_delay isn't a problem, I don't mind doom's typical load up, it's that I hate my monitor's back light going off and on.

The reason this is a problem is because I have to set Chocolate-Doom to run at 1680x1050 (my native), and that causes the game to stutter.

Super Jamie said:

That ScummVM code sounds pretty good, more accurate in parts than ZDoom's emulation. It would probably be difficult to do a whole lot better.

After that you should totally implement OPL3 emu as a Linux driver which presents itself as an Alsa MIDI port :) Well, I can dream.

Linux does have an OPL3 driver, and I wrote a script that converts the doom GENMIDI lump into .o3 files that can be loaded by it so that the driver will use the same patches. That only works if you have a hardware OPL though, obviously, and it still won't sound exactly like Doom.

What you describe isn't actually that implausible though. You can already use Timidity as an ALSA MIDI sink in the same way.

Mike.Reiner said:

startup_delay isn't a problem, I don't mind doom's typical load up, it's that I hate my monitor's back light going off and on.

The reason this is a problem is because I have to set Chocolate-Doom to run at 1680x1050 (my native), and that causes the game to stutter.

Your computer probably isn't fast enough to scale up to that resolution at full frame rate. Only suggestions I can think of are to upgrade or run the game in a Window.

If you run it fullscreen with -timedemo demo2, what frame rate do you get? If it's almost at 35fps, bumping the optimisation level to -O3 on compile might be enough to get it at an acceptable speed.

fraggle said:

Your computer probably isn't fast enough to scale up to that resolution at full frame rate. Only suggestions I can think of are to upgrade or run the game in a Window.

If you run it fullscreen with -timedemo demo2, what frame rate do you get? If it's almost at 35fps, bumping the optimisation level to -O3 on compile might be enough to get it at an acceptable speed.

Odd, considering I can run Vanilla doom in dosbox with the resolution set to native at full speed.. hm. anyway.

-timedemo demo2 gave me:
Timed 2001 gametics in 275 realtics (254.672727 fps)


Edit:..aahhhhh I see now.

I ran the game originally in DirectX, I was playing around and swapped to Windows GDI, and then I ran the timedemo, and it gave me that framerate.

Switching back to DirectX, the timedemo barely managed to keep 30+ fps.

Well then, this is resolved. I just need to run in Windows GDI rather than DirectX. Sweet.