SDL digest, Vol 1 #190 - 31 msgs

  1. On Windoze,

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

Sorry about that.

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

I’m sorry, but the two do not compare! An OpenGL newbie is not
going to realise out of the blue that the texture coordinates
given in examples from Nate Robins’s and NeHe’s tutorials work
because of the formats and the loaders they use - you might find
it “DUH!”, but this “Aha!” experience is not likely to strike
most mortals immediately.

  1. On Windoze, SDL automatically overrides my main( ) method
    IIRC, it overrides WinMain, not main. This is done in the interests of
    portability since everyone ELSE uses main.

(NOTE: Refer to the sources for SDL 1.2.3 for the following.)

“SDL_main.h” #defines main to SDL_main( ).
In console mode, main( ) is the entry point into the app, while
it is WinMain( ) for windowed applications.
SDL_main.c produces a “real” main( ) only for MSVC on
Windows - therefore, GCC/MinGW is not able to find a
main( ) for console apps.
For console apps, the console_main( ) function does some initialisations,
including calling SDL_Init( ) and then
calls the original main( ).

My point is this: if in any case I must call SDL_Init( ) before
using SDL functions, this function can do all the
initialisations it wants and leave my main( ) alone. If I happen
to compile with -mwindows (on MinGW), the WinMain( ) from SDL_main
can do all Win32-specific stuff and then call the main( ) in my
program. In either cases, my main( ) can be left alone. At least
from the SDL_main.c sources and header files, it appears that
the simpler scheme will also achieve pretty much the same
effect.

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.

RTFS! :stuck_out_tongue: It does it only for WinCE.

  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”.
    =20

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

Huh? For SDL 1.2.3, 307 is the last line of SDL_opengl.h and doesn’t
have much info.

Anyways, thanks a lot for your help and comments.

Ranjit.>From: Mattias Engdeg

From: Joseph Carter
From: “M. R. Brown” <mrbrown at 0xd6.org>
From: “M. R. Brown” <mrbrown at 0xd6.org>


Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Hi All!

I’ve just moved to new RH 7.2 and tried to make install the SDL from the
CVS code… But the resulting .so library doesn’t have the X11
dependency. Could you help me? I’m not that good in tracing linux .so
problems as I’m quite new to linux programming…
Please see the following snips.

thanks in advance

STan

--------- Cut -------------

after make install

$ ldd /usr/local/lib/libSDL.so
libc.so.6 => /lib/libc.so.6 (0x4007a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

build proces…

$ ./configure --enable-video-fbcon=yes --enable-video-aalib=yes
–enable-video-svga=yes --enable-input-event=yes

loading cache ./config.cache
checking host system type… i686-pc-linux-gnu
checking target system type… i686-pc-linux-gnu
checking for a BSD compatible install… (cached) /usr/bin/install -c
checking whether build environment is sane… yes
checking whether make sets ${MAKE}… (cached) yes
checking for working aclocal… found
checking for working autoconf… found
checking for working automake… found
checking for working autoheader… found
checking for working makeinfo… found
checking build system type… i686-pc-linux-gnu
checking for ranlib… (cached) ranlib
checking for gcc… (cached) gcc
checking whether the C compiler (gcc ) works… yes
checking whether the C compiler (gcc ) is a cross-compiler… no
checking whether we are using GNU C… (cached) yes
checking whether gcc accepts -g… (cached) yes
checking for ld used by GCC… (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld… (cached) yes
checking for BSD-compatible nm… (cached) /usr/bin/nm -B
checking whether ln -s works… (cached) yes
loading cache ./config.cache within ltconfig
checking for object suffix… o
checking for executable suffix… (cached) no
checking for gcc option to produce PIC… -fPIC
checking if gcc PIC flag -fPIC works… yes
checking if gcc supports -c -o file.o… yes
checking if gcc supports -c -o file.lo… yes
checking if gcc supports -fno-rtti -fno-exceptions … yes
checking if gcc static flag -static works… -static
checking if the linker (/usr/bin/ld) is GNU ld… yes
checking whether the linker (/usr/bin/ld) supports shared libraries… yes
checking command to parse /usr/bin/nm -B output… ok
checking how to hardcode library paths into programs… immediate
checking for /usr/bin/ld option to reload object files… -r
checking dynamic linker characteristics… Linux ld.so
checking if libtool supports shared libraries… yes
checking whether to build shared libraries… yes
checking whether to build static libraries… yes
checking for objdir… .libs
creating libtool
loading cache ./config.cache
checking whether make sets ${MAKE}… (cached) yes
checking for gcc… (cached) gcc
checking whether the C compiler (gcc -g -O2 ) works… yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler… no
checking whether we are using GNU C… (cached) yes
checking whether gcc accepts -g… (cached) yes
checking for inline… (cached) inline
checking for working const… (cached) yes
checking for c++… (cached) c++
checking whether the C++ compiler (c++ ) works… yes
checking whether the C++ compiler (c++ ) is a cross-compiler… no
checking whether we are using GNU C++… (cached) yes
checking whether c++ accepts -g… (cached) yes
checking for a BSD compatible install… /usr/bin/install -c
checking how to run the C preprocessor… (cached) gcc -E
checking for working alloca.h… (cached) yes
checking for alloca… (cached) yes
checking for nasm… no
checking for OSS audio support… yes
checking for sys/asoundlib.h… (cached) no
checking for snd_pcm_open in -lasound… (cached) no
checking for artsc-config… (cached) /usr/bin/artsc-config
checking for aRts development environment… yes
checking for esd-config… (cached) /usr/bin/esd-config
checking for ESD - version >= 0.2.8… yes
checking for NAS audio support… no
checking for X… (cached) libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet… (cached) no
checking for dnet_ntoa in -ldnet_stub… (cached) no
checking for gethostbyname… (cached) yes
checking for connect… (cached) yes
checking for remove… (cached) yes
checking for shmat… (cached) yes
checking for IceConnectionNumber in -lICE… (cached) yes
checking for XFree86 VidMode 1.0 support… yes
checking for XFree86 VidMode gamma support… yes
checking for XFree86 DGA 1.0 support… yes
checking for XFree86 XvImage support… yes
checking for X11 Xinerama support… yes
checking for Xi Graphics XiGMiscExtension support… no
checking for XFree86 DGA 2.0 support… yes
checking for framebuffer console support… yes
checking for pkg-config… (cached) /usr/bin/pkg-config
checking for DirectFB support… no
checking for PlayStation 2 GS support… no
checking for SVGAlib (1.4.0+) support… no
checking for AAlib support… no
checking for OpenGL (GLX) support… yes
checking for dlopen in -ldl… (cached) yes
checking for Linux 2.4 unified input interface… yes
checking for pthreads… yes
checking for recursive mutexes… yes
checking for pthread semaphores… yes
checking for broken glibc 2.0 pthreads… no
checking whether semun is defined in /usr/include/sys/sem.h… no
Copying src/main/linux/SDL_main.c -> src/main/SDL_main.c
Copying src/thread/linux/SDL_systhread.c -> src/thread/SDL_systhread.c
Copying src/thread/linux/SDL_systhread_c.h -> src/thread/SDL_systhread_c.h
Copying src/thread/linux/SDL_syssem.c -> src/thread/SDL_syssem.c
Copying src/thread/generic/SDL_syssem_c.h -> src/thread/SDL_syssem_c.h
Copying src/thread/linux/SDL_sysmutex.c -> src/thread/SDL_sysmutex.c
Copying src/thread/linux/SDL_sysmutex_c.h -> src/thread/SDL_sysmutex_c.h
Copying src/thread/linux/SDL_syscond.c -> src/thread/SDL_syscond.c
Copying src/thread/generic/SDL_syscond_c.h -> src/thread/SDL_syscond_c.h
Copying src/timer/linux/SDL_systimer.c -> src/timer/SDL_systimer.c
creating ./config.status
creating Makefile
creating docs/Makefile
creating docs/html/Makefile
creating docs/man3/Makefile
creating include/Makefile
creating src/Makefile
creating src/main/Makefile
creating src/main/macosx/Makefile
creating src/main/macosx/Info.plist
creating src/audio/Makefile
creating src/audio/alsa/Makefile
creating src/audio/arts/Makefile
creating src/audio/baudio/Makefile
creating src/audio/dma/Makefile
creating src/audio/dmedia/Makefile
creating src/audio/dsp/Makefile
creating src/audio/esd/Makefile
creating src/audio/macrom/Makefile
creating src/audio/nas/Makefile
creating src/audio/nto/Makefile
creating src/audio/openbsd/Makefile
creating src/audio/paudio/Makefile
creating src/audio/sun/Makefile
creating src/audio/ums/Makefile
creating src/audio/windib/Makefile
creating src/audio/windx5/Makefile
creating src/audio/disk/Makefile
creating src/video/Makefile
creating src/video/cybergfx/Makefile
creating src/video/x11/Makefile
creating src/video/dga/Makefile
creating src/video/nanox/Makefile
creating src/video/fbcon/Makefile
creating src/video/directfb/Makefile
creating src/video/ps2gs/Makefile
creating src/video/ggi/Makefile
creating src/video/maccommon/Makefile
creating src/video/macdsp/Makefile
creating src/video/macrom/Makefile
creating src/video/quartz/Makefile
creating src/video/svga/Makefile
creating src/video/vgl/Makefile
creating src/video/aalib/Makefile
creating src/video/wincommon/Makefile
creating src/video/windib/Makefile
creating src/video/windx5/Makefile
creating src/video/bwindow/Makefile
creating src/video/photon/Makefile
creating src/video/epoc/Makefile
creating src/video/dummy/Makefile
creating src/events/Makefile
creating src/joystick/Makefile
creating src/joystick/amigaos/Makefile
creating src/joystick/beos/Makefile
creating src/joystick/darwin/Makefile
creating src/joystick/dummy/Makefile
creating src/joystick/linux/Makefile
creating src/joystick/macos/Makefile
creating src/joystick/win32/Makefile
creating src/cdrom/Makefile
creating src/cdrom/aix/Makefile
creating src/cdrom/beos/Makefile
creating src/cdrom/dummy/Makefile
creating src/cdrom/bsdi/Makefile
creating src/cdrom/freebsd/Makefile
creating src/cdrom/linux/Makefile
creating src/cdrom/macos/Makefile
creating src/cdrom/openbsd/Makefile
creating src/cdrom/qnx/Makefile
creating src/cdrom/win32/Makefile
creating src/thread/Makefile
creating src/timer/Makefile
creating src/endian/Makefile
creating src/file/Makefile
creating src/hermes/Makefile
creating sdl-config
creating SDL.spec

  • Ranjit Mathew on Thu, Dec 20, 2001:

SDL_main.c produces a “real” main( ) only for MSVC on
Windows - therefore, GCC/MinGW is not able to find a
main( ) for console apps.

More like GCC/MinGW doesn’t need the console_main() hack like VC does.

My point is this: if in any case I must call SDL_Init( ) before
using SDL functions, this function can do all the
initialisations it wants and leave my main( ) alone. If I happen
to compile with -mwindows (on MinGW), the WinMain( ) from SDL_main
can do all Win32-specific stuff and then call the main( ) in my
program. In either cases, my main( ) can be left alone. At least
from the SDL_main.c sources and header files, it appears that
the simpler scheme will also achieve pretty much the same
effect.

You’ve lost me here. Do you have any code to back this up?

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.

RTFS! :stuck_out_tongue: It does it only for WinCE.

You obviously didn’t read far enough. In src/main/win32/SDL_main.c,
starting at line 166, is the definition of console_main(). console_main()
is called when you compile your app as a console-only application under
Win32. This has nothing to do with WinCE. If you would’ve read, you
would’ve noticed that NO_STDIO_REDIRECT is only used in WinMain, which is
the entry point for GUI apps.

So, RTFS over! :P.

  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”.
    =20

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

Huh? For SDL 1.2.3, 307 is the last line of SDL_opengl.h and doesn’t
have much info.

Sorry, I looked at the wrong field in vim. Here’s the quote from line 48:

/* This file taken from “GLext.h” from the Jeff Molofee OpenGL tutorials.
It is included here because glext.h is not available on some systems.
If you don’t want this version included, simply define “NO_SDL_GLEXT”
*/
#ifndef NO_SDL_GLEXT
#if !defined(_glext_h) && !defined(GL_GLEXT_LEGACY)
#define _glext_h

So the rest of that file is glext.h, it’s needed for platforms that don’t
have one.

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/20011220/b1bc985e/attachment.pgp> >From: “M. R. Brown” <@M_R_Brown>

From: “M. R. Brown” <@M_R_Brown>

My point is this: if in any case I must call SDL_Init( ) before
using SDL functions, this function can do all the
initialisations it wants and leave my main( ) alone. If I happen
to compile with -mwindows (on MinGW), the WinMain( ) from SDL_main
can do all Win32-specific stuff and then call the main( ) in my
program. In either cases, my main( ) can be left alone. At least
from the SDL_main.c sources and header files, it appears that
the simpler scheme will also achieve pretty much the same
effect.

The reason the initialization code is in there, is that older versions
of DirectX required that DirectInput have the application module handle.
If you call GetModuleHandle(NULL) from code in a DLL, you’ll get the handle
to the DLL, not the application. So, rather than make you have to do Win32
specific initialization, I overrode main(), which is necessary on other
platforms as well. At the same time I redirect the stdio because Windows
games are not going to ship as console applications - it looks unprofessional,
and most people are too lazy to set up their own in-game console or other
mechanism of redirecting stdio output. You are always able to redirect
stdio or use a different SDL_main.c - that’s why it’s in the public domain.

So… there you have it.

-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam Lantinga wrote:

The reason the initialization code is in there, is that older versions
of DirectX required that DirectInput have the application module handle.
If you call GetModuleHandle(NULL) from code in a DLL, you’ll get the handle
to the DLL, not the application. So, rather than make you have to do Win32

Whenever you have some time, do take a look at:

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0998/hood0998.htm&nav=/msj/0998/newnav.htm

It shows a way in which you can get the complete path to the EXE module
that called your DLL that can be (theoretically) passed to the
GetModuleHandle( ) method.

platforms as well. At the same time I redirect the stdio because Windows
games are not going to ship as console applications - it looks unprofessional,
and most people are too lazy to set up their own in-game console or other

OK. But how about executables that are run from a CD?

Ranjit.

Ranjit Mathew wrote:

Sam Lantinga wrote:

The reason the initialization code is in there, is that older versions
of DirectX required that DirectInput have the application module
handle.
If you call GetModuleHandle(NULL) from code in a DLL, you’ll get the
handle
to the DLL, not the application. So, rather than make you have to do
Win32

Whenever you have some time, do take a look at:

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0998/hood0998.htm&nav=/msj/0998/newnav.htm

Another useful link might be:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q175030

Unfortunately, you have to use ToolHelp32 APIs on Windows 95 and
PSAPI.DLL on WinNT, so the code might not be too clean. :frowning:
So it might not be worth the effort.

On the other hand, if the version of DirectInput is really so
old that most users can “reasonably” be expected to have better
versions, then we can avoid the whole problem.

Just my 2p.

Ranjit.

Sam Lantinga wrote:

The reason the initialization code is in there, is that older versions
of DirectX required that DirectInput have the application module handle.
If you call GetModuleHandle(NULL) from code in a DLL, you’ll get the handle
to the DLL, not the application. So, rather than make you have to do Win32

OK, so why can’t we call:

  1. GetCurrentProcess( ) to get a handle to the current process,
  2. GetModuleFileName( ) using the above handle to get the full path,
  3. GetModuleName( ) with the path obtained above to get the handle.

This should work, shouldn’t it?

Ranjit.