ZDoom 2.0.98 Bugfixing bugfix release
Moderator: GZDoom Developers
ZDoom 2.0.98 Bugfixing bugfix release
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
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
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.
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.
Code: Select all
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*)'

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.
(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:
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.
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..
0. m_misc.cpp, like Chris said.
1. had to #include <unistd.h> in src/w_wad.cpp, because:
Code: Select all
src/w_wad.cpp: In function `int filelength(int)':
src/w_wad.cpp:146: error: `close' undeclared (first use this function)
.. 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
-#include <SDL.h>
+#include <SDL/SDL.h>
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

- Attachments
-
98linux.tar.bz2
- patch and makefile
- (7.3 KiB) Downloaded 408 times
Last edited by zloba on Wed Nov 02, 2005 10:33 pm, edited 3 times in total.
- Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
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).
EDIT: updated patch to fix crash when specifying non-existant wads (or wads that are found when searching the wad dir list).
Last edited by Chris on Thu Nov 03, 2005 1:28 am, edited 1 time in total.
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.)zloba wrote: 3.Code: Select all
-#include <SDL.h> +#include <SDL/SDL.h>
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)
Linux gcc version?
What version of gcc are you using Chris?Chris wrote:Here's my patch. Make sure you're using the cbuild script (chmod +x cbuild.c and run it, or manually compile it).
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
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
The cbuild script adds `sdl-config --cflags` to the command line.Using sdl-config as they suggest will produce the appropriate -I command line arguments to include the SDL directory in the include search path.
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.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)
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.
3.4.4. -mcpu was deprecated in 3.4 in favor of -mtune.What version of gcc are you using Chris?
- Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
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.But it is still accepted in 4.0.2, at least in suse linux (plus a warning, of course).
- TheDarkArchon
- Posts: 7656
- Joined: Sat Aug 07, 2004 5:14 am
- Location: Some cold place
- Hirogen2
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Operating System Version (Optional): Tumbleweed x64
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
- Contact:
"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.and tell me does the new version do, apart from having trouble with multiple PNAMES?
("Support" as in "pnames are added, not overwritten like in vanilla and other dooms")