ZDoom 2.0.98 Bugfixing bugfix release

[randi]

Due to an unexpected change in the code generated by the compiler, ZDoom 2.0.97 had a nasty habit of crashing while saving a game. <a href="http://zdoom.org/files/lars/98.cab">ZDoom 2.0.98</a> fixes this and more.

[Chris]

Compiles nicely so far. I'll just list out the problems I run into as I get them (and fixes). I'll make up a patch later.

Code: Select all • Expand view

src/m_misc.cpp: In function `string GetUserFile(string, bool)':
src/m_misc.cpp:305: error: cannot convert `string' to `const char*' for argument `1' to `size_t strlen(const char*)'
src/m_misc.cpp:332: error: cannot convert `string' to `const char*' for argument `2' to `char* strcat(char*, const char*)'

These two were easy to fix. Changed strlen(file) to file.Len(). Also changed the function's strcat's and return value to return string(path)+"/"+file; (btw, naming your string class as 'string'.. evil I thought it was std::string at first).

And that's it. The rest (including zdoom.wad) compiles and runs fine, as far as I can see. Only other issues are some uninitialized variable warnings in r_polymost and thingdef (don't seem to be of any immediate detriment). And the patch here dealing with finding savegames in ~/.zdoom wasn't applied (and unfortunately wouldn't apply cleanly to .98). I'll make up a diff/archive, that has an updated cbuild.c, and a Linux binary soon.

[zloba]

(on Linux) here's what I got:

0. m_misc.cpp, like Chris said.

1. had to #include <unistd.h> in src/w_wad.cpp, because:

Code: Select all • Expand view

src/w_wad.cpp: In function `int filelength(int)':
src/w_wad.cpp:146: error: `close' undeclared (first use this function)

2. (edit: never mind, I'm stupid so I used the old Makefile; removing music_spc from the makefile did the trick)
.. there was some LoadLibraryA() etc. in src/sound/music_spc.cpp; I did #ifdef _WIN32 the whole block without looking much.

3.

Code: Select all • Expand view

-#include <SDL.h>
+#include <SDL/SDL.h>

in a few places.

4. the missing fix refused to be applied for some reason, so I hand-applied it.

(It's nice, though - the patch gets smaller and smaller )
Thanks to Chris for the original patch.

p.s. I don't mean to step on Chris's toes, sorry if I did It's just that I did it myself anyway, so why not double-check stuff..

[Chris]

Here's my patch. Make sure you're using the cbuild script (chmod +x cbuild.c and run it, or manually compile it). You can get a binary here. I still uses the "older" FLAC libs, so you'll either need to get them, or try using symlinks (portage doesn't have the newer libs marked stable yet).

EDIT: updated patch to fix crash when specifying non-existant wads (or wads that are found when searching the wad dir list).

[randi]

3.

Code: Select all • Expand view

-#include <SDL.h>
+#include <SDL/SDL.h>

I'd just like to point out that "SDL/SDL.h" is not the recommended way to use the SDL headers. See Do I #include <SDL.h> or <SDL/SDL.h>? (Yes, I notice they say to use quotes instead of angle brackets. That might be something new.)

As for why you aren't supposed to need to include the SDL directory path in the #include, see How do I add SDL to my project? Using sdl-config as they suggest will produce the appropriate -I command line arguments to include the SDL directory in the include search path.

Question: What does the I_FindFirst patch do? Does it still work for finding files in arbitrary paths? (i.e. if you use the dir console command to get a directory listing)

[kvh]

Here's my patch. Make sure you're using the cbuild script (chmod +x cbuild.c and run it, or manually compile it).

What version of gcc are you using Chris?

I get this error with gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)

cc1plus: error: invalid option `tune=athlon-xp'

I just removed the 'tune=' and it compiles fine.

Thanks for your work!

[Chris]

Using sdl-config as they suggest will produce the appropriate -I command line arguments to include the SDL directory in the include search path.

The cbuild script adds `sdl-config --cflags` to the command line.

Question: What does the I_FindFirst patch do? Does it still work for finding files in arbitrary paths? (i.e. if you use the dir console command to get a directory listing)

It allows you to use directory paths in the search path (so you can search for $HOME/.zdoom/*.zds, for example). Normally scandir gets passed "." as the directory to search, and makes any specified path invalid, but the patch makes it so it gets passed the directory, if specified, or "." otherwise.

That said, there's a bug in I_FindClose (or whatever calls I_FindClose) that'll cause a crash if it's given a "failed" handle, -1. I'll update the patch to fix this right after I post this.

What version of gcc are you using Chris?

3.4.4. -mcpu was deprecated in 3.4 in favor of -mtune.

[Hirogen2]

What version of gcc are you using Chris?

3.4.4. -mcpu was deprecated in 3.4 in favor of -mtune.

But it is still accepted in 4.0.2, at least in suse linux (plus a warning, of course).

[Graf Zahl]

Are there plans for a stable floating point release before rewriting the actor handling completely?

BTW, what is a 'bugfixing bugfix release'?

[Hirogen2]

BTW, what is a 'bugfixing bugfix release'?

In technical release terms, that would be a ver.sion.number-tryX release

[Chris]

But it is still accepted in 4.0.2, at least in suse linux (plus a warning, of course).

True, but there really isn't any reason not to be using 3.4.4. It's perfectly stable as far as I've seen (been using 3.4 exclusively since 3.4.2 came out) and optimizes better. And having a warning on every source file (or warnings in general) is ugly.

[ellmo]

Okay, can somebody please speak "human english", and tell me does the new version do, apart from having trouble with multiple PNAMES ?

[TheDarkArchon]

Fixes that horrible hub crash.

[Hirogen2]

and tell me does the new version do, apart from having trouble with multiple PNAMES?

"Support" for multiple PNAMES/TEXTURE1 was added somewhere between 2.0.48 and 2.0.51, and works with 2.0.96 and 2.0.96x (aka GZDoom). Did not yet have the time to check 2.0.97/.98.
("Support" as in "pnames are added, not overwritten like in vanilla and other dooms")

[Graf Zahl]

The bug was introduced in .97.