ZDoom 2.3.0 released

Great news!

Here's to hoping 2.4 has OpenAL support as well. It's close, people!

ooh, fixes, features and fancy complevels for the lazy. I only worry there will be more 'Doom/Boom compatible' levels only tested in ZDoom.

I've got some ZDoom mod playing to catch up on.

Apparently ZDoom now supports Eternity's 3dMidTex. :o

Oh, Graf Zahl updated GZdoom too! Yay!

woot. 3 source port update releases in a week.

Four, if you count GZDoom as well (1.2.0, which is up-to-date with ZDoom 2.3.0).

And that's if you're counting ReMooD.

Oh, why shouldn't it be counted, you ask? No reason. No reason at all.

Damn. I only hope someone ports this version to Mac OS X now....... :(

Nice to see an update to this, only to wait till Skulltag is upgraded to the latest version of ZDoom.

Is anyone else having horrible trouble with their audio crackling now? It sounds like my speakers are broken ... but sound plays fine on any other program; it's just the new ZDoom that does it.

On my system, I hear only a slight crackling, but sound is odd. It's slightly delayed, perhaps a little grave or hollow, and fireball sounds seem to buzz or stutter a bit.

Too bad Randy removed low detail modes. I found them useful (and not for performance issues). I had been thinking about posting about low detail at the ZDoom forums when I heard they were gone from the betas, but didn't get around to it :p

ZDoom updates are a bit of a hassle; I now need to transfer my DECORATE edits to remove all the ugly additive translucency on things. An option to make all things no use translucency would be great (as opposed to eliminating translucency altogether). Also, there is no reason why teleporter and rocket explosions should be hard-coded as translucent. That should be managed fully by DECORATE.

myk said:

Also, there is no reason why teleporter and rocket explosions should be hard-coded as translucent. That should be managed fully by DECORATE.

The teleport fog translucency is defined in DECORATE.
The rocket is a bit of a problem because it still needs some support for old Dehacked opions. But even there you can do it in DECORATE. Just clear the DEHEXPLOSION flag.

Yeah, you're right about the teleport flash, I remembered incorrectly. And thanks for the explosion tidbit.

OK, I might get flamed for this, but I don't care, these are my honest points about this version, running Debian 5:

* Source code comes in an archive bomb. At least atool prevents this from doing damage, it's still really really stupid.
* Compiling it requires a complex maneuver of commands; documented on the wiki but it doesn't make sense why it can't be simple.
* No sound whatsoever (yeah big surprise there, *glares at fmod*). Multiple options available for FMOD, OPL emulation, Timidity, none of them work even when completely restarting the engine.
* Menu graphics are squished (not aspect corrected)... especially odd since the game itself has the correct aspect.
* Mouse sensitivity, at least through the menus, doesn't quite go high enough for my tastes...
* After about five minutes of playing, the CPU use jumps high and it starts feeling like a slideshow. (I'm just playing doom.wad too, it's not a crazy PWAD like nuts that should slow it down)

Here's to hoping the next version addresses these issues!

MikeRS said:
OK, I might get flamed for this, but I don't care, these are my honest points about this version, running Debian 5:

* Source code comes in an archive bomb. At least atool prevents this from doing damage, it's still really really stupid.

Care to explain what's the problem? There's nothing that looks wrong to me with the archive.

* Compiling it requires a complex maneuver of commands; documented on the wiki but it doesn't make sense why it can't be simple.

Again, what's the problem? The fact that some third party libraries need to be installed or is it CMake?

* No sound whatsoever (yeah big surprise there, *glares at fmod*). Multiple options available for FMOD, OPL emulation, Timidity, none of them work even when completely restarting the engine.

Bad sound drivers?

* Menu graphics are squished (not aspect corrected)... especially odd since the game itself has the correct aspect.

Have you ever tried to 'fix' this? You'll never try again. ;) The scaling factors involved here make aspect ratio corrected graphics not look good.

* Mouse sensitivity, at least through the menus, doesn't quite go high enough for my tastes...

Then either your tastes are off or your system. I never ever had to set them beyond either end of the slider.

* After about five minutes of playing, the CPU use jumps high and it starts feeling like a slideshow. (I'm just playing doom.wad too, it's not a crazy PWAD like nuts that should slow it down)

Hard to say when it only happens on systems where it can't be investigated.

Graf Zahl said:
Care to explain what's the problem? There's nothing that looks wrong to me with the archive.

All the files/directories are in the root of the archive. If I extracted through the normal 7zip tool, it would have put everything under the current directory, potentially overwriting files.

Again, what's the problem? The fact that some third party libraries need to be installed or is it CMake?

A little of both. I was expecting to install FMOD beforehand, but CMake itself was an 18MB package to download (!!) and using it was not straight-forward.

Bad sound drivers?

Guess again, my sound works fine for everything else.

Have you ever tried to 'fix' this? You'll never try again. ;) The scaling factors involved here make aspect ratio corrected graphics not look good.

No, I haven't; it is a very minor issue, I'll grant that, but it feels strange.

Then either your tastes are off or your system. I never ever had to set them beyond either end of the slider.

I don't know, but all the way to the right end of the slider was still too slow. Is it possible to configure this manually in the cfg file? (I didn't try myself, I just put up with a slow mouse for my gameplay...)

MikeRS said:

All the files/directories are in the root of the archive. If I extracted through the normal 7zip tool, it would have put everything under the current directory, potentially overwriting files.

Strange that only Linux users have problems with this... It never, ever happened to me that I accidentally unpacked something organized this way in the wrong directory.

A little of both. I was expecting to install FMOD beforehand, but CMake itself was an 18MB package to download (!!) and using it was not straight-forward.

CMake is still loads better than those abomination called autotools and the baggage that comes with it. Maybe not for you as the end user but certainly for me as developer. ZDoom's old makefiles were a complete and utter mess nobody understood anymore. Why it's 18 MB though - no idea...

Guess again, my sound works fine for everything else.

Someone once told that FMod tends to bring out the worst in sound drivers... :D There's an OpenAL implementation in the works so we'll have to see when this can be used for real.

I don't know, but all the way to the right end of the slider was still too slow. Is it possible to configure this manually in the cfg file? (I didn't try myself, I just put up with a slow mouse for my gameplay...)

These are normal CVARs that can be changed at the console.

	{ slider,	"Overall sensitivity",	{&mouse_sensitivity},	{0.5}, {2.5},	{0.1}, {NULL} },
{YesNo} },
	{ slider,	"Turning speed",		{&m_yaw},				{0.5}, {2.5},	{0.1}, {NULL} },
	{ slider,	"Mouselook speed",		{&m_pitch},				{0.5}, {2.5},	{0.1}, {NULL} },
	{ slider,	"Forward/Backward speed",{&m_forward},			{0.5}, {2.5},	{0.1}, {NULL} },
	{ slider,	"Strafing speed",		{&m_side},				{0.5}, {2.5},	{0.1}, {NULL} },

Here's a list of menu items related to mouse sensitivity. The item after the name in each line is the CVAR that's being set. The 3 values are minimum, maximum and step size of the slider.

Graf Zahl said:
Strange that only Linux users have problems with this... It never, ever happened to me that I accidentally unpacked something organized this way in the wrong directory.

So Windows users don't have a command that just extracts files, do you have to manually copy+paste files?

CMake is still loads better than those abomination called autotools and the baggage that comes with it. Maybe not for you as the end user but certainly for me as developer. ZDoom's old makefiles were a complete and utter mess nobody understood anymore. Why it's 18 MB though - no idea...

It's not better from an end-user experience, at the very least. Having to make directories, change to them, invoke cmake magick, is very counter-intuitive compared to a simple "make". Plus the fake that ZDoom's old Makefiles says little about the venerable make... it just says that the ZDoom project wasn't doing it right.

Oh, and I was wrong about the package size, turns out that it's 18MB *installed*, the package itself is "only" 6.7MB (that's still huge for a make replacement).

Someone once told that FMod tends to bring out the worst in sound drivers... :D There's an OpenAL implementation in the works so we'll have to see when this can be used for real.

This is a bullshit excuse and I hope you don't really believe it. The Intel HDA drivers are very well written, and they come from Intel itself, not to even mention that every other program I have ever ran supports sound perfectly fine, it's just ZDoom (and/or FMOD, I don't know for sure as that's the only FMOD program I've ever heard of either).

MikeRS said:

So Windows users don't have a command that just extracts files, do you have to manually copy+paste files?

No. I use 7zip's shell integration, open the dialog and can type in the destination directory.

It's not better from an end-user experience, at the very least. Having to make directories, change to them, invoke cmake magick, is very counter-intuitive compared to a simple "make". Plus the fake that ZDoom's old Makefiles says little about the venerable make... it just says that the ZDoom project wasn't doing it right.

CMake has its problems - but it definitely was a step in the right direction (i.e. making the maintenance of makefiles actually manageable for developers.) What do you prefer? A slightly unintuitive tool or constantly broken makefiles? Because that's what we had before because nobody was able to do them right.

Oh, and I was wrong about the package size, turns out that it's 18MB *installed*, the package itself is "only" 6.7MB (that's still huge for a make replacement).

CMake is not a make replacement but an autotools replacement.
About the size, does the Linux version come with a GUI tool? The Windows version, which is 25MB installed, contains 4 large EXEs, one of which is a 7MB GUI tool. I'd say the problem here is that they statically linked a large shared library into all 4 of these.

The Intel HDA drivers are very well written, and they come from Intel itself, not to even mention that every other program I have ever ran supports sound perfectly fine, it's just ZDoom (and/or FMOD, I don't know for sure as that's the only FMOD program I've ever heard of either).

I'm sorry but I can't help you here. Are you sure you checked any sound config option in the menu? You may have more luck asking at the ZDoom forum in the Linux thread. There's some people hanging around there who actually might know what is wrong.

Graf Zahl said:
No. I use 7zip's shell integration, open the dialog and can type in the destination directory.

This seems cumbersome compared to a plain "Extract", but whatever.

CMake has its problems - but it definitely was a step in the right direction (i.e. making the maintenance of makefiles actually manageable for developers.) What do you prefer? A slightly unintuitive tool or constantly broken makefiles? Because that's what we had before because nobody was able to do them right.

I'd prefer a plain "make" and someone to know how to write it -- there's an excellent book from O'Reilly called "Using GNU Make" (beware of an earlier book titled just "Using Make" or something similar, that is one of the few horrible O'Reilly books) to learn.

CMake is not a make replacement but an autotools replacement.
About the size, does the Linux version come with a GUI tool? The Windows version, which is 25MB installed, contains 4 large EXEs, one of which is a 7MB GUI tool. I'd say the problem here is that they statically linked a large shared library into all 4 of these.

There's no GUI tool as far as I can tell (from `dpkg --listfiles` and all the binaries...), and there'd be no reason it would be compiled with static libraries (there's few Debian packages which are staticly compiled, like screen or bash, for those instances where you might just be in single user mode and /usr won't be accessible).

I'm sorry but I can't help you here. Are you sure you checked any sound config option in the menu? You may have more luck asking at the ZDoom forum in the Linux thread. There's some people hanging around there who actually might know what is wrong.

Yes, I checked every option on the menu, nothing worked. Thanks for the tip about the forums, maybe I'll check that out some day ;)

MikeRS said:

This seems cumbersome compared to a plain "Extract", but whatever.

I rarely encounter archives that put all content in a subdirectory so it just became habit. In other words: I don't assume the best case scenario.

I'd prefer a plain "make" and someone to know how to write it -- there's an excellent book from O'Reilly called "Using GNU Make" (beware of an earlier book titled just "Using Make" or something similar, that is one of the few horrible O'Reilly books) to learn.

That'd be easier for *you* but not for the developers. I'm not too familiar with its internal workings but CMake sets up a lot of external dependencies for different platforms. So any makefile that might be useful for you does not help a MinGW user and vice versa. What about someone who would like to compile ZDoom with Microsoft's command line compiler. Again, your makefile would not help him. The CMake build files can be used everywhere. Before CMake we had to maintain several separate versions of each makefile for different platforms and more often than not they were not in sync. So please forgive me if we choose a process that is the least problematic all things combined - even if it means one or two additional steps for the end user. But the fact that the 'Linux does not compile' bug reports have significantly decreased since switching to CMake is telling more than anything else I'd say.

MikeRS said:
So Windows users don't have a command that just extracts files, do you have to manually copy+paste files?

If you right-click the icon you can use either "extract here", which dumps stuff in the directory the compressed file is in (d:\downloads\) or "extract files..." which opens a dialog where the default path is a folder named after the compressed file (d:\downloads\filename\).

Fact is that *nix users expect an archive to create a new directory itself, and of the form ${PACKAGE}-${PACKAGE_VERSION}, i.e. "gzdoom-1.2.0" (gzdoom-1-2-0-source is also an odd ordering, and let's not talk about the dots which have mysteriously become dashes).

I'm not sure what the big deal with CMake is. I've never found it a hassle to use. I haven't read the wiki article but the following has always worked for me (under Kubuntu 8.10):

$ cmake .
$ make

Granted that is a little more work than just typing make, but as Graf was saying, CMake is much easier for developers to use. Why should we learn another language to compile our applications to suit your resistance to press 7 more keys? Even then, once the Makefiles are generated you would rarely have to call CMake again (the Makefiles it generates call CMake if need be).

On the other hand, I don't know why Graf is arguing over the archive bomb issue. It's not a hard issue to fix. Hirogen2's post explains it well.

Blzut3 said:

On the other hand, I don't know why Graf is arguing over the archive bomb issue. It's not a hard issue to fix. Hirogen2's post explains it well.

There is no issue. However, Randy and I are not using Linux as our main working system, and we are not used to Linux 'conventions'. And why are Linux users implicitly expecting everything to be done their way? Furthermore, this is the first time in the 3.5 years I've been working on (G)ZDoom that this was ever brought up so it can't really be that critical an issue - except, of course, for people like MikeRS who show a certain tendency to demand from others others to do their work. :P

This naming convention is not common practice under Windows and to be honest, I never heard of it. As for the dashes instead of dots, blame some shitty Windows software. Bad experience in the past has led me not to use dots in filenames for distribution because some stuff mixes them up with extensions - which these are not.

It's not a "Linux convention" to make proper archives, it's generally been the expected way for all operating systems for a very long time. And to be frank, the software packaged in the all-files-under-root method almost always gives a first glimpse as to the quality that the software will be in... (oh and for what its worth, it's quite rare for me to come upon an archive packaged the way ZDoom is, no matter what format, who made it, or where it came from, it's just the general expectancy to have your archive extract to a specific directory rather than the current, with no user intervention required; and really, it's actually easier to make archives this way than it is to do it your way)

Blzut3: The instructions on the wiki for compiling ZDoom were a bit more complex than that, but doesn't it still seem silly at any rate to use CMake to autogenerate a normal Makefile? Make isn't exactly Malbolge, after all...

MikeRS said:

Blzut3: The instructions on the wiki for compiling ZDoom were a bit more complex than that, but doesn't it still seem silly at any rate to use CMake to autogenerate a normal Makefile? Make isn't exactly Malbolge, after all...

How often do I have to tell you that CMake is for generating multiplatform compile files? It creates makefiles and comparable output for all supported platforms, not just Linux. Maintaining all of this in a file format that's not directly designed for it is a major hassle and the bad history of ZDoom's makefiles before the CMake switch is ample proof of that. Not even the Linux guys managed to get them into a stable condition - and as I said before, the Linux and MinGW makefiles more often than not were out of sync with one working and the other not, depending on the last person working on them.

There's nothing silly about it. CMake wouldn't have been invented if there wasn't a very good reason for it

MikeRS said:

Blzut3: The instructions on the wiki for compiling ZDoom were a bit more complex than that, but doesn't it still seem silly at any rate to use CMake to autogenerate a normal Makefile? Make isn't exactly Malbolge, after all...

I do not think using CMake is silly at all. My own personal project using CMake for all platforms. Although ZDoom doesn't take this approach, it's possible to let CMake generate the project files for MSVC. This makes things easy for me as I don't need to make MSVC files (which for some reason Windows users demand) which I can't maintain. It also allows for generating project files for all the popular IDEs for example Code::Blocks and KDevelop. Most importantly, I can do this quickly with little background knowledge of using CMake. In all this leaves more time for me to work on the functionality of the program.

Or I could read a book on how to use Makefiles which could take anywhere from a few weeks to a month. In the end I have something that works with only Linux. If you want to work with your favorite IDE you have to create the project file yourself. In all, I see writing Makefiles manually overly complicated for little, if any, gain.

MikeRS said:

Make isn't exactly Malbolge, after all...

Unfortunately, it isn't LOLCODE either. That shit cracks me up.