Announcing SDL_image 1.2.4 (take 2)

SDL Development
#1

SDL_image 1.2.4 is now available!
http://www.libsdl.org/projects/SDL_image/

Changes since the last release:

  • Added support for RLE encoded BMP files
  • Added EHB and HAM mode support to the ILBM loader
  • Updated libtool support for new mingw32 DLL build process
  • Fixed crash loading certain PCX images
  • Added .la files to the development RPM, fixing RPM build on RedHat 8

Enjoy!
-Sam Lantinga, Software Engineer, Blizzard Entertainment_______________________________________________
SDL-announce mailing list
SDL-announce at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl-announce

#2

SDL_image 1.2.4 is now available!
http://www.libsdl.org/projects/SDL_image/

These have been built with new versions of libpng and zlib libraries, BTW.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

#3

Thank you!

One of my big problems with SDL_image (win32) was that PNG loading
eventually crashed. Linking with libpng 1.0.15 instead of 1.0.8 fixed
it though. Thank you for an official build though.

Oh btw, SDL_ttf had some kind of RWops problem (couldn’t load out of a
zip file using PHYSFS), is this fixed? Or is that a PHYSFS problem?

-TomT64

Sam Lantinga wrote:>>SDL_image 1.2.4 is now available!

http://www.libsdl.org/projects/SDL_image/

These have been built with new versions of libpng and zlib libraries, BTW.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

#4

TomT64 wrote:

Oh btw, SDL_ttf had some kind of RWops problem (couldn’t load out of a
zip file using PHYSFS), is this fixed? Or is that a PHYSFS problem?

I’m not sure what exactly the problem is you’re talking about, but a
problem that I had with SDL_ttf reading fonts from a ZIP file through
PhysFS, and that turned out to be an error on my part, is the following
(as far as my memory serves - I don’t remember all the details):

You can’t remove and re-add the ZIP file in question from the PhysFS
search path while SDL_ttf is using a font from there, because SDL_ttf
needs to read from there every time it renders a new glyph. What made
the bug difficult to find is that reading continued to work after
removing and re-adding the ZIP file, but it read from the wrong location
(off by 4 bytes or something) because some structure PhysFS keeps about
ZIP file entries wasn’t properly initialized.

After I worked around this (by copying the whole font into memory and
reading it from there through an RWops), I haven’t had any problems with
SDL_ttf and RWops. That was with SDL_ttf 2.0.6 and PhysicsFS 1.0.0, by
the way, I haven’t used SDL_ttf 2.0.7 yet.

-Christian

#5

I’ve experienced a problem when trying to read fonts from RWops, when the
font data is somewhere in a larger file. This is because SDL_ttf seeks to
some offset from SEEK_SET or SEEK_END. If the RWops object is created with
SDL_RWFromFP, SEEK_END naturally refers to the end of the file, and
SEEK_SET to the beginning of the file, not to the position of the file
pointer at the time when the RWops object was created.

I solved this by making a somewhat more flexible RWops creation function,
which allows the user to specify which range of the file to be used.

// Martin