ZDoom32

Schedules and announcements about program releases.

ZDoom32

Postby dondiego » 2017-7-05 @ 08:56

I've just released a new project, ZDoom32.

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

I've released ZDoom32 2.8.5 (GL 1.9.2) JUL 15 2018 but i don't feel like writing a changelog anymore. It's an important update with several bugfixes (one major old ZDoom bug) and more stuff. See last page for some details.

---------------------------------------
ZDoom32 2.8.4a (GL 1.9.1b) APR 16 2018
---------------------------------------

ZDoom32 is a fork of truecolor ZDoom by dpJudas and Rachael and ZDoom 2.9pre (https://github.com/rheit/zdoom).
It's a merge of dpJudas old truecolor branch (SEP 08 2016) and ZDoom master as of DEC 03 2016.
Later merged with the GZDoom g1.x branch (APR 24 2016).

Changes/features since 2.8.4:
- Fixed wrong alpha blending, this broke 3D floors in truecolor
- Several bugfixes.
- Restored XInput support.

Changes/features since 2.8.3:
- Fixed generalized BOOM crushers not crushing.
- Fixed wrong weapon vertical position.
- Fixed security issues (execution of unsafe commands and ACS stack checking).
- Lots of official bugfixes.
- More compatibility fixes.

Changes/features since 2.8.2b:
- Fixed crashes on some old CPUs in software due to a broken asm routine.
- Fixed Doom turbo stairs not working anymore.
- Changed savegame list order, now they are sorted by slot number instead of alphabetically.
- Added free space margin aka safe frame for automap.
- Several bugfixes from GZDoom.

Changes/features since 2.8.2a:
- Fixed savegame bug on maps with dynamic lights.
- Don't hide the console when killing specific monster classes.
- Several minor bugfixes.

Changes/features since 2.8.2 GL:
- Added truecolor capped sky drawers.
- 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 voxels for the SSE2 executable (BD v21).
- Fixed crash with textures larger than those supported by the hardware in D3D and OGL (BD v21).
- Fixed crash with capped sky mode and very wide skies (Castlevania).
- Added four text colors: ice, fire, sapphire, teal.

Changes/features since 2.8.2:
- Included old OpenGL renderer from GZDoom 1.9.1 (off by default). Supports shaders on GL2 hardware.
- Added xBRZ to the GL renderer.
- Autoloading of brightmaps.pk3 and lights.pk3.
- Added MF7_NOINFIGHTSPECIES flag.
- added new Stairs_BuildUpDoomCrush special from Eternity.
- Switched to FMOD Ex 4.36 for sound.
- Fixed wrong weapon scale in savegame pic for low detail modes.
- Some recent GZDoom bug fixes.

Changes/features since 2.8.1:
- Old C++ truecolor renderer by dpJudas.
- Mostly up to date with the last ZDoom SVN and includes some later fixes and features (from QZDoom).
- Compiled with Pentium II architecture optimizations.
- Still has the assembly routines and SSE2 is not a requirement.
- Two executables, the one using SSE2 instructions requires a Pentium 4 or Pentium M CPU.
- Sprite and wall distance culling to increase performance.
- Low detail modes have been restored (from ZDoom LE) but are disabled for truecolor.
- Added video menu options to switch between d3d and ddraw and set ddraw display bits (ZDoom LE).
- Startup console fixed for Win98 (ZDoom LE) with a slightly different look.
- More modern default keyboard layout.
- Command versions of the original Doom cheats.
- Uses FmodEx 4.28 for sound.(*)
- Capped skies have been disabled for truecolor since there are no drawers. No support for truecolor textures either.
- Multithreading is disabled by default.
- No xinput joystick support.

Minimum estimated system requirements are: Pentium II 233, 32 mb of ram, 1 mb svga card and Windows 98.
For OpenGL mode a graphics card with GL 2.0 support is required.

(*) For modern windows i recommend CoolSoft VirtualMIDISynth with the following soundfonts: Roland SC-55, Yamaha DX50XG and AWE64 Gold from 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.
3D floors are not properly rendered in truecolor (missing textures).

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

Compiles with CMake 2.8.12, CodeBlocks 16.01 (TDM-GCC 4.9.2) and NASM 2.10.09. You'll need the following libraries:
dx9mgw.zip, fmodapi43623win-installer.exe and fluidsynth.7z (optional).
Run CMake to generate a CodeBlocks makefile, you can link directly against the dlls but not for DX (dinput).

Copyright © 1993-1996 id Software, 1998-2016 Randi Heit, 2002-2017 Christoph Oelckers, et al.
Copyright © 2016-2017 Magnus Norddahl and Rachael Alexanderson.
Copyright © 2014-2017 Alexey Lysiuk.

This version maintained by drfrag from zdoom.org. Includes patches by Blzut3 and hail-to-the-ryzen.

More stuff from drfrag:
ZDoom LE 2.8.2a, a fork of the ZDoom 2.8.1 maintenance branch for Windows 9x and old machines.
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.
http://www.moddb.com/mods/brutal-doom/a ... cial-patch

More info here:
https://forum.zdoom.org/viewtopic.php?f=44&t=57087
Last edited by dondiego on 2018-7-19 @ 18:30, edited 16 times in total.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby koverhbarc » 2017-7-05 @ 12:55

Seems OK on quick checking. I'll note that the readme seems to imply that truecolor is available _only_ with SSE2, which is not true. I'd prefer the sprite-culling option give actual distances and 'OFF' for no culling (normal behavior).

Presumably this should be merged with LE next release - is there any reason not to have both OpenAL and FMod available in the same executable? I had no trouble with this.
koverhbarc
Member
 
Posts: 119
Joined: 2017-6-05 @ 02:02

Re: ZDoom32

Postby dondiego » 2017-7-06 @ 18:24

No, SSE2 instructions are used for truecolor, i said they are not a requirement right above.
On sprite culling actual distances mean nothing to players and infinite is actually a very long distance.
Original ZDoom used just FMod and OpenAL was needed for win95 compatibility.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby koverhbarc » 2017-7-06 @ 22:21

You didn't say that SSE2 is not a requirement _for truecolor_; I inferred that from what your wrote and my previous knowledge of the truecolor renderer. I have seen myself that it is available in the non-SSE2 version; it seemed to increase rendering time by about 5x in the non-SSE2 and 3x in the SSE2 version - I presume it is not as optimised as the 8-bit renderer, as it should always be less than 4x (the ratio of memory usage), but I am not asking you to fix that. It was enough work getting in it at all without help!

For the sprite culling distances, they certainly would be meaningful to me, and I can't see how 'close', 'medium', 'far', and 'infinite' can be better. Without their display, I will have to search the source code to find out, which I can't right now.

I know why OpenAL was added - the question is why remove it? Including both sets of sound code hardly affects size or performance, and causes no trouble that I know of. Why not give users the choice?
koverhbarc
Member
 
Posts: 119
Joined: 2017-6-05 @ 02:02

Re: ZDoom32

Postby dondiego » 2017-7-07 @ 10:08

Well, people know SSE2 is required for truecolor in QZDoom. I could change the text file anyway.
There's nothing to fix, it's old dpJudas c++ 32 bit renderer and it's already fast even without SSE2 compared to the new LLVM one. On my athlon 64 it's actually as fast as the latter (non SSE2 vs SSE2) and even faster with SSE2 although there's not as much of a difference as in QZDoom.

Just check menudef.txt, or even better install git and tortoisegit then clone the repo and go to that commit. You can have a look on github but it's very limited. The default is 5000.0 in doom units.

OpenAL is not needed and has not been removed, ZDoom never included OpenAL. The code is there of course but it's a GZDoom thing. Also that old version has limitations and i would need to update the code to a very recent version, positional sound was not working (some sounds were even played at full volume) and stereo sounds had to be converted to mono on the fly, that has been fixed recently. Also there were more powerful bass and higher volume in fmod then.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby koverhbarc » 2017-7-07 @ 22:38

OK, the culling ranges are 2000, 3500, and 5000. Not as different as I expected, and it seems doubtful that 2000 would be considered 'close'. Powers of 2 are nice numbers - how about 2048 (normal hitscan range exactly), 4096, 8192, and 'off'?

As for OpenAL I was only asking about it because I'd like to see this merged with LE at some point. What version of Windows is now required? If you want it to be run/tested on retro machines I think you need to support at least 98.
koverhbarc
Member
 
Posts: 119
Joined: 2017-6-05 @ 02:02

Re: ZDoom32

Postby dondiego » 2017-7-10 @ 11:18

Multi layer skies are fixed now so expect a proper release soon. I guess a pentium ii with 32 mb of ram and win98 will be required.

I've reviewed sprite culling and changed infinite to maximum (8000) since that's the render limit. In QZDoom there are no options only 5000 which is the default. Why powers of two? Did you actually tried those distances in game (from the console)? I did.

Of course it runs on 98 however i've tried to run the truecolor renderer on a pentium 3 and apparently direct3d requires at least win2k since it crashes on win98. I removed my voodoo 3 and put a geforce fx 5500 in with the forceware 56.64, directx 9.0c is required BTW. Now the 3dfx card is back.
The official 2.8.1 crashes as well. I'm considering disabling direct3d support for win98 and ME. I wonder if anyone has ever managed to run ZDoom on 98 with direct3d.

This cannot be merged with LE since it's a different codebase, the only things you'd be missing is win95 and pentium support.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby koverhbarc » 2017-7-14 @ 02:19

I understand but that's unfortunate because of the limitation. No, this Direct3D can't run on Windows 98 (or ME, I think), so if it is required for truecolor one will need XP and a compatible graphics card. By the way, the FX card you mentioned supports only 9.0a (per Wikipedia), not 9.0c, so maybe that's the actual minimum specification. It makes me wonder exactly what systems are going to benefit from this release.

As for the sprite cull distance it shouldn't really be needed to explain why powers of 2 are preferred in computer programs. It the hitscan distance is 2048 then the visibility distance should also be at least 2048, as you should at least see all that can shoot at you. 2048, 4096, and 8192 should cover all configurations that are used, I would guess. What is that limit of 8000? I didn't find that in the code. [Sorry I haven't had much time recently.]
koverhbarc
Member
 
Posts: 119
Joined: 2017-6-05 @ 02:02

Re: ZDoom32

Postby dondiego » 2017-7-24 @ 08:41

May be it's just a poor driver problem. I know the hardware requirement is a card supporting 1.4 pixel shaders and for the software you need DX9 with the initial release not being enough.
I've ported wall (line) culling to ZDoom32, dpJudas implemented it recently into QZDoom. It works really well with a big performance boost, also i added sliders for both culling options to the menu and a switch to disable them.
I've ported some renderer bugfixes as well, i believe those bugs were introduced with the floatification. And some extra stuff. So i'm aiming for an impending release.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2017-7-26 @ 07:51

I've just released a final (non pre-release) version. See first post.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby Osprey » 2017-8-15 @ 21:33

When I select VirtualMIDISynth as the MIDI device in ZDoom32, it uses Microsoft GS Synth, not VirtualMIDISynth. I just tested in a recent version of GZDoom and that correctly uses VirtualMIDISynth when I select it. It seems like a bug in ZDoom32.
Osprey
Member
 
Posts: 257
Joined: 2017-7-27 @ 21:32

Re: ZDoom32

Postby dondiego » 2017-8-16 @ 12:38

I've just checked and runs fine. You need to select virtualmidisynth in the menu and it must be properly configured of course. It's just another midi device for ZDoom.
BTW i updated the release a few days ago to fix a couple of rare savegame bugs.

Some news: the next release will include an OpenGL renderer (1.9.1a) with a menu option to enable it but software will still be the default. I also fixed the GL renderer in ZDoom LE (1.8.4a), that one will require a GL 1.2 card. I will drop win95 support and switch to fmodex, GZDoom doesn't run on 95 anyway.
There will be a last release for 95 though, i also have ported the render culling options to LE.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby Osprey » 2017-8-16 @ 14:25

Ok, I feel dumb. The issue is that the default music volume (0.50) was too low for me to distinguish between the two. I cranked it up to 1.00, like I have it in GZDoom, and the differences are more noticeable. Sorry to bother you with a non-issue.
Osprey
Member
 
Posts: 257
Joined: 2017-7-27 @ 21:32

Re: ZDoom32

Postby dondiego » 2017-9-08 @ 22:38

What's in my gzdoom repo (https://github.com/drfrag666/gzdoom, copied from README.md):

Some ZDoom based legacy ports with lower system requirements for Windows 9x or later and older hardware.
Some branches are discontinued from now on (SEP 04 2017).

- gzdoom32 branch:
ZDoom32 is a fork of truecolor ZDoom by dpJudas and Rachael and a later ZDoom (https://github.com/rheit/zdoom).
It's a merge of dpJudas old truecolor branch (SEP 08 2016) and ZDoom master as of DEC 03 2016.
Now merged with the GZDoom g1.x branch (APR 24 2016).

- glzdoom32 branch:
A merge of ZDoom32 with a later GZDoom master (roughly 2.2) from NOV 17 2016 with later fixes. Discontinued.

- zdoom32 branch:
Old ZDoom32 2.8.2 branch without the GL renderer. Discontinued.

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

- zdoomle branch:
Old ZDoom LE 2.8.1a branch with OpenAL for win95 (released from the ZDOOM-LE repo). Discontinued.

- zdoomcl branch
ZDoom CLASSIC 2.1.4a is a fork of ZDoom 2.1.4 for Windows 9x and pentium machines.
Now merged with GZDoom 1.0.17 with later fixes and additions.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2017-9-08 @ 22:38

I've released a new ZDoom32 version with the OpenGL renderer from GZDoom 1.9.1 with later fixes and additions, has shaders for GL 2.0 cards. I've also switched to FMOD Ex 4.36 for sound.
I've also updated ZDoom LE for even older hardware. See first post for download and detailed info.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2017-11-08 @ 19:35

I've released a new version. This release mainly adds the truecolor capped sky drawers and a couple of new low detail modes and fixes some crashes (large textures on old cards and SSE2 executable with voxels). See first post.
I've changed version numbering as well (still it's very conservative). I've updated ZDoom LE and Classic as well.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2017-11-20 @ 12:20

Well, this is embarrassing. I've just released a new version since i've found a nasty bug with broken savegames on maps with dynamic lights (i've flagged it as critical). Somehow i missed a bugfix by Graf after porting his GZDoom adjustments for the new savegame code, i usually don't read the entire description for all commits. The problem was already in the previous release after the merge with the old GZDoom but it's not a bad merge. I know i said the last one was a solid release but hey this time is for real i promise. I know this comes after the gcc crash with voxels for the SSE2 version but it was also unfortunate and that doesn't mean this is not a solid product. Some testing would be welcome.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2018-1-19 @ 18:27

I released another version (2.8.3) on december due to a couple of new critical bugs i found. Everyone is encouraged to upgrade ASAP. If you're interested on what happened i explain it at the project thread @zdoom.org. Also there are plans for a future 2.9.0 release, i'd need help with the broken 3D floors in software truecolor mode BTW.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2018-2-26 @ 19:40

Yesterday i released a new ZDoom32 version (2.8.4) with the security updates and a lot of bugfixes. Grab it from:

https://github.com/drfrag666/gzdoom/releases
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Re: ZDoom32

Postby dondiego » 2018-3-01 @ 19:55

I've reuploaded the release due to the severe performance regression in gcc 4.9.2, the game mostly ran fine but was very slow in extreme cases with a lot of actors. Now it's compiled with gcc 5.1 and still runs on win98.
User avatar
dondiego
Member
 
Posts: 325
Joined: 2013-12-24 @ 12:31
Location: Spain

Next

Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 2 guests