Basically just requesting that an implementation of the SDL_gfx’s
rotozoom functions be implemented as a part of SDL 1.3 (since doing
those in OpenGL or Direct3D should be quite fast and simple compared to
in software).
If this has already been suggested or implemented and I failed to notice
it, then I’m sorry.
Also, if SDL_image could have IMG_SaveJPG, etc functions added when
updating for SDL 1.3, that would be great. I really hate having to deal
with libjpeg/libpng directly and would rather not force my users to
waste hard disk space for a bitmap file when they should have a
compressed image format provided to them.
Again, if this is already planned or implemented and I didn’t notice, sorry.
I submitted a IMG_SavePNG patch a while back, but nobody’s gotten around to actually applying it to the library yet. If you know enough about libjpeg to implement a saving routine, try writing one up and submitting it.
Also, if SDL_image could have IMG_SaveJPG, etc functions added when updating for SDL 1.3, that would be great. I really hate having to deal with libjpeg/libpng directly and would rather not force my users to waste hard disk space for a bitmap file when they should have a compressed image format provided to them.
Again, if this is already planned or implemented and I didn’t notice, sorry.From: nfries88@yahoo.com (Nathaniel J Fries)
Subject: [SDL] [SDL 1.3] Rotation and stretching of textures + SDL_image 1.3
Actually, I have no idea how to use either library. I can’t find any
actual tutorial or formal reference for libjpeg, and
any time I try writing something with libpng or zlib I end up confusing
myself. Otherwise I’d gladly submit patches.
I think adding surface/texture rotation is a good idea, but there is a
detail to consider. When SDL adds a hardware-accelerated function, it
also needs a (non-OpenGL) software fallback. In this case, you’d want
an accurate rotation to match the hardware one, but rotozoom is very
slow. Hence, the usages are incompatible. Hardware rotation is
commonly done in real time. If you know that you’re using rotozoom,
then you should never try to rotate in real time. Programming
naively, this would cause a program’s performance to be very
surprising (and unusable) if the graphics can’t be accelerated.
I do have a much faster rotation function (from Sprig and SGE) that I
use in real time, but I haven’t had the time to squash a bug in it and
it would need thorough testing.
I submitted a IMG_SavePNG patch a while back, but nobody’s gotten around to
actually applying it to the library yet. If you know enough about libjpeg
to implement a saving routine, try writing one up and submitting it.
From: Nate Fries
**Subject: [SDL] [SDL 1.3] Rotation and stretching of textures +
SDL_image 1.3
Also, if SDL_image could have IMG_SaveJPG, etc functions added when
updating for SDL 1.3, that would be great. I really hate having to deal with
libjpeg/libpng directly and would rather not force my users to waste hard
disk space for a bitmap file when they should have a compressed image format
provided to them.
Again, if this is already planned or implemented and I didn’t notice,
sorry.