[Fwd: Some Suggestions]

Hi,

 On Sam's suggestion, I'm posting this message to

this list. Your comments are welcome.

Ranjit.> ----- Original Message -----

Subject: Some Suggestions
Date: Tue, 18 Dec 2001 14:13:12 +0530
From: rmathew@hotmail.com (Ranjit Mathew)
To: slouken at libsdl.org

Dear Sam,

  I've been using SDL for a while now and in fact, just

completed a small demo using OpenGL/SDL:

http://ranjitmathew.tripod.com/philez/index.html#vtaj

I used SDL 1.2.3 on both Windoze and Linux. There were a
couple of “irritants” that I think you should know:

  1. 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( )?

  2. 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!

  3. Rather than having to #define NO_SDL_GLEXT (I get errors
    otherwise), the default should be the other way - I should
    explicitly #define SDL_GLEXT for SDL to correctly load “glext.h”.

  4. 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?

  5. 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?

  6. 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…

  7. The “SDL Data Source” seems to be an undocumented thingy
    gleamed only by looking at the SDL headers…

  8. 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.

That’s enough for now. :wink:

I’m sorry if this sounds unfairly critical, but I just thought
that SDL could become even better than it already is if
such minor things are “fixed”.

Thanks once again for SDL,

Ranjit.


Ranjit Mathew E-Mail: rmathew at hotmail.com

Member (Technical Staff) Phone: +91-80-209 75 11/12/13
Torry Harris Business Solutions, Fax: +91-80-226 84 42
Bangalore, INDIA. http://ranjitmathew.tripod.com/


Ranjit Mathew E-Mail: rmathew at hotmail.com

Member (Technical Staff) Phone: +91-80-209 75 11/12/13
Torry Harris Business Solutions, Fax: +91-80-226 84 42
Bangalore, INDIA. http://ranjitmathew.tripod.com/

Ranjit Mathew wrote:

  1. On Windoze,

I think people will take you more seriously if you spell names correctly,
regardless of what you think of them

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?

Cross-platform dynamic loading is somewhat tricky and not yet
implemented except for openGL. If it can be done in a sufficiently
clean way, dynamic loading of needed libs for SDL_image may be added
to a later release

  1. 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…

That’s your problem. I’m not going to add “SDL_LoadBMP() does not load
your image upside-down” to the docs. sorry. Nor “SDL_Init does not
play ‘God Save the Queen’ when invoked at tea-time”.

  1. 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.

Your first statement does not follow from the second.
Experience shows that 1 ms is enough, and portable.

I used SDL 1.2.3 on both Windoze and Linux. There were a
couple of “irritants” that I think you should know:

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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

  1. 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!

have you not heard of freopen?_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

  • Joseph Carter on Wed, Dec 19, 2001:

I used SDL 1.2.3 on both Windoze and Linux. There were a
couple of “irritants” that I think you should know:

  1. 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.

Start reading under src/main/. SDL “overrides” main() for linux, win32,
macos, macosX, beos, and epoc. On these targets, it defines your main as
SDL_main, which gets called after it does it’s main() initialization. What’s
there to discuss?

  1. 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.

Again, read the sources. SDL does know the difference between console and
GUI apps under win32. SDL will not redirect STDIO if you compile as a
console-only app. Compiling as a console or GUI app is determined by
compiler/IDE options, e.g. you can say “-mconsole” or “-mwindows” on the
cygwin/mingw command-line to select the type you wish to build.

The original poster was either using a very old version of SDL (or did SDL
always not redirect for console apps?) or he’s not actually compiling as a
console app and needs to check his mingw setup.

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011219/8d6a6830/attachment.pgp> On Wed, Dec 19, 2001 at 04:29:02PM +0530, Ranjit Mathew wrote:

  • Ranjit Mathew on Wed, Dec 19, 2001:
  1. Rather than having to #define NO_SDL_GLEXT (I get errors
    otherwise), the default should be the other way - I should
    explicitly #define SDL_GLEXT for SDL to correctly load “glext.h”.

Read include/SDL_opengl.h starting with the comments around line 307.

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011219/c57b7ab4/attachment.pgp