You didn't fork from a zdoom repository to track changes against the tree for future maintenance?

I should have done so but i only wanted to fork the maint branch. I can apply patches but it's a bit tricky. Anyway it's possible to create a branch from this repo on a new one.
Have you tried it by the way?

I don't see much interest in this, however i've released another old ZDoom version for 486 machines.

ZDoom CLASSIC

You're catering to a niche of a niche. Probably would get more response on a Doom specific forum.

Thanks for working this though I'm definetly interested.

very nice that old computers and old operating-systems are still supported 😀
would be nice if 3dfx-glide would be more supported.

DosFreak wrote:

You're catering to a niche of a niche. Probably would get more response on a Doom specific forum.

On a Doom-specific forum these days, the response would be "what the point play gzdoom it work with brutal doom best 4k graphics who clare slow computer!!! upgrade to windows 10 to play doom THREAD CLOSED"

DosFreak wrote:

You're catering to a niche of a niche. Probably would get more response on a Doom specific forum.

I already knew that, actually i've posted it at doomworld and at least they've not locked the thread.
Hope the classic version actually runs well on a 486, it should.

I've just updated the release to fix sky scaling in low detail modes.

I will check it out on my 233mmx , always nice to have stuff like that 😁

Big update, i actually wasn't very happy with the old release. Now direct3d works while maintaining win95 compatibility. I've edited the first post.

I want to comment something on the quad mode algo. At last i think i know how the original double one worked. It copied the first half of the screen onto the second, i got it right after all (copying half of the pixels) but i could also have copied the first quarter onto the second, third and fourth. Performance wise it could have been even worse. It's very difficult to see what was going on there without any commentary.

Do this "brutal-doom" stuff work with this classic release, or is it possible to get a low-end-brutal-doom-fix for a classic pentium(mmx)/pentium2 win9x machine.

The brutal doom v20c patch is only required for new GZDoom versions but has more bugfixes so i recommend it anyway. ZDoom LE of course can run brutal doom 20 but it's barely playable on a pentium ii, it will be surely too slow on a pentium and i guess it will require at least 64 mb of ram. BTW 2.1.4 classic it's much faster on a pentium.
@keropi: i strongly recommend you to upgrade to the new version.

any light-version of brutal-doom for w95/p2 planned?

Of course not but brutalv20c_UP.pk3 already enhances performance since decreases the number of particles for water splashes. I'm planning another completely unrelated mod BTW.

I've just uploaded a new release, i've flagged it as important due to the A_SpawnItem bug of the maint branch i've noticed recently.

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.

https://github.com/drfrag666/ZDoom-LE/releases

I finally found this. More progress - is this the last version you think necessary? I've finally tried it out and had something of an adventure.

First, you do have a binary version available. I either missed it before (most likely) you you just added it. This is what I first tried. I also compiled it myself, using your instructions and some help from the wiki, with several combinations of OpenAL, FMod, and Fluidsynth, trying to see if they'd make a difference in the sound; I could detect none that I was sure of.

The reason I was doing this is that the sound seemed awful; as if there were some strange reverb enabled or my speakers just had a cold (LOL) - I finally examined the sound settings in the menu and found almost the entire difference was caused by the option 'Randomize pitches', which was enabled. Why, I must ask, does this option even exist? Turning it off made it sound right again (in all the versions including your binary), and it performs exactly the same as standard 2.8.1 as it should. This showed me that it does have demo compatibility, as I could timedemo the exact same runs on both.

I note that (barring the sound) this software rendered is a bit faster than the Quake2 software renderer; if interpolation is off this is so even on quite large levels. If I can extrapolate I'd say any computer that can run Quake2 software mode can run ZDoom 2.8.1 at the same resolution quite playably. Unfortunately I don't have any hardware older than my main computer to test, though I know others do - what do you have? I'm worried that even OpenAL may take too many cycles on a Pentium 1.

Adding truecolor support as I have speculated about would be an awful mess; though, if it were done, it would make sense to add it as almost all the target systems will support it - yes, maybe ZDoom should have done it when RGB effects/computations were first added, but it wasn't. With this renderer it would require new versions of functions in many places, including the assembly loops. Further, truecolor isn't even that useful (I can barely notice the improvement) in maps not specifically designed for it, which means everything that runs on ZDoom. So Zpack E2M6, the level I was looking at, doesn't even look right in truecolor! Yes, it's smoother but the colored lighting and fog effects are just too faint; it was clearly made for the ZDoom palette mapping. [Also the bug rendering that level uncompletable occurred only in 2.5.0, of the official releases - I looked back in the forum and saw it was finally marked 'fixed' - and was in the polyobject code, not the scripting code. So that's not a concern now.]

So should I switch to LE from 2.8.1 as my default version for playing? There seems no reason why not if it is as stable.

Andrew Usher

I believe I have found at least one bug.

First (occurs in stock 2.8.1 also), some video modes don't work. While this is no surprise, the way in which it is handled is problematic. ZDoom can just crash, and worse, keep crashing if restarted (because it tries to enter the same mode) unless the user knows the command line options for restoring the resolution to something that does work. The occurs with some of the stranger low resolutions, and is related to one's video driver since it doesn't happen with the standard VGA driver. The actual crash must occur in (or from) I_SetMode or I_CheckResolution , which I can't find in the source. Even if the crash can't be avoided (some other unsupported modes just cause it to switch to windowed, which is better), surely ZDoom should not store this resolution as the default before it's demonstrated to work. I would consider this bug serious, but not too important, since it involves modes few people will use anyway. [Related minor issue: the video modes screen will only display 30 resolutions, with no way to page down to higher ones. Setting the aspect ratio reduces it to less than 30, and does allow selecting the highest ones.]

Secondly (does _not_ occur in 2.8.1), I tried in on another system I have, a laptop running Windows 7, and it simply bluescreens and requires a complete reboot, even with proper setup (specifying a standard iwad and the native monitor resolution on the command line). This doesn't seem to be sound-related as it happens the same with the FMod build and with -nosound. I don't use that system for gaming of course but if this occurs in Win7 (or other) systems that are used for gaming, it is important.

As stated in both threads and the readme i've already released several versions.
Have you tried compiling with both fmod and openal? You should be able to select the audio backend from the sound options menu.
You cannot fix bugs (or add new features) and keep 100% demo compatibility.
About sound it's right the opposite, i see you didn't play Doom when it came out. ZDoom LE tries to resemble the first dos versions up to 1.2 (actually the 1.3 beta) which had random pitched sounds. On later versions they didn't work due to a bug (the spec of the DMX audio library changed) and id didn't bother fixing it. That option has been in ZDoom almost right from the start (came from Boom). Also i've changed the defaults for old machines so you should increase the sound samplerate at least to 22050.

Nothing to do with Quake 2, with Doom you will be cpu limited most of the time due to the game logic, the engine was not ready for maps that complex and with that many things (inneficient algos and data structures).
As i mention in the readme i've tested it on a pentium 90 and performance is more of less acceptable.

I see you've looked at the code and noticed it's not pretty. The 32 bit renderer would be a nice addition but a nightmare to implement. Also dpJudas started his work in the middle of the renderer floatification and that didn't make into the maint branch. I guess you've tried the renderer in QZDoom or GZDoom, even the 8 bit mode is clearly slower due to the asm removal. Also dpJudas fully refactored the renderer with a different modularization.
Finally i restored the low detail modes and i don't know if that could also be a problem.
Actually there were some sort of hicolor and truecolor modes in ZDoom in very early versions using ddraw (up to 1.14 i think) but they were half broken and looked pretty much the same as the 8 bit one (they were also paletted i think and with these i only noticed a difference in the menu).

About Zpack that nodebuilder bug was never fixed, for now there's only a recent workaround.

On those bugs of course i'm not going to support an unnoficial build. If the engine crashes just run RUNME_WIN8_1ST.cmd and try to set video modes until you find which one is causing the crash. BTW are you runnigh the d3d or the ddraw backend? Have you installed the video drivers? Which graphics card? In d3d the mouse cursor is an imp claw and the menus are in 32 bit, if not the palette change very noticeable with the status bar on.
I guess what's happening is that some weird lowres letterboxed mode is being set and those only work well with certain graphic cards. I changed the default to 320x200 for old machines since 640x480 is too slow on pentiums but 320x240 works on most computers. There was a menu option for testing video modes but was removed between 2.0.38 and 2.0.39 becouse apparently users got confused and wasn't needed, not a very clever decision. I looked into it but the video section of the code saw a major refactoring then so i don't know how to restore the testing modes option. BTW there's a race condition when setting the default video mode (due to multithreading) and i don't think it's fixable, on very slow machines (some pentiums) you need to set the video mode twice. Another one appeared after restoring the low detail modes making certain maps crash but i fixed it.

So in the end if things get messed up you can always run the cmd file to start @640 windowed.

As I have stated in this thread, yes, I did compile with both OpenAL and FMod (and each separately). I haven't noticed any difference audibly; the 'random pitch' just sounds awful to me either way. Maybe on a real Soundblaster it wasn't so bad. I didn't know about the history; if so, the option has a right to be in the game, but I'm afraid making it the default will convince many people (as it did me) that there's something wrong with LE. I did indeed play Doom v1.2 when it came out, but I can't remember anything about the sound (it's been over 20 years!).

I wasn't complaining about demo compatibility - I know Doom's demo format makes it impossible to maintain compatibility across most changes without special-case code - I was just observing that this version doesn't seem to have broken compatibility from 2.8.1, which allowed me to time the same demos in both.

As for the video issues, yes, your batch file does fix it. I didn't think of that before because I hadn't looked at it, and your documentation identifies it as an issue only for Windows 8 and later (not 7); clearly, if I can get a bluescreen crash on 7 that's not entirely accurate. Perhaps the batch file should instead be called, for example, SAFEMODE (reminding people of the somewhat related feature of Windows) and suggested any time ZDoom crashes in startup.

The video-mode crashes, I now am convinced, are bugs in Windows and/or my drivers, and not in ZDoom. They're just seen there because ZDoom offers so many strange video modes and allows them all to be selected fullscreen. Neither is the need to reset manually - while it's true that ZDoom (arguably incorrectly) sets a new video mode as default before actually switching to it, reversing that order did not help. So I would say there's nothing to be done except document the behavior.