lib SDL version

Post by **fmunoz** » August 18th, 2006, 2:58 pm

Thepackaged version of Wesnoth for windows seems to use the 1.2.7 vesion of SDL.. a bit older...
Latest one is 1.2.11
http://www.libsdl.org/release/changes.html
Maybe updating it will help to fix minor some bugs.. (At least one memory leak fixed)
(SAme with SDL image 1.2.5 vs 1.2.3, ...)
Can anyone compile the game in Windows and check if the version behaves better or if the upgrade breaks things?

zaimoni · Post by **zaimoni** » August 18th, 2006, 10:07 pm

I did notice an immediate speed increase from SDL 1.2.11 as opposed to 1.2.10, which in turn is somewhat faster than SDL 1.2.7. However, the DLL dependencies for the prebuilt SDL were more complicated enough to break the official Windows build when the jump from 1.2.7 to 1.2.10 was attempted.

Note that libPNG is on at least 1.2.12 now.

[The problem looks like the provided libPNG. Basically, my build-from-source uses staticly linked zlib and libJPEG in both libSDL and libPNG. As for the other libraries, the prebuilt binaries were lagging cutting edge for MSVC by one version]

Post by **torangan** » August 18th, 2006, 11:39 pm

Yes, getting binaries of the dependency libs is the source of the problem. If you've got a working set of libraries by all means contact YogiHH our windows packager! We'd love to see recent versions of all libs in use.

Post by **Yogibear** » September 6th, 2006, 10:22 pm

That's true. I remember one try to use newer versions and i gave up mainly because of libPng and sdl_mixer. They compile and link ok, but they don't seem to work right. IIRC, sdl_mixer cripples the sound and libPng makes wesnoth crash.

I will see about what you mentioned so far, though.

zaimoni · Post by **zaimoni** » September 7th, 2006, 2:01 pm

Hmm...while you're at it, one thing that caught me by surprise is that the official Wesnoth Windows build is on zlib 1.1.3.1. for both zlib.dll and zlib1.dll Correct form would be to use only one of zlib.dll (1.1.4.x) or zlib1.dll (1.2.3).

The latest is zlib 1.2.3 (prebuilt DLL available). There are interface incompatibilities between the 1.1 and 1.2 series, which is why the DLL was renamed.

I don't see anything in the libpng documentation, but I haven't checked other libraries to see if they are blocking the upgrade on zlib 1.1.x. In particular, I'm not quickly finding documentation on the minimum zlib version for either SDL 1.2.11 or freetype 2.2.1.

Post by **torangan** » September 7th, 2006, 3:26 pm

If you've got a working binary using recent version of the dependencies, why don't you simple sent Yogi Bear a zip with your dll files? Would be nice to get a "free speedup" for the windows binary that way.

zaimoni · Post by **zaimoni** » September 8th, 2006, 1:42 pm

Yes, my local build works without any of the mentioned glitches.

I probably should try to upgrade my SDL-mixer to 1.2.7 before composing that ZIP archive.

zaimoni · Post by **zaimoni** » September 8th, 2006, 4:25 pm

libogg-1.1.3 installed fine, libvorbis-1.1.2 won't build. (libtool broken, need to fix installation process for both automake and libtool to deal with it; same problem as for libintl and gettext). So no upgrade on SDL_mixer right now.

I'll prepare the ZIP archive (both DLLs, *.h files, and *.a files) for MingW32/GCC 3.4.5, along with which libraries need linking, if Yogi wants to work with it.

Post by **torangan** » September 8th, 2006, 5:01 pm

Do those libs then also work with VC++?

zaimoni · Post by **zaimoni** » September 8th, 2006, 5:40 pm

I do not have the *.lib files for MSVC on hand, except for SDL_net 1.2.6 (where I made the *.a file from the prebuilt MSVC *.lib file). I can research the procedures for making the *.lib files, but I cannot test them (I don't have MSVC installed locally).

libpng uses C setjmp/longjmp for error handling by default, so I don't know whether the MingW32 build would crossover to MSVC safely.

EDIT I believe all DLLs on my end, other than the prebuilt SDL 1.2.11, would link with MSVC++ if they had working *.lib files. libpng needs verification to see what would happen if an error requiring longjmp happened. [Function signature clash on WinMain means that the prebuilt for MSVC++ SDL1.2.11 would have to be used for that.]