The error seems to be in SDL_GetVideoMode().
SDL_VideoModeOk() returns 0, but within SDL_GetVideMode() [at line 436],
the variable table it intialized with ((*BitsPerPixel+7)/8)-1.
For BitsPerPixel == 33, table would be 4 and out of range of
SDL_closest_depths.
As for the test case 4545: SDL_closest_depths + 4545 seems to be zero’d
(at least on my system).
Okay, thanks for the help, it should be fixed in CVS now.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I went to `video/wincommon/SDL_sysevents.c’ to see if you really did the
full job (also replacing numbers with constants there), and I see you
did… :))))
But then again, why are the first three buttons as numbers (1,2,3) and
not constants?
Okay, okay, such a stickler. 
/me signs you up for some free SPAM…
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I’m gearing up to release SDL 1.2.5
Are there any outstanding bugs that need to be fixed, which have not
been fixed in the CVS code: http://www.libsdl.org/cvs.php
The BSD USB HID bugs I reported (with a patch) in
http://www.libsdl.org/pipermail/sdl/2002-July/047343.html
has not been fixed yet.
/KristerOn Sun, 18 Aug 2002, Sam Lantinga wrote:
Under windows, if you have a mouse click trigger a change from fullscreen to
windowed mode and let go of the button before the mode change is complete
SDL_GetMouseState will report that the mouse button is still down until you
click the mouse button again. If you hold the mouse button until the change
is complete and then let go everything is fine.
This was a tricky one. The mouse state had to be reset when the video mode
was changed, and then because SDL switches to DirectInput in fullscreen mode,
the DirectInput mouse queue needed to be flushed.
It should work now in CVS though.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
The BSD USB HID bugs I reported (with a patch) in
Ah, good call, thank you very much.
See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Hi Sam,
A special version of SDL 1.2.4 is shipping with C++ Builder for Linux
and includes specific C++ Builder for Linux project files for all the
standard SDL, SDL_Image, SDL_Mixer and SDL_net demos. All the demos were
compiled with C++ Builder for Linux and ran under Linux without any
problems. If this was not the case it would not be shipping out of the
box with C++ Builder for Linux ( AKA Kylix 3 ).
I did post an announcement here about it but obviously no one really
paid attention to it, and also a link to the archive that will appear on
the Kylix 3 Companion CD under C++. The link again is…
http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=18309
The project files in this archive are also more up to date than the ones
mentioned in the FAQ and the project files are for all of Borland’s C++
compilers.
So in short, yes I have access to C++ Builder for Linux.
Trial versions of C++ Builder for Linux ( AKA Kylix 3 ) can be
downloaded from…
http://www.borland.com/products/downloads/download_kylix.html, if anyone
is interested. Make sure you click on the link for version 3 as version
2 and 1 did not support C++.
Btw is Kylix 3 the first commercial C++ compiler that is shippping with SDL?
Dominique.
Sam Lantinga wrote:>>Hi Sam,
Any chance of including the Borland C++ Builder for Linux and Windows
project files in the next release?Do the projects on the FAQ page work unmodified with the latest source?
Do you have access to C++ Builder for Linux?See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I did post an announcement here about it but obviously no one really
paid attention to it, and also a link to the archive that will appear on
the Kylix 3 Companion CD under C++. The link again is…
http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=18309
Generally I see “Borland” and immediately hit “Delete”.
So in short, yes I have access to C++ Builder for Linux.
It would probably be valuable to have these more closely maintained with
the SDL sources (in cvs, even?) … otherwise users will likely find they
are bound to whatever prepackaged SDL comes with C++ Builder (being
1.2.4, it’s about to become obsolete, too). If Borland is actively
maintaining those project files, though, that’s cool.
Then again, I’m not volunteering, so I’ll shut up.
–ryan.
Hi Sam,
A special version of SDL 1.2.4 is shipping with C++ Builder for Linux
and includes specific C++ Builder for Linux project files for all the
standard SDL, SDL_Image, SDL_Mixer and SDL_net demos. All the demos were
compiled with C++ Builder for Linux and ran under Linux without any
problems. If this was not the case it would not be shipping out of the
box with C++ Builder for Linux ( AKA Kylix 3 ).
The project files in this archive are also more up to date than the ones
mentioned in the FAQ and the project files are for all of Borland’s C++
compilers.
Very cool. I’ll be adding your projects to SDL as soon as I get a chance.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I’m gearing up to release SDL 1.2.5
Are there any outstanding bugs that need to be fixed, which have not
been fixed in the CVS code: http://www.libsdl.org/cvs.php
Nothing drastically important at this time but it’s worth mentioning
Cygwin. I realise it’s rather pointless attempting a “unix” XFree86
build atm. Nevertheless I’m a glutton for punishment plus I believe
shared memory support is getting closer: if the XPutImage() bottleneck
vanishes folks may want to investigate stuff like ParaGUI etc or simply
make use of cygwin for win32<-SDL->X ports.
My point? Just that default compilation behaviour for cygwin is unix
whereas I notice SDL-1.2.4 targets mingw OOTB. This is unexpected and
undesirable because it’ll break any unix app trying to make use of
’sdl-config’.
It’s worth noting that ‘specs’ will ensure -D__CYGWIN__ -Dunix (and
flavours) are defined but not MINGW32 and WIN32 (nor flavours). I
can post ‘specs’ - just didn’t want to waste space unbeckoned.
Conversely, pass “-mno-cygwin” to the compiler and it toggles to mingw
mode. CYGWIN and unix vanish to be replaced by -D__MINGW32__ and
-DWIN32 (and flavours). ‘specs’ also ensures various headers and
libraries appear and vanish accordingly.
I guess all your script guru needs be concerned with is ensuring the
compiler becomes “gcc -mno-cygwin” in ‘configure’ when everybody (but
me!) wants to compile a mingw target SDL under Cygwin.
Oh, I just noticed this. Perhaps I have got a bug to report after all!
/* return the preferred visual to use for openGL graphics */
XVisualInfo X11_GL_GetVisual(_THIS)
— SDL-1.2.4/src/video/x11/SDL_x11video.h.ORIGINAL 2002-08-12
03:12:57.000000000 +0100
+++ SDL-1.2.4/src/video/x11/SDL_x11video.h 2002-08-12
03:13:53.000000000 +0100
@@ -71,9 +71,9 @@
/ Direct Graphics Access extension information */
int using_dga;
–
swamp-dog at ntlworld.com
Hi Sam,
Sam Lantinga wrote:
Very cool. I’ll be adding your projects to SDL as soon as I get a chance.
Btw, as I am not really a true C/C++ developer ( though Kylix 3 almost
convinced me to make the jump ) the C++ Kylix project files really need
a knowledgable C/C++ developer to maintain them and to create new demos.
So if there are any takers please let me know.
Dominique.
oops, forgot to mention examples!
Conversely, pass “-mno-cygwin” to the compiler and it toggles to mingw
mode. CYGWIN and unix vanish to be replaced by -D__MINGW32__ and
-DWIN32 (and flavours). ‘specs’ also ensures various headers and
libraries appear and vanish accordingly.I guess all your script guru needs be concerned with is ensuring the
compiler becomes “gcc -mno-cygwin” in ‘configure’ when everybody (but
me!) wants to compile a mingw target SDL under Cygwin.
— SDL-1.2.4/include/SDL_syswm.h.ORIGINAL 2002-08-12
03:06:25.000000000 +0100
+++ SDL-1.2.4/include/SDL_syswm.h 2002-08-12 03:08:09.000000000
+0100
@@ -50,7 +50,7 @@
/* This is the structure for custom window manager events */
#if (defined(unix) || defined(unix) || defined(_AIX) ||
defined(OpenBSD)) && \
(removed because MINGW32 won’t have ‘unix’ defined)
— SDL-1.2.4/src/SDL_error.c.ORIGINAL 2002-08-12 04:52:25.000000000
+0100
+++ SDL-1.2.4/src/SDL_error.c 2002-08-12 04:52:53.000000000 +0100
@@ -47,7 +47,7 @@
#define SDL_GetErrBuf() (&SDL_global_error)
#endif /* DISABLE_THREADS */
-#ifdef CYGWIN
+#ifdef MINGW32
#define DISABLE_STDIO
#endif
— SDL-1.2.4/src/SDL_fatal.c.ORIGINAL 2002-08-12 04:53:31.000000000
+0100
+++ SDL-1.2.4/src/SDL_fatal.c 2002-08-12 04:53:34.000000000 +0100
@@ -51,7 +51,7 @@
#include “SDL.h”
#include “SDL_fatal.h”
-#ifdef CYGWIN
+#ifdef MINGW32
#define DISABLE_STDIO
#endif
(substituted so that only a windows native target gets disabled)
And a converse example…
— SDL-1.2.4/src/video/x11/SDL_x11gl.c.ORIGINAL 2002-08-12
08:17:14.000000000 +0100
+++ SDL-1.2.4/src/video/x11/SDL_x11gl.c 2002-08-12 08:18:30.000000000
+0100
@@ -34,7 +34,11 @@
#include “SDL_x11dga_c.h”
#include “SDL_x11gl_c.h”
-#define DEFAULT_OPENGL “libGL.so.1”
+#ifdef CYGWIN
+# define DEFAULT_OPENGL “libGL.dll”
+#else
+# define DEFAULT_OPENGL “libGL.so.1”
+#endif
…which may interest somebody because the rotating cube example does
work at a half-decent frame rate. ;-)On Wed, 21 Aug 2002 07:40:55 GMT, swamp-dog at ntlworld.com (Guy Harrison) wrote:
–
swamp-dog at ntlworld.com
I wonder is it possible for SDL_FreeSurface(SDL_Surface *surface)
to return an int value, 0 means it fails to (or didn’t) free the
surface, and 1 otherwise.
Sometimes I find surface->refcount quite handy to do some quick
hack. But this may not be a very valid reason for the API change.
It is up to Sam to decide.
Regards,
.paul.
er, 0 on success would be better, as you then can use the value to give
specific reasons for the failure (as 1 means you didn’t allocate this
surface, stupid!, and 2 means something else went wrong, 23 means the
illuminati still need the surface, so you can’t free it, etc)
My two cents,
KaiOn Wednesday 21 August 2002 16:16, paul at theV.net wrote:
I wonder is it possible for SDL_FreeSurface(SDL_Surface *surface)
to return an int value, 0 means it fails to (or didn’t) free the
surface, and 1 otherwise.
–
Kai Blin Linux system administrator Tel: Ring-86592
Allgemeine Chirurgie Universitaetsklinikum Tuebingen
I have discovered that all human evil comes from this, man’s being unable
to sit still in a room.
– Blaise Pascal
My point? Just that default compilation behaviour for cygwin is unix
whereas I notice SDL-1.2.4 targets mingw OOTB. This is unexpected and
undesirable because it’ll break any unix app trying to make use of
’sdl-config’.
Actually, I build SDL all the time with cygwin and no special parameters.
You’ll notice in configure.in:
# The Win32 platform requires special setup
SDL_CFLAGS="$SDL_CFLAGS -Dmain=SDL_main"
case "$target" in
*-*-cygwin*)
CFLAGS="$CFLAGS -I/usr/include/mingw -DWIN32 -Uunix -mno-cygwin"
SDL_CFLAGS="$SDL_CFLAGS -I/usr/include/mingw -DWIN32 -Uunix -mno-c
ygwin"
LIBS="$LIBS -mno-cygwin"
SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows -mno-cygwin"
;;
--mingw32*)
SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows"
;;
esac
See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
My point? Just that default compilation behaviour for cygwin is unix
whereas I notice SDL-1.2.4 targets mingw OOTB. This is unexpected and
undesirable because it’ll break any unix app trying to make use of
’sdl-config’.Actually, I build SDL all the time with cygwin and no special parameters.
You’ll notice in configure.in:# The Win32 platform requires special setup SDL_CFLAGS="$SDL_CFLAGS -Dmain=SDL_main" case "$target" in *-*-cygwin*) CFLAGS="$CFLAGS -I/usr/include/mingw -DWIN32 -Uunix -mno-cygwin" SDL_CFLAGS="$SDL_CFLAGS -I/usr/include/mingw -DWIN32 -Uunix -mno-cygwin"
LIBS="$LIBS -mno-cygwin"
SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows -mno-cygwin"
;;
--mingw32*)
SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows"
;;
esac
Yep, I saw it. The only way I can get a cygwin/X build is to tell
configure that I’m linux! Surely that’s gotta be suspect? I did some
thinking after my last post so if you’ve a moment, give this a blast…
CC=“gcc -mno-cygwin” configure --target=i686-pc-mingw32
Builds just fine. Default installation prefix looks wrong
(/usr/local/cross-tools/i386-mingw32msvc) but that’s just a detail.
Notice the CYGWIN checks in SDL_fatal/SDL_error/SDL_syswm are
completely redundant: no requirement to substitute MINGW32. Just
wipe those checks in the code. Ditto for ‘configure’ to a large extent.
I reckon even that long configure line can be dispensed with:
That should leave things transparent - cygwin users still get a mingw
target OOTB but if someone like me comes along we can be told to
use…
configure --target=i686-pc-cygwin
…and get our Cygwin/XFree86 build. Moreover it also leaves the
possibility to have twin installations under cygwin: the windows one sat
in the mingw hierarchy and the X one sat in /usr/local. You could link
against the opposite SDL GUI for porting purposes. Even with cygwin/X
currently crippled it isn’t as daft as it first appears. ;-)On Wed, 21 Aug 2002 08:12:09 -0700, Sam Lantinga wrote:
–
swamp-dog at ntlworld.com
[snipped]
…and get our Cygwin/XFree86 build. Moreover it also leaves the
possibility to have twin installations under cygwin: the windows one sat
in the mingw hierarchy and the X one sat in /usr/local. You could link
against the opposite SDL GUI for porting purposes. Even with cygwin/X
currently crippled it isn’t as daft as it first appears.
Uh… okay…
I think I’ll leave it the way it is now, and you can send me a completely
perfect configure.in and patch at some point for me to play with.
Heheh,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
[snipped]
…and get our Cygwin/XFree86 build. Moreover it also leaves the
possibility to have twin installations under cygwin: the windows one sat
in the mingw hierarchy and the X one sat in /usr/local. You could link
against the opposite SDL GUI for porting purposes. Even with cygwin/X
currently crippled it isn’t as daft as it first appears.Uh… okay…
I think I’ll leave it the way it is now, and you can send me a completely
perfect configure.in and patch at some point for me to play with.
Okidoki. I might just do that. On Wed, 21 Aug 2002 23:30:16 -0700, Sam Lantinga wrote:
–
swamp-dog at ntlworld.com
Hi Ryan,
Ryan C. Gordon wrote:
It would probably be valuable to have these more closely maintained with
the SDL sources (in cvs, even?) … otherwise users will likely find they
are bound to whatever prepackaged SDL comes with C++ Builder (being
1.2.4, it’s about to become obsolete, too). If Borland is actively
maintaining those project files, though, that’s cool.
Just to clarify, Borland are not maintaining it ( not yet anyway ).
It was something I did in order to try and give SDL a bit more exposure.
If something ships out of the box people are more likely to play around
with it than if they have to go searching for it on the internet.
I also agree that it should be part of CVS and I have recently sent Sam
updates to the BorlandC.html file.
BTW Borland have just released the Open Edition of Kylix 3 ( 300MB and
comes with C++ Builder for Linux and Delphi for Linux ). This allows you
to create GPLed software at the price of a big download. If anyone is
curious about their C++ compiler and you can handle the download, this
may be a way of see what they have to offer.
PS. I am not employed by Borland. I just like alternatives.
L8R,
Dominique.–
http://www.DelphiGamer.com := for all your Object Pascal game
development needs;
http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME := Home of JEDI-SDL;
Cross-platform game development with Pascal, has never been easier.
Thanks, this is fixed in CVS.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Mon, 2002-08-19 at 00:02, Sam Lantinga wrote:
I’m gearing up to release SDL 1.2.5
Are there any outstanding bugs that need to be fixed, which have not
been fixed in the CVS code: http://www.libsdl.org/cvs.php
Are you going to release new versions of the libraries you maintain too?
If so, the bug in SDLNet_UDP_Bind I told you about earlier is still not
fixed in CVS. For reminder, the 2nd SDLNET_MAX_UDPCHANNELS in that
function has to be changed to SDLNET_MAX_UDPADDRESSES…