I used SDL 1.2.3 on both Windoze and Linux. There were a
couple of “irritants” that I think you should know:
- On Windoze, SDL automatically overrides my main( ) method
even if I’m using SDL headers merely to be able to use Uint32, etc.
I have to “#undef main” - if I do call SDL_Init( ), what’s the
point in overriding main( )?
IIRC, it overrides WinMain, not main. This is done in the interests of
portability since everyone ELSE uses main. This is a feature, really. If
it’s not doing that, then we have something to discuss.
- Again on Windoze, the stderr and stdout streams are
redirected to text files, even if I create a console application
(-mconsole on Mingw) - I had to open two files just to
be able to see my debug messages!
SDL should be smart enough to handle this, I agree. Currently, SDL does
not have any concept of a text-only application in win32. A flag should
exist to inhibit this. A win32 console similar to Q3A would also be a
nice thing. I know approximately how to do it (I at least know which
function calls are involved) but since I don’t do win32 stuff, putting it
together in a usable manner is not trivial.
- For some reason, my application always gets a MOUSEMOTION
event the moment it starts up, even though I’m miles away from
my mouse. Can there be an “SDL_ClearEvents( )” or something
that I can use before I go into my event loop?
I suspect this mousemotion event is there deliberately, to tell you where
the mouse currently is.
- On Windoze, SDL_image.dll requires the PNG, ZLIB and JPEG
DLLs, even though I use only JPEGs - should the DLLs not be
loaded dynamically as needed? Or is that error-prone?
knghtbrd at galen:~$ dpkg -s libsdl-image1.2
Package: libsdl-image1.2
[…]
Version: 1.2.0-2
Depends: libc6 (>= 2.2.4-4), libjpeg62, libpng2 (>= 1.0.12),
libsdl1.2debian, zlib1g (>= 1:1.1.3)
Description: image loading library for Simple DirectMedia Layer 1.2
You were saying? =) I use OpenGL exclusively myself. SDL_Image is
basically a mess for me to use since it loads in an arbitrary fashion. If
I could count on RGB or BGR with an A at one end or the other, I could
cope with that. Chances are good, SDL will always return that, but I
can’t count on it. Instead, I basically wrote my own functions for
loading and saving from my own image format. Something like this is
generally suitable:
typedef struct image_s
{
Uint32 width;
Uint32 height;
Uint32 format;
Uint8 *palette;
Uint8 *pixels;
} image_t
The format is one of IMG_INDEXED, IMG_GREYSCALE, IMG_RGBA8, IMG_BGR8, etc.
I’m going to sidetrack a little here for a rant. Basically, I don’t
support many image formats in my code. Targa is obvious for OpenGL
because it’s braindead simple and has an alpha channel. The RLE variant
isn’t hard to support. PCX is supported because it’s the indexed color
version of Targa. I also use libpng because the format has better
compression and can do everything I need, and libjpeg basically because
users expect to be able to save jpeg screenshots directly these days.
Okay, now the rant: I hate libraries. Experience has taught me to code
as if every single OS vendor is out to break things just to make me have
to help some poor unsuspecting newbie figure out how to fix it. Each of
Win32, Mandrake (no surprise there - but that’s another rant), SuSE, and
Debian have all managed to have seriously screwed up OpenGL build support
at some point in the past year or so, and that’s JUST OpenGL!
Fortunately, we currently depend only on SDL and the system library to
compile. With the exception of Mandrake and Win32, I have never had a
problem helping a user get that much working onder their standard build
environments. We have our own OpenGL headers and we bind our OpenGL
library at runtime with a little help from SDL. If that help weren’t
there, we’d have written the code ourselves (and actually have.)
So now we have zlib (which has been screwed up on a few dists), libpng,
and libjpeg to consider. Frankly, I have no intention of linking any of
them on any system. The active parts of libpng and libjpeg will go into
subdirectories and be compiled in staticly. As for zlib … ew, I think
we will probably come up with our own deflate code if we can, that lib’s
just nasty. Sure most people probably run some desktop thingy which links
to those libs and we could save memory by doing the same. But as long as
we are forced to contend with broken build environments with most of the
Linux distributions, frankly I’d prefer to save my sanity. Okay, end of
rant, back to your regularly scheduled comments.
- SDL_image functions as well as the SDL_LoadBMP( ) function,
all return images in top-to-bottom scanline order. This is a
GOOD thing, but should be mentioned somewhere - for example,
TGA and BMPs are stored the other way round, so my texture
coordinates went for a toss when I shifted from native
functions to SDL functions…
This truly is your own fault. First of all, you should not depend on
which direction the image is saved. Yes, bitmaps are saved upside down.
But if you use them that way, you’re seriously asking for problems. As
for Targa, they can be stored horizontally or vertically flipped. You’d
better test for that, it’s one of the few ways in which the Targa format
is more complicated than we’d like. The other one is that the Targa
format demands that RLE not cross line boundaries, and people’s Targa
writers do that all the time so you’d better be able to read it.
- The resolution of SDL_GetTicks( ) is not enough - I think
on quite a few platforms you can get a much better clock
resolution than 1 millisecond.
Forest Hale would agree with you. It’s not fine enough resolution for
timing individual subsystems if you’re getting more than about 50 frames
per second. Of course, individual frame timings are not nearly as useful
as profile data, which I can get pretty easily on my preferred development
platform. A visible FPS counter is useless to players if it updates any
more often than once every tenth of a second. Mine update every quarter.
I still think SDL should continue to work with OpenGL even if it cannot
find GL/gl.h (or whatever) at compile-time. If the functions are there
and the requisite headers aren’t, include a nice aux header that has all
of the necessary defines for SDL to work. The only reason not to do this
is the OpenGL data types, and those can be determined by platform anyway.On Wed, Dec 19, 2001 at 04:29:02PM +0530, Ranjit Mathew wrote:
–
Joseph Carter Free software developer
If we want something nice to get born in nine months, then sex has to
happen. We want to have the kind of sex that is acceptable and fun for both
people, not the kind where someone is getting screwed. Let’s get some cross
fertilization, but not someone getting screwed.
– Larry Wall
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011219/c1fe2370/attachment.pgp