ZDoom

Notice: This might be the last vintage version.

Please note that the survey is currently closed. GZDoom 3.8.0 does not include the survey code that 3.5.0 did.

Download (Vintage, OpenGL 2.0)

• Windows 64-bit
• Windows 32-bit
• mac OS
• Linux 64-bit
• Linux 32-bit

• Source

Highlights

• A few localization enhancements.
• add 'cl_blockcheats' - useful for people who use debugging keys, allows a user to consciously turn off cheats without affecting the server
• Punctuated the input strings in UpperCamelCase format, improving its appearance in the menu for upper/lowercase capable fonts
• 'wait' console commands no longer execute inside the level, and can run during intermissions and outside the game
• moved controls to submenus in "Customize Controls" menu
• Implement page string names for dialog lumps
• did a bit of cleanup on the option menus by regrouping some settings, especially splitting out of the Hardware Rendering Options menu into submenus.
• fixed inverted logic for displaying the generic log in Strife.

ZScript

• scriptified P_CalcHeight. This was the only code using the ViewBob member variable. This also moves the range check for this variable to its application, because a badly behaved mod can just as easily change it at run time instead of just setting an absurdly large value in the class definition.
• scriptified APlayerPawn's DamageFade handling.
• scriptified A_SkullPop and ObtainInventory. These were the last relevant items to access PlayerPawn.InvFirst.
• scriptified useflechette CCMD's item finding code.
• scriptified the remaining PlayerPawn methods.
• exported all native components of APlayerPawn.
• Added Z + camera roll relativity for A_QuakeEx's QF_RELATIVE flag.
• Added inflictor, source and flag parameters to GetModifiedDamage on actors and ModifyDamage on inventory. The flags are used by DamageMobj so modders can determine radius damage, for example, by checking for DMG_EXPLOSION.
• removed extraneous parameter in SpawnPlayerMissile call in A_FireProjectile. The native variant has a MissileActor out parameter in this place, but in ZScript that's a secondary return value.
• Add LookScale variable on weapon This variable allows a weapon to set a custom look sensitivity multiplier without fiddling with FOVScale / DesiredFOV hacks.

Details/missing stuff

• Due to the old texture manager titles cannot be created from texts, no extended console font, no support for vga/generic fonts.
• No extra lenguages with the new csv format (russian is partially working with missing console chars).
• No new player menu.
• No generic HUD.

It's up but the post is a bit old. Report bugs here: viewforum.php?f=178

Well. That's all in Vintage

Mac and Linux builds uploaded.

Thanks a bunch , drfrag , I was very much waiting for this !

Just a simple question , is there an easy way to c/p my settings from another version/build like controller/sound configs etc ?

The user.ini file in the ZDoom dir seems to be storing those , but since it also includes the current build/fork name I'm not sure if moving that file will make another build to read and employ that settings...

ClessxAlghazanth wrote:Thanks a bunch , drfrag , I was very much waiting for this !

Just a simple question , is there an easy way to c/p my settings from another version/build like controller/sound configs etc ?

The user.ini file in the ZDoom dir seems to be storing those , but since it also includes the current build/fork name I'm not sure if moving that file will make another build to read and employ that settings...

The ini file will be updated with the new version and build number. Just be aware that some cvars and settings may have become obsolete and moved into an unknown group where they won't get used.

@drfrag:
I have missed that survey, so I guess I am partially guilty for the possible demise of GZDoom Vintage, but let me say that GZDoom Vintage is the ONLY way to have a working version of GZDoom on some hugely popular systems like the Raspberry Pi, so.... Would you please consider future updates?
Even if you only update Vintage edition once in a year or so, when a very stable GZDoom is released, it would make an up-to-date solution for GZDoom on this kind of hardware.

vanfanel wrote:some hugely popular systems like the Raspberry Pi, so...

I doubt that these are"hugely popular". Just because you use such a thing doesn't change the fact that it is very much a niche product with an extremely small user base.
Updating the Vintage build will become more difficult over time because this hardware lacks everything that makes modern graphics cards tick, meaning that the render backend is completely incompatible. However, since this part will change, it will inevitably mean that more and more features cannot be backported.

Graf Zahl wrote: I doubt that these are"hugely popular". Just because you use such a thing doesn't change the fact that it is very much a niche product with an extremely small user base.
Updating the Vintage build will become more difficult over time because this hardware lacks everything that makes modern graphics cards tick, meaning that the render backend is completely incompatible. However, since this part will change, it will inevitably mean that more and more features cannot be backported.

Well, maybe a software-renderer only version could be maintained then? Software rendering at 320x200, scaled to fullscreen via a very simple GL texture, works rock-solid 60FPS on the Pi. No need to backport anything hardware dependant if only the software renderer is maintained on the Legacy branch. What do you think?

vanfanel wrote: Well, maybe a software-renderer only version could be maintained then? Software rendering at 320x200, scaled to fullscreen via a very simple GL texture, works rock-solid 60FPS on the Pi. No need to backport anything hardware dependant if only the software renderer is maintained on the Legacy branch. What do you think?

The most likely answer is: No. Mostly because the software-renderer isn't the issue, it's the backend that only supports OpenGL 2.0 and Direct3D, which many Raspberry Pis don't support.

If you still want to run GZDoom on the Pi, there's the following options:
RaspZDoom
LZDoom
ZDoom LE (Best GL renderer of the whole bunch, fastest and most compatible)
Zandronum
Odamex (It's based on a very old ZDoom version, but works better on the Pi than most others and has excellent netcode)

@TDRR: Is RaspZDoom still alive? Seems to be a great alternative (if alive)

Then the software renderer would need to be run on a GL 2.x backend but now it requires 3.3 as well. What you're asking here for is a new ZDoom but only on GL without a hardware renderer. I'd rather create a D3D11 backend but i can't do it, and i don't think it would be very popular. But would that really be even doable after somewhat merging both renderers? I doubt it.
Edit: actually a software renderer based on GL 2 is not a bad idea at all, D3D11 what for? I already thought about it but i forgot. You'd "just" need to detach the hardware renderer and bring back the legacy backend for software, and ignore the ton of unsupported features. And port the render hacks to softpoly. Easier said than done. Seems Erick194 even made shaders work on GL 2. However the software renderer has problems and it's suffering from lack of maintenance (some areas of the code are a bit obscure it seems).

RaspZDoom is entirely based on the vintage build and right now they're pretty much the same. You could use LZDoom since it has a "pure" software renderer and should run well on the Pi. It's here: https://github.com/drfrag666/gzdoom/tree/g3.3mgw

About the vintage build itself i'm going to release a 3.8.1 update very soon and then a new LZDoom version. I don't know what will happen, but the last release it's already hacky with missing stuff and i think we're pushing it too far. Right now i'm in deep shit and if i manage to get out of this really bad situation who knows, i want to continue with LZDoom and after all the code for both is very similar (right now everything goes thru legacy first).

drfrag wrote: About the vintage build itself i'm going to release a 3.8.1 update very soon and then a new LZDoom version. I don't know what will happen, but the last release it's already hacky with missing stuff and i think we're pushing it too far. Right now i'm in deep shit and if i manage to get out of this really bad situation who knows, i want to continue with LZDoom and after all the code for both is very similar (right now everything goes thru legacy first).

At least in my case, i'm perfectly fine if this turns into the last major LZDoom version, so long as there are bugfix releases after it.
Don't strain yourself too much with it, take your time. No one is going to stop playing it just because it's taking long

Post-mortem download stats for 3.8.0v:

That's not really much for 6 weeks.
Past vintage builds had higher download numbers.