ZDoom LE (Legacy Edition)

[drfrag]

Finally i've released this @GitHub, now i'll copy the readme file.

https://github.com/drfrag666/gzdoom/releases

I've released ZDoom LE 2.8.3a (GL 1.8.4c) JAN 25 2019 but i don't feel like writing a changelog anymore. It's a VS 2013 build for even better performance, the MinGW build is included for win98 compatibility.
Hotfix reuploaded on FEB 14.

https://github.com/drfrag666/gzdoom/rel ... 2.8.3a.zip

--------------------------------------------------
ZDoom LE 2.8.2a (GL 1.8.4b) APR 10 2018
--------------------------------------------------

ZDoom LE (Legacy Edition) is a fork of the ZDoom 2.8.1 maintenance branch (https://github.com/rheit/zdoom/tree/maint)
for Windows 9x and old machines. Now merged with GZDoom as of august 2013.

Changes/features since 2.8.2:
- Added light definition for megasphere.
- Added unexploredsecretcolor variables to mark undiscovered secrets differently in the automap.
- Several bugfixes.
- Fixed GL performance regression.
- Restored XInput and FluidSynth support.

Changes/features since 2.8.1b:
- Changed savegame list order, now they are sorted by slot number instead of alphabetically.
- Added hqNx MMX HQ resize modes to the GL renderer.
- Fixed security issues (execution of unsafe commands and ACS stack checking).
- Lots of official bugfixes.
- More compatibility fixes.
- Not optimized for ancient hardware anymore.

Changes/features since 2.8.1a R3:
- Added new 3x2 and 4x4 low detail modes.
- Increased size of the savegame comment area.
- Fall back to software renderer with unsupported OpenGL version.
- Fixed crash with textures larger than those supported by the hardware in the D3D backend (BD v21).
- Added an option to add elements to an existing options menu.
- Added four text colors: ice, fire, sapphire, teal.
- Several more old bugfixes not present in the maint branch.

Changes/features since 2.8.1a R2.1:
- Included old OpenGL renderer from GZDoom 1.8.4 with later fixes (off by default). Requires GL 1.2 support.
- Added xBRZ scaler to the GL renderer.
- Autoloading of brightmaps.pk3 and lights.pk3.
- More modern default keyboard layout.
- Command versions of the original Doom cheats.
- Render cull options (sprite and wall distance) to increase performance.
- Fixed skies during the wipe and wrong weapon scale in savegame pic for low detail modes.
- added MF7_NOINFIGHTSPECIES flag.
- More iwad compatibility fixes.
- Some important ZDoom fixes not present in the maint branch.
- Switched to FMOD Ex 4.36 for sound.
- Updated Game-Music-Emu library.

Changes/features since 2.8.1a R2:
- Fixed bug introduced in the maint branch, A_SpawnItem was broken.
- Fixed the timing of Heretic's lava damage.
- Added some wad compatibility fixes mainly for the Doom II, Doom and Heretic iwads.
- Added WadSmooth iwad support.

Changes/features since 2.8.1a:
- Restored Direct3D renderer.
- Fixed sky scaling in low detail modes.
- Added video menu options to switch between d3d and ddraw and set ddraw display bits for compatibility.
- Usernames for ini files are back on win2k and later.
- Proper startup banner modification.
- More engine defaults changed for performance.
- Some more official fixes.
- Now compiled for pentium ii architecture but there's no performance difference.

Changes/features since 2.8.1:
- Includes later fixes from the maint branch and some more.
- Compiled with pentium architecture optimizations.
- Low detail modes have been restored. Added a new quad horizontally and double vertically mode for a somewhat retro
look, you can get the original low detal mode from 640 and it's playable even @320. Unfortunately it gives the same
performance as doubling horizontally and vertically.
- A more retro looking startup console.
- Engine defaults changed for slower machines.
- Runs on windows 95 but without the startup log.
- No direct3d nor xinput joystick support, only classic directdraw mode.
- Uses a modified openal compatible with windows 95 as sound backend.
- Compiled without fmodex support but should work, it's untested though. Fluidsynth doesn't work with openal and
could even crash on certain machines so no fluidsynth support either.
- Hardware midi doesn't work on modern windows versions, it does on win9x.(*)
- If you experience sound problems on very slow machines try reducing the sound channels to 8.
- To set the default video mode on pentiums sometimes you need to press enter twice.

Minimum estimated system requirements are: Pentium 133, 16 mb of ram, 1 mb svga card and windows 98.
Tested on a Pentium 90 with 32 mb of ram and a trident 1 mb graphics card on win95c, i get 22 fps @320x200.
Don't try to turn on rendering interpolation on a pentium mmx, it's extremely slow.
For OpenGL mode a graphics card with GL 1.2 support is required.

(*) For modern windows i recommend CoolSoft VirtualMIDISynth with the following soundfonts: Roland SC-55,
Yamaha DX50XG and AWE64 Gold from https://www.vogons.org/viewtopic.php?f=9&t=45600.
A good alternative is the Yamaha S-YXG50 Portable VSTi software synth at http://veg.by/en/projects/syxg50/.

NOTE: On windows 8 and above trying to go fullscreen on some systems when using ddraw you may get a black screen,
a batch file (RUNME_SAFE.cmd) is included for convenience.
Some letterboxed modes don't display properly and they might even crash on ddraw.
With old graphic drivers on win9x d3d might crash, update your drivers or set 'vid_forceddraw' to true.

The source code can be downloaded from https://github.com/drfrag666/gzdoom.

Copyright © 1993-1996 id Software, 1998-2016 Randi Heit, 2002-2017 Christoph Oelckers, et al.
This version by drfrag from zdoom.org, blue-green-frog from vogons.org, dondiego and hail-to-the-ryzen.
Note that blue-green-frog and hail-to-the-ryzen might be the same person, same for drfrag and dondiego.

More stuff from drfrag:
ZDoom32 2.8.5b, a fork of truecolor ZDoom by dpJudas and Rachael and ZDoom.
https://github.com/drfrag666/gzdoom/releases
ZDoom CLASSIC 2.1.4a, a fork of ZDoom 2.1.4 for Windows 9x and pentium machines.
https://github.com/drfrag666/gzdoom/releases
Romero's Heresy II, an universal ZDoom mod to play Heretic levels with Doom and Heretic modified weapons and monsters.
http://www.moddb.com/mods/romeros-heresy-ii
Romero's Heresy 0.15, a conversion of all the Heretic levels to Doom II.
http://www.moddb.com/mods/romeros-heresy
My Brutal Doom v20c unofficial patch.
https://www.moddb.com/mods/brutal-doom/ ... cy-edition

BONUS: ZDoom CLASSIC.

https://github.com/drfrag666/gzdoom/releases

Released ZDoom Classic 2.1.4a (GL 1.0.17a) JAN 26 2019.

https://github.com/drfrag666/gzdoom/rel ... .4a_GL.zip

------------------------------------------------------------------
ZDOOM CLASSIC 2.1.4a (GL 1.0.17a) R2.2 MAR 20 2018
------------------------------------------------------------------

ZDoom CLASSIC 2.1.4a is a fork of ZDoom 2.1.4 (https://github.com/rheit/zdoom) for Windows 9x and pentium machines.

Changes/features since 2.1.4a GL R2.1:
- Adjusted scaled status bar for 4x4 low detail mode.
- Fixed savegame comment size for the 640x400 resolution.
- Added light definition for megasphere.
- Added Deejay's par times for Thy Flesh Consumed.
- Added support for older versions of DeHackEd patches.
- A few more official fixes.
- Changed savegame list order, now they are sorted by slot number instead of alphabetically.

Changes/features since 2.1.4a GL:
- Added new 3x2 and 4x4 low detail modes.
- Added GL compatibility mode option to the video menu.
- Fixed crash starting the GL renderer on cards without 2d 32 bit support.
- Increased size of the savegame comment area.
- Added Windows 8 detection.
- Fixed crash with truecolor PNGs in GL mode (but they are not supported there).

Changes/features since 2.1.4a CL R2:
- Included old OpenGL renderer from GZDoom 1.0.17 with later fixes (off by default).
- Added Skulltag's HQ resize options and texture compression.
- Added sprite billboard options from GZDoom 1.0.31.
- Autoloading of lights.wad.
- Added early Direct3D renderer and a display menu option to switch between d3d and ddraw.
- More modern default keyboard layout.
- Command versions of the original Doom cheats.
- Added buddha cheat.
- Render cull options (sprite and wall distance) to increase performance.
- More ZDoom patches (mostly up to date with ZDoom 2.1.5).
- Now compiled for pentium architecture (but i guess performance on 486s will not be affected).

Changes/features since 2.1.4a CL:
- Added video menu options to change fullscreen display bits for compatibility and disable widescreen aspect
ratio correction.
- Some more official fixes.

Changes/features since 2.1.4:
- Includes some later fixes.
- Compiled for 486 architecture.
- Added a new quad horizontally and double vertically mode from ZDoom LE.
- Added pixel doubled and quadrupled lowres directdraw modes from ZDoom 2.3 for more recent Windows versions.
- Engine defaults changed for 486 machines.
- Added some missing video settings to the display options menu.
- To set the default video mode on slow machines sometimes you need to press enter twice.

Minimum estimated system requirements are: 486DX4-100, 16 mb of ram, 1 mb svga card and windows 95.
Tested on a Pentium 90 with 32 mb of ram and a trident 1 mb graphics card on win95c, i get 38 fps @320x200.
This is intended for vanilla levels and old mods from 2006.

For modern windows i recommend CoolSoft VirtualMIDISynth with the following soundfonts: Roland SC-55,
Yamaha DX50XG and AWE64 Gold from https://www.vogons.org/viewtopic.php?f=9&t=45600.
A good alternative is the Yamaha S-YXG50 Portable VSTi software synth at http://veg.by/en/projects/syxg50/.

NOTE: On windows 8 and above trying to go fullscreen on some systems when using ddraw you may get a black screen,
a batch file (RUNME_WIN8_1ST.cmd) is included for convenience.
A DirectDraw to OpenGL wrapper such as DXGL for GL 3 cards should fix the problem, or just use d3d.

The source code can be downloaded from https://github.com/drfrag666/gzdoom.

Copyright © 1993-1996 id Software, 1998-2016 Randi Heit, 2002-2017 Christoph Oelckers, et al.
This version by drfrag from zdoom.org and dondiego from vogons.org.
Note that drfrag and dondiego might be the same person.

More stuff from drfrag:
ZDoom32 2.8.5b, a fork of truecolor ZDoom by dpJudas and Rachael and ZDoom.
https://github.com/drfrag666/gzdoom/releases
ZDoom LE 2.8.3a, a fork of the ZDoom 2.8.1 maintenance branch for Windows 9x and old machines.
https://github.com/drfrag666/gzdoom/releases
Romero's Heresy II, an universal ZDoom mod to play Heretic levels with Doom and Heretic modified weapons and monsters.
http://www.moddb.com/mods/romeros-heresy-ii
Romero's Heresy 0.15, a conversion of all the Heretic levels to Doom II.
http://www.moddb.com/mods/romeros-heresy
My Brutal Doom v20c unofficial patch.
https://www.moddb.com/mods/brutal-doom/ ... cy-edition

Alternative LE release without the GL renderer for Windows95:
https://github.com/drfrag666/ZDoom-LE/releases

ZDoom CL release without the GL renderer:
https://github.com/drfrag666/ZDoom-CL/releases

Link to the ZDoom32 thread:
viewtopic.php?f=44&t=57087&p=1013766#p1013766

Old original post follows...

Some food for thought:
After adding the low detail modes there was a crash on certain maps with tall skies, i think this was due to a race condition on small maps such as Heretic E1M1 so R_InitSkyMap() was being called too late.
The quad mode didn't work properly (only showed one third of the screen) when done "the right way", picking every one out of four pixels from the framebuffer (creating a 80*100 virtual screen) and copying it four times, so i had to create another 160*100 virtual screen like in the double mode and then travel it increasing the x by two units at a time to pick half of the pixels. I don't think it matters.
This apparently runs well, i've tested with original Doom 2 and that damned Heresy project (all Heretic levels in Doom 2) plus Brutal Doom 20 but needs more testing.

[Graf Zahl]

- No direct3d nor xinput joystick support, only classic directdraw mode.

... and it seems to start up in fullscreen mode. This is a recipe for disaster on any modern Windows and can easily make the entire system become unresponsive if the low end video mode you use as default cannot be set and forcing the user to do a hard reset.

The reason the Direct3D backend was added were the massive problems DDraw had been causing when being set to fullscreen.
When running in a window it looks stable, but trying to start in fullscreen on my system - kaboom!

[Rachael]

All I can say is - if this'll cut the mustard for people who want legacy support, more power to them. Fullscreen DirectDraw and all.

I've always given my full support to someone who wanted to maintain a legacy fork. Starting in Windowed mode and making Fullscreen optional is definitely a good idea, though.

Otherwise, I doubt it's really going to get better than this for the Windows 9x community.

[Graf Zahl]

This is certainly fine for the intended target. But starting in fullscreen by default with an ancient, deprecated backend is absolutely not advisable as it tends to do bad things to modern computers. DDraw works fine when being used in windowed mode, but ZDoom's DDraw backend is a particularly nasty piece of code that used some elaborate hacks to get a 'performant' surface that is bound to cause problems with systems not made for these 15+ year old hacks.

In any case, that lock-up I got made me rethink whether the DDraw backend should be dumped from the current code base. For today's computers it is worthless and all old ones now have an alternative to switch to - I'd guess most will have performance issues with the modernized-for-multithreading code base anyway.

[dpJudas]

The DDraw backend doesn't really serve much of a purpose with XP as the minimum target. That OS supports D3D9 after all. On the subject, I got an experimental D3D11 target on a branch called d3d11target.

[Graf Zahl]

I've seen it. Does it have any genuine advantage? As long as XP is on the table it probably serves little use, but it may come in handy once XP gets dropped.

As for DDraw, I toyed around a bit more with ZDoom LE and my personal feeling is that this cannot be used fullscreen on my Windows 8.1 system without causing some stability issues - most likely related to using a paletted display mode. Under these circumstances I'd prefer to toss out that code from GZDoom. The D3D9 backend supports cards down to Shader Model 1.4, which translates to my computer from 2003. The only concern may some leftover Intel integrated chipsets from old times. Their graphics deceleration has been notorious. But I guess even those fare better with D3D than with DDraw.

[dpJudas]

I've been wanting to detach the resolution of the game from the size of the window, without stretching it like old ZDoom did. The purpose is to run 320x200 letterboxed for retro feel, and to allow a 4K monitor like mine to render only at half resolution for better performance (kind of like that old r_detail thing). Initially I tried to add this support to the D3D9 target, but its legacy support is so extensive that I could not do it without breaking things.

The D3D11 target is meant to be a "legacy free" target that supports better viewport handling, but still using the old shaders from the D3D9 target. By legacy free I mean that the target assumes the hardware supports basic shaders and 24/32 bit render targets. When the day comes to drop XP support, we can check if anyone with old computer has trouble running with the new target, and if not then phase out the D3D9 target as well. Otherwise just keep D3D9 as fallback in the same way DDraw was used.

This all assumes I finish the work there before getting bored, of course. Right now the D3D11 target has less features than the D3D9 target.

[Graf Zahl]

By legacy free I mean that the target assumes the hardware supports basic shaders and 24/32 bit render targets.

... which really should be everything these days. Those ancient Pre-GL2 cards that made the legacy support necessary are long gone, and those Intels probably work better on D3D than OpenGL.

But what I do not understand is why the code had to become so convoluted. It's not the first part in ZDoom suffering from that - in fact the entire video backend is one fucking ugly mess of bad design. Why all the classes if everything was written for a singular purpose so that even for GZDoom I had to employ some ugly hackery to make it work with what I got?
Until this day I do not understand why the base canvas class implemented the software renderer itself instead of serving as an abstract template.

[dpJudas]

If I'm to guess, I think part of the reason was that the backend was never properly moved into fully designed abstractions. Instead its a mixture of C with globals and a few half-finished C++ abstractions. It didn't exactly help that the whole thing happened as computers transitioned from palette resolutions to true color. I think any changes always came with a specific feature in mind (i.e. port to Linux, port to Direct3D 9, port to DirectInput, etc.) and as a result nothing ever got fully removed or refactored.

You could probably delete half of the code there today. The problem is it is extremely hard to know what of the code is just leftovers that are dormant, and which are genuinely supporting old hardware. For example, for the DirectDraw target I'm pretty sure the code allowing the canvas/surface to use video memory is never ever used. It might have been in the 90's, but once Randi added blending it was most likely disabled, but kept in just in case we might need it again.

[Graf Zahl]

I think any changes always came with a specific feature in mind (i.e. port to Linux, port to Direct3D 9, port to DirectInput, etc.) and as a result nothing ever got fully removed or refactored.

Welcome to the story of ZDoom! Yes, that's pretty much of things went in the beginning.
You haven't seen some of the beautiful code that had accumulated in the early years and what I had to refactor over the years to make the code flexible enough to get working.
The biggest clusterfuck outside the renderer was the menu - it was such a mess that for years nobody dared to touch it. With that code, when you wanted to add a new menu entry you had to modify 5 different places in the code. When I finally had enough it took me over a month to redo it in a sane fashion, and that involved throwing away nearly everything aside from some data management backend stuff.

You could probably delete half of the code there today. The problem is it is extremely hard to know what of the code is just leftovers that are dormant, and which are genuinely supporting old hardware. For example, for the DirectDraw target I'm pretty sure the code allowing the canvas/surface to use video memory is never ever used. It might have been in the 90's, but once Randi added blending it was most likely disabled, but kept in just in case we might need it again.

Yeah, something like that.

[drfrag]

Thanks for your feedback guys.
Fist, a win98 and pentium ii target would have been fine but official 2.8.1 already supported that, we went all the way back to win95 and pentium. Actually compiling with -O3 and -mtune=i586 gives a 40% performance increase on pentiums and i hope this won't cause problems on modern processors, seems like there's no performance penalty on my athlon64. The default mtune generic option shedules instructions for most common modern processors.
The other guy from vogons deleted all the direct3d code, i've restored it with #ifdef but i'm not going to mess with CMake and that would break win95 compatibility, anyway i'm not sure if this would compile with the minimal DX9 allegro libraries.

On that crash, well ZDoom always has started in fullscreen mode and i don't think changing the default to 640 would make a difference as ZDoom tries to use the lowest available resolution. Anyway 640x480 would be very slow on some pentiums. On my system (windows 7 32 bit with ati card) 320x200 is not supported so it starts at 320x240. On my intel laptop with windows 7 64 bit starts at 320x200. On both systems this seems to run well. Old ZDoom versions have serious problems even on windows 7, they start @640 since they don't detect low res modes.
On windows 8 onwards directdraw emulation is broken, low color depth modes are also emulated but i don't think that's the problem. I've tested on my windows 8.1 32 bit machine with another ati card and apparently runs well but only at 30 fps, starts at 320x240 and changing video mode is very slow. With rendering interpolation enabled it runs like shit.
@Graf Zahl: I guess your system lists a resolution as available when really it's not, so does it run fullscreen in the end? Which graphics card? Is 320x200 listed? Does 320x240 work?

Anyway starting windowed would't solve anything since as soon as the user would try to go fullscreen it would crash anyway, on my windows 7 system ZDoom in a window looks blurry and it's very slow, people will want to play fullscreen anyway.
So i guess this version is not adequate for windows 8 but that's not really a problem, we need to make clear then that windows 8 and up are unsupported and not recommended for this version. Up to XP this seems to run well and i hope that it won't crash on windows 7.

[Graf Zahl]

@Graf Zahl: I guess your system lists a resolution as available when really it's not, so does it run fullscreen in the end? Which graphics card? Is 320x200 listed? Does 320x240 work?

When I try to start ZDoom-LE in fullscreen with standard settings the screen remains black and it becomes very hard to Ctrl-Alt-Del out of it.

So i guess this version is not adequate for windows 8 but that's not really a problem, we need to make clear then that windows 8 and up are unsupported and not recommended for this version. Up to XP this seems to run well and i hope that it won't crash on windows 7.

That pretty much sums it up. DirectDraw in general is a huge problem on Windows 8. I still have all old ZDoom versions on my HD but set them to start up windowed so that I do not run into display problems, the old pre-D3D9 ones also exhibit instabilities when used fullscreen.

[Rachael]

@drfrag: 320x200 is only available on Intel cards from what I've noticed. nVidia and ATI drivers do not list it by default.

[Graf Zahl]

Most modern drivers do not even support 320x200 anymore. It's not only not listed - it's impossible to set Windows to such low resolutions.

[drfrag]

I know but ZDoom will try to set the lowest available resolution, i guess this will be in most cases 640x480 or at least for nvidia cards.