After much more carefully observing this in the debugger I realized
this was my own fault after all. I had mindlessly declared one of my Surface
objects as a global, failing to realize this would cause its destructor to
be invoked well after SDL_Quit was already called.
Commands :
fuser /dev/dsp
strace aProgram
lsof list open files
In X environment, even the surface is initialized as 800x600 or 1024x768 or whatever without SDL_FULLSCREEN flag, it gives me "Full screen mode" surrounded by black strip. After several testing, I realize the resolution of the screen is that I specify in lilo but not the resolution in X.
Sounds like you have an SDL lib without X support, or maybe that it can't find or access X for some reason. Some distros configure X to refuse connections from local root.
Check that your XFree86/Xorg.conf has a configuration for your desired video resolution, SDL will behave as you described if it can not set the desired video mode or it will choose a video mode from your X config that's close enough to the desired video res and draw black around your screen surface. You can read more about it on John Hall's "Programming Linux Games" book, on his web server
(http://www.overcode.net)
Use xprop to have informations about an X window
Setting sdl program's niceness to -20 and running it as root may not help
The drivers you are using.
The compatibility between your driver and the OS you
are running.
What you are trying to do 'behind the scenes' (what
you do between one frame and the next one).
What kind of video card you are using.
What kind of video features you are using (i.e.: try
to use some OpenGL opperations that requires real
video card support on a non-accellerated video card.
The size of your screen.
The amount of memory avaliable to the app.
With Cygwin :
Some nasm problems, changedir to the ./src/hermes, type "make clean" then
type "make" and show the stdout output, how hermes is compiling.
Or disable the MMX accel, run configure with --disable-nasm option.
but I meet errors when linking and this is the error message:
gcc -shared .libs/SDL.o .libs/SDL_error.o .libs/SDL_fatal.o .libs/SDL_getenv.o
.libs/SDL_loadso.o -Wl,--whole-archive main/.libs/libarch.a audio/.libs/libaudio
.a video/.libs/libvideo.a events/.libs/libevents.a joystick/.libs/libjoystick.a
cdrom/.libs/libcdrom.a thread/.libs/libthread.a timer/.libs/libtimer.a endian/.l
ibs/libendian.a file/.libs/libfile.a cpuinfo/.libs/libcpuinfo.a hermes/.libs/lib
hermes.a -Wl,--no-whole-archive -luser32 -lgdi32 -lwinmm -mno-cygwin -mno-cygw
in -o .libs/SDL.dll -Wl,--enable-auto-image-base -Wl,--out-implib,.libs/libSDL.d
ll.a
Creating library file: .libs/libSDL.dll.a
/usr/lib/gcc-lib/i686-pc-mingw32/3.3.1/../../../../i686-pc-mingw32/bin/ld: herme
s/.libs/libhermes.a(mmxp2_32.o): bad reloc address 0x87 in section `.text'
collect2: ld returned 1 exit status
make[2]: *** [libSDL.la] Error 1
Some nasm problems, changedir to the ./src/hermes, type "make clean" then
type "make" and show the stdout output, how hermes is compiling.
Or disable the MMX accel, run configure with --disable-nasm option.
When executing two applications making use of SDL_CreateYUVOverlay, the second window is dark and blank
SDL uses XVideo for YUV overlays on the screen, but most cards cannot handle more than one application which uses XVideo. You can either set environment variable SDL_VIDEO_YUV_HWACCEL to 1 or use non-screen surfaces as destination for overlays. Notice than anyway you will get some slowdown.
I get the following message : Xlib : extension "XFree86-DRI" missing on display ":0.0".
You do not seem to have 3D acceleration correctly setup. You should load
the dri module in your X configuration file.
My game runs 1/2 speed on 32 bit window desktops
If you are comparing to 16 bit modes, it's quite obvious: Going to 32
bits with the same resolution means twice as much data to move around - and blitting to the screen (VRAM access with the CPU) is usually the major bottleneck, and takes the full impact of such changes.
what X version are you using (please send the output of xdpyinfo)
Cannot compile SDL with gcc < 3.1 : SDL_yuv_mmx.c has a special declaration of names for assembly parameters, which is only available as of gcc 3.1
SDL_FreeSurface(screenSurface);
Don't ever do that.
If I start it from shell, the program works fine but if I try to do the same from a graphical tool ot fails, or a window appears but nothing aopears in it, etc.
You are probably using relative paths for your data, which work in the
console because you have to be in the right folder to run the program,
but do not work in the file browser which doesn't set up the path.
Problem with : tile = SDL_LoadBMP("D:\Pyro\img\brick.bmp");
You have to make sure to escape the backslashes like this:
tile = SDL_LoadBMP("D:\\Pyro\\img\\brick.bmp");
or this will usually work as well:
tile = SDL_LoadBMP("D:/Pyro/img/brick.bmp");
otherwise it'll think you are trying to use the string escape sequence \P, \i, \b.
The Windows version of my game runs faster than the Linux one :
Could be lots of different reasons. You need to tell us the specs of the
the two computers. You need to tell us the specs of the video cards. You
need to tell us if you are using OpenGL or not. The most likely reasons
(IMHO) are
1) The Linux computer is half the speed of the windows computer.
2) The pixels in your art are all X bits wide, which happens to be the
same as a video mode supported by the video card on the windows computer
but not on the Linux computer. If the depth you ask for is not supported
by the video card on your computer SDL gives you a fake buffer and then
converts the pixels to something the card does support at run time. So,
the program works, but slowly.
3) You are *not* using OpenGL, but only SDL's blit functions. Those
functions are (usually) hardware accelerated on Windows and are
(usually) not hardware accelerated on Linux.
4) You *are* using OpenGL and you have a very nice video card in the
windows computer and a relatively crappy one in the Linux computer.
5) You have a lot more memory in the windows computer than you do in the
Linux computer.
And there are even more possible reasons.
I noticed SDL_ttf was crashing
with a segfault when the filename TTF_OpenFont(char*) expects does not
exist.
Sometimes, not ALL the time, but sometimes, when i go to
click and drag the window (you know, when you "grab" the top bar of
the window to move the window around?) - i can't do it.
I've had the same problem with my OpenGL game and SDL 1.2.7.
SDL 1.2.6 doesn't have this problem, so I'm still using it.
Also with SDL 1.2.7 the window disappears in some conditions (after
alt-tabbing from fullscreen IIRC).
Using DevC++, I added -lSDL_image to the linker parameters. Now I am
getting the error message "cannot find -lSDL_image" when I try to
compile and link my application.
I installed the SDL_image 1.2.3 devpak from devpaks.org which copied the
necessary .a, .dll and .h files within the respective directories.
What's wrong here?
You may want to take a look here: http://www.gamedev.net/community/forums/topic.asp?topic_id=285721
I tried to change my code to use an SDL Timer. Sometimes it works for a little, but it always ends up locking up
and Not Responding. It stops drawing, the screen turns white, and I
get an hourglass. What's weird, I can still quit the game by hitting
escape, which is an event which calls Quit(0);
I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one 'thread' is trying to write to the
video surface.
My questions are 1) do SDL_Timers create there own 'threads'? 2) is
there a way to detect if the display surface is locked so as not to try
and draw the graphic? And 3) this doesn't appear to happen when I use
the hardware surfaces, why?
mcop warning: user defined signal handler found for SIG_PIPE, overriding.
Unable to resolve pcwks123.miel.mot.com...
but, earlier I got the same message with some other tag, not "unable to resolve". But, this message of SIG_PIPE is consistently coming, though the sound is being played properly.
SDL uses arts (the kde sound daemon) on your machine.
A solution is to switch to another audio driver :
export SDL_AUDIODRIVER=esd
export SDL_AUDIODRIVER=dsp
export SDL_AUDIODRIVER=alsa
...
Refer to the docs :
http://sdldoc.csn.ul.ie/sdlenvvars.php
Here's how to get a backtrace :
http://www.libsdl.org/cgi/docwiki.cgi/FAQ_20Getting_20a_20backtrace
Unexpected async reply message, because more then one thread is trying to write to the
video surface.
SDL_Timers may create there own 'threads', depending on the underlying OS. In general you MUST NOT do
graphics in a timer callback function.
Humm... When building with nasm, I get the error:
Creating library file: .libs/libSDL.dll.a
c:\MinGW\bin\..\lib\gcc-lib\mingw32\3.3.1\..\..\..\..\mingw32\bin\ld.exe:
hermes/.libs/libhermes.a(mmxp2_32.o): bad reloc address 0x87 in section
`.text'
Any idea?
Go to google, find the answer in the SDL archives.
Basically there is a bug in your version of binutils. Upgrade/downgrade it.
Xlib: unexpected async reply(0x190)
Got such an error message recently when trying to run plaympeg (which
comes with the smpeg package). I solved it by setting the following
environment variable:
export XLIB_SKIP_ARGB_VISUALS=1
Everything works perfectly in windowed mode, but when I switch to fullscreen video,
it looks like my SDL surface takes only upper half of the screen. The
bottom half stays black (I can only go there with my mouse cursor, which
leaves there it's track).
I've seen this problem before when setting "odd" video modes (like once i set
50x50 to see what would happen).
what's happening is that for some reason, SDL is unable or unwilling to get
a 320x240x8 bits screen, so it's getting a bigger screen than you requested,
but the size you requested is there, it's just in the upper left (or just
upper) part of the screen.
Other probable reason could be that the monitor geometry isn't setup for
such modes, since "nobody" uses them anymore.
Does SDL's event system work properly on linux/win32 textmode console?
My app doesn't receive any keyboard events when running in console mode...
Yes, you need to setup a video mode to get keyboards events. But this
can be an ascii video mode so you can try to use the ascii art rendering
backend :
export SDL_VIDEODRIVER=aalib
I'm sure it depends on what you're doing and the platform you're
using, but when I tested the aalib backend with my app, the keyboard
functions didn't behave very well.
I don't think it's a well-tested backend.
unexpected crash of executable when i try to switch to fullscreen mode on windows with a linux application compiled with Mingw.
This is usually caused by not locking surfaces properly before doing pixel
accesses on them.
It happens because you are using Windows and Windows wipes out all your
GL context when you change the video mode. This has nothing to do with
SDL, it is just the way MS decided to implement GL on Windows.
If I were you, I would complain to MS, and then rewrite your code to
reload your textures after you change the video mode.
Some additional notes regarding this case, if you don't want to reload
your textures unless it really is necessary.
If you want to switch between fullscreen and windowed mode, you will of
course need to call SDL_SetVideoMode. But you can check with
SDL_VideoDriverName if you're using the x11 driver, and in such cases skip
the initialization.
If you receive a SDL_VIDEORESIZE event, you have to call SDL_SetVideoMode
according to the docs, I think. But at least at the moment, you don't
really need that call on Windows (the same goes for OS X), just remember
to update your GL viewport. Using the x11 driver, you have to call
SDL_SetVideoMode, but you don't need to reload the textures and
reinitialize the GL context again.
Of course, this makes your code ugly, and this kind of OS dependant checks
should be avoided. But if you really want your app to do as little
unneccessary texture reloading as possible, using the current version of
SDL, this is how it works as far as I've seen.
An event which tells whether the GL context was lost would of course be
the best solution.
Errors Exiting SDL on Windows
the problem was that i was using Microsoft Visual
Studio.NET and a tutorial i read said to choose a Win32 Windows
Application and not a Win32 Console Application.
The exact problem was that somehow, atexit() was getting passed a NULL pointer
somewhere (thus why it crashes when exit() is called
I found that if I disabled the Parachute (SDL_Init(SDL_INIT_NO_PARACHUTE)
or something like that), the crash stopped hapening. Try that out.
If that doesn't help, I'd sugest compiling your application with MinGW or
Cygwin -- I never had that problem occur with either of those
Q: I have an accelerated video card, but SDL tells me that that I have zero video memory and no acceleration!
A: Not all display targets can make use of hardware acceleration. In particular, this is the case for the X11 target which always presents you with a software framebuffer. Your video memory will always be reported to be zero if no acceleration is available.
Note that this has nothing to do with 3D acceleration, just 2D hardware acceleration support in the underlying operating system video drivers.
If you want hardware acceleration on Linux, you can use the DGA driver (fullscreen-only, under X11) or the framebuffer console driver (fullscreen-only, under the console). See the Linux FAQ for more information on using these drivers.
If you want hardware acceleration on Windows, make sure SDL is built with DirectX support and run your program in fullscreen mode.
An excellent article by Bob Pendleton covering SDL hardware surfaces is available at the O'Reilly Network
Could you send us an strace of a program running and crashing ? strace
myprogram will do.
SDL_INIT_EVENTTHREAD : The source code does seem to say that it isn't supported on all
operating systems:
./include/SDL.h:#define SDL_INIT_EVENTTHREAD 0x01000000 /* Not supported on all OS's */
I know that I've released game snapshots which defaulted to the maximum
refresh that Windows thought was supported, and received bug reports of
people's monitors being desynced. I may revisit it at some point, using 70
or 72Hz instead of the maximum.
Causes might be : you don't call SDL_UpdateRects/SDL_Flip, or you assume no surface locking is
needed
Try the following :
export SDL_DSP_NOSELECT=1
It seems that the via82xx driver is buggy, and SDL doesn't detect it (anyone has an idea how we could find this and automate this workaround ?).
Test your code on another OS, perhaps it's not a problem relative to your platform at
all.
3) Test an application that does what YOU are trying to do, and see if
it has a problem on your system. If it doesn't, again, you may have
made a simple mistake in your code.
it sounds like you need to redraw everything to the screen when you detect
that your app has become active again
I don't use the framebuffer device in Linux because it doesn't work
correctly. It's very unstable, have many kernel panics, problems with
screen.
I'm getting linker errors on several applications (audacity, jasper, and
others). The message is:
/usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
Anyone know what this cryptic message means?
So, it seems you upgraded gcc but not ld and binutils ? You should upgrade those two I think.
if you don't provide the correct arguments to your main
routine's function definition, it won't be replaced by
SDL's macro. Using "main(int argc, char **argv)" is
the best thing to do.
In win32 if I run fullscreen, the windows cursor dissapears, while windowed apps keep the cursor.
Many systems don't actually give you full video
hardware priveleges in windowed mode, otherwise you'd
be rendering all over other screens. In most systems
this means you're rendering occurs on a seperate
surface which eventually gets included in the final
screen image by the window composition element of your
system. The mouse cursor is drawn by the window
composition system.
Whenever you are in full screen, the window
composition system no longer needs to do anything, so
it relinquishes full video control to your
application. During this time, the window composition
system usually ceases to draw any sort of cursor for
you.
where do I set the path for shared libs? I tried a demo and
it said it couldn't find the shared lib libSDL-1-1.so.O, so I guess
make install must have put them in a place different from my
installation.
you just need to run ldconfig, to update the database for the
runtime linker. If you installed SDL from source, then the shared
library is probably in /usr/local/lib. Make sure this directory is
included in /etc/ld.so.conf so that ldconfig can find it. See the
documentation for the runtime linker (ld.so) for more information.
More likely, it's binary file is quite old and links to a specific
version of SDL (here SDL 1.1).
To see if the binary links to a specific version of SDL, do :
ldd ./mybinary
if it says something like :
libSDL-1.1.so.0 => /usr/lib/libSDL-1.1.so.0
that's the cause of the problem.
If you can't recompile it, the easiest fix is to create a symlink :
cd /usr/lib
ln -s libSDL-1.2.so.0 libSDL-1.1.so
Under Linux : Unable to init SDL: No available video device
Are you running it as the same user that is running X ? Are you
compiling with `sdl-config --cflags --libs` ?
That message means your SDL install is not configured with support for
your current setup, or you are forcing the backend by using the
SDL_VIDEODRIVER env variable. So :
- did you do the ./configure ; install yourself for SDL, or is this a
packaged version ? If it is packaged, which version is it ?
- does "echo $SDL_VIDEODRIVER" say something ?
About XFree86's failure to ungrab the mouse
if an app compiled without the SDL parachute crashes. I just noticed
the following in the XFree86 man page that might be useful:
Ctrl+Alt+KeypadMultiply
Not treated specially by default. If the AllowClose-
downGrabs XF86Config-4(5x) file option is specified,
this key sequence kills clients with an active key-
board or mouse grab as well as killing any applica-
tion that may have locked the server, normally using
the XGrabServer(3x) Xlib function.
Ctrl+Alt+KeypadDivide
Not treated specially by default. If the AllowDeac-
tivateGrabs XF86Config-4(5x) file option is speci-
fied, this key sequence deactivates any active key-
board and mouse grabs.
In short, its a bug in XFree86. It should watch if the connection that
mouse grabbed fails, and then ungrab. The (absurd) fix is to start an
app that mouse grabs, and then quite again; this forces XFree86 to
ungrab.
I met a error like this when change resolution by using SDL_SetVideoMode.
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 19 (X_DeleteProperty)
Atom id in failed request: 0x2a00003
Serial number of failed request: 89
Current serial number in output stream: 92
what this error mean?
You're probably drawing outside your window bounds. Check your
SDL_UpdateRects call
Under Windows, some odd compilation problems such as redefinitions of symbols occur
Try adding #include <windows.h> at the top of the file... it's a "magic bullet" in Windows. However the most portable solution is probably to replace :
#include
#include
#include
#include "SDL.h"
#include "SDL_opengl.h"
SDL_opengl.h already includes windows.h under Windows, unless you want to use
glut.h, glaux.h, etc. which SDL_opengl.h does not include. Using no SDL or GL directory prefix for the includes is the most portable way, since on Mac, for example, the prefix would be OpenGL instead of GL. The path to these files is to be handled by sdl-config.
As a workaround, I'm using
_Exit() (new in C99), which skips the atexit() callbacks. Not pretty, but I
can live with it!
You might try updating your video drivers, I've heard the ones that come
with XP make GL run slow (maybe so directx apears to be the better
solution?) and maybe they put in bugs too..who knows.
Have you tried on several PCs? It might be a driver-related problem. My
SDL 1.2.6 game crashes like that during the SDL_SetVideoMode() call
with the drivers that were supplied with my Radeon 9200 SE. It works
fine after updating the drivers.
Yes, of course! Didn't notice the "magic" 80 fps value, which sounds
very much like a sensible refresh rate for 800x600.
Try removing the SDL_DOUBLEBUF flag, and/or run the app in windowed
mode. One or both will eliminate retrace sync on most targets.
Now, note that this is just for testing. Retrace sync is a Very Good
Thing. It allows you to get the smoothest animation without wasting
CPU and/or GPU power.
if you set the colorkey or the alpha flag, the bpp
can be changed on the surface in favor of the video bpp if the video
driver supports colorkey or alpha blits in h/w. That's not documented
but causes bug on some programs
this sounds errily similar to a problem I was having when using
VC++7. Try passing the SDL_INIT_NOPARACHUTE flag to your SDL_Init() call --
thats how I "fixed" it in VC++7 (Actually, I've found several different
"bugs" that are somehow fixed by disabling the parachute; so much so that
it's now in every SDL app I write -- perhaps there's a bug in the VC++ code
for the parachute?).
For the flicker problem, are you seeing "white flashes" on the screen ?
Maybe you just loose frames in windowed mode, which is not surprising
if you redraw the whole screen.
Yes this is the normal behavior. In windowed mode you can't do a flip
synch'ed with the monitor refresh, so when you update the framebuffer
in memory (SDL_UpdateRect) the video card may be drawing on the screen.
That's why you see on the upper part your old blue and on the lower part
the new one.
bash-2.05b# which sdl-config
/usr/bin/sdl-config
bash-2.05b# sdl-config --version
1.2.6
bash-2.05b# locate libSDL
warning: locate: warning: database /var/lib/slocate/slocate.db' is more =
than 8 days old
bash-2.05b# tail config.log
tail: config.log: No such file or directory
Please help me if you can. Oh yeah, in my /etc/ld.so.conf there is the =
line /usr/local/lib already. Thanks
if the program is running in fullscreen mode and the user
> hits the windows key or tries to alt-tab (Etc), my program crashes.
Look at the doc for SDL_BlitSurface :
http://sdldoc.csn.ul.ie/sdlblitsurface.php
and notice the special "-2" return value that happens "under DirectX 5.0
when the system switches away from your fullscreen application
If the configure script tells you it can't find the lib, although it
exists, check if you have installed the developer packages and if that
doesn't help, have a look at the options with ./configure --help.
The problem was that I was treating a surface's pixels as a char* when actually the
pointer type depends on the pixel format.
i'm using a full screen jpg background with bmp sprites and the when i run it, the mouse (that i can't use) flicks over the screen
This is listed in the BUGS file:
When the implementation is writing directly to video memory the mouse
cursor doesn't work properly. Applications which do this should use
their own mouse cursor and call SDL_ShowCursor(0) to hide the system
cursor.
>I am using SDL 1.2.6. I have installed it correctly. Under X-Window, The
>> examples run ok.But Under framebuffer console, the mouse is displayed on
>> the left-top corner, and can't move.
>> I stop gpm and start with -R option. Then the mouse jumps on the scre=
en
>> and back to the left-top corner, and so on.
>> How to do?
>>
Have you tried setting SDL_MOUSEDEV_IMPS2=3D1 in your environment?
If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!