Simple Directmedia Layer, 1.2 branch ... ***DEPRECATED***, please use https://github.com/libsdl-org/SDL for new projects!

Related tags

Game sdl
Overview

DEPRECATED

The 1.2 branch of SDL is deprecated. While we occasionally collect fixes in revision control, there has not been a formal release since 2012, and we have no intention to do future releases, either.

Current development is happening in SDL 2.0.x, which gets regular releases and can be found at:

https://github.com/libsdl-org/SDL

Thanks!

Simple DirectMedia Layer (SDL) Version 1.2

https://www.libsdl.org/

This is the Simple DirectMedia Layer, a general API that provides low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D framebuffer across multiple platforms.

The current version supports Linux, Windows CE/95/98/ME/XP/Vista, BeOS, MacOS Classic, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, Nintendo DS, and OS/2, but these are not officially supported.

SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, and Smalltalk.

This library is distributed under GNU LGPL version 2, which can be found in the file "COPYING". This license allows you to use SDL freely in commercial programs as long as you link with the dynamic library.

The best way to learn how to use SDL is to check out the header files in the "include" subdirectory and the programs in the "test" subdirectory. The header files and test programs are well commented and always up to date. More documentation is available in HTML format in "docs/index.html".

The test programs in the "test" subdirectory are in the public domain.

Enjoy!

Sam Lantinga ([email protected])

Comments
  • fbdev: Triple-buffering

    fbdev: Triple-buffering

    This bug report was migrated from our old Bugzilla tracker.

    These attachments are available in the static archive:

    Reported in version: HG 1.2 Reported for operating system, platform: Linux, All

    Comments on the original bug report:

    On 2020-01-13 18:20:39 +0000, Paul Cercueil wrote:

    Created attachment 4164 Patch to fix the issue

    From the patch:

    "Implement triple-buffering using a dedicated thread which will wait on VSYNC and then flip the two back buffers."

    On 2020-09-22 02:11:12 +0000, Ozkan Sezer wrote:

    The patch is in. Thanks. http://hg.libsdl.org/SDL/rev/3dfb9493a246

    enhancement 
    opened by SDLBugzilla 14
  • Interoperability between SDL1.2 apps and SDL2 plugins on macOS

    Interoperability between SDL1.2 apps and SDL2 plugins on macOS

    The patch enables retrievable info->nsWindowPtr type from SDL_GetWMInfo() to enable foreign window conversion in SDL2 plugins. Fixed class collision warning on SDLTranslatorResponder when both SDL1.2 and SDL2 dylib are loaded at the same time.

    sha256sum 26d450371967cce1bd169c46cdedee1e98d2acd07dd14d1a25ee2aa7c2655779 0005-GetWMInfo.txt

    opened by kjliew 8
  • [WINCE] Cannot rotate screen Portrait<->Landscape

    [WINCE] Cannot rotate screen Portrait<->Landscape

    From README.Wince, we can read this information:

    - Landscape mode and automatic rotation of buttons and stylus coordinates.
      To enable landscape mode make width of video screen bigger than height.
      For example: 
        SDL_SetVideoMode(320,240,16,SDL_FULLSCREEN)
    

    However, this does not seem to be true, at least with the source into the repo at the time of writing. Making Width > Height does not rotate the screen. I don't know if:

    • this is a bug
    • it is something unimplemented.
    • it is something removed from the code in the past
    • or it not expected to be done in this way

    ...but at the moment the library does not change from portrait to landscape when you follow the instructions written into the readme file. Instead, if you create a 320x240 screen on a 240x320 device, it simply overflows the space on the display.

    VirtualBox_windows xp_26_08_2021_19_53_33

    opened by carlo-bramini 8
  • DirectFB causes apps to crash.

    DirectFB causes apps to crash.

    I'm still trying to work out the root cause of this but this is what I have so far:

    • DirectFB itself works fine, the native DirectFB demos work on the targets (armhf and amd64)
    • The apps seem to be OK as they work when using the fbdev backend
    • The apps seem to crash because they are getting a null pointer for the framebuffer, they seem to get a workable address at some point because you can see stuff getting drawn to the screen
    • The problem seems to come right after the framebuffer mode is getting changed.

    FWIW: I know SDL1 is dead, DirectFB was basically dead too (it's recently been forked and getting some love again), the target platform can only run SDL2 with the DirectFB backend because it doesn't have a GPU to run the KMSDRM backend. I also want to run some SDL1 apps that haven't been ported... so getting the DirectFB backend working is the easiest route to having both SDL2 and SDL1 working on this machine.

    endoflife 
    opened by fifteenhex 7
  • SDL doesn't render anything on MacOSX 11.5.1

    SDL doesn't render anything on MacOSX 11.5.1

    environment

    SDL: 1.2.15 gcc: Apple clang version 13.0.0 (clang-1300.0.29.3)

    SDL doesn't render anything on MacOSX 11.5.1.

    I confirm that the picture exists.

    expect: render hello.bmp

    result: nothing

    image

    code: src/window.c

    #include <SDL/SDL.h>
    
    #undef main
    int main(int argc, char *argv[])
    {
      SDL_bool quit = SDL_FALSE;
      SDL_Event event;
      SDL_Init(SDL_INIT_EVERYTHING);
    
      SDL_Rect rect = {0, 0, 100, 100};
      
      SDL_Surface* window = SDL_SetVideoMode(480, 480, 32, SDL_SWSURFACE);
      SDL_Surface* hello = SDL_LoadBMP("../preview2.bmp");
      if (hello == NULL) {
        printf("read bmp error\n");
      }
      SDL_BlitSurface(hello, NULL, window, NULL);
      SDL_WM_SetCaption("hello sdl", "logo.png");
      SDL_Flip(window);
    
      while (!quit)
      {
        while (SDL_PollEvent(&event))
        {
          if (event.type == SDL_QUIT) {
            quit = SDL_TRUE;
          }
        }
      }
      
      SDL_FreeSurface(hello);
      SDL_Quit();
      return 0;
    }
    

    CMakeLists.txt

    cmake_minimum_required(VERSION 3.5)
    set(project_name sdl-demo)
    project(${project_name})
    
    add_executable(${project_name} src/window.c)
    target_include_directories(${project_name} PUBLIC ~/Library/SDL ~/Library)
    
    target_link_libraries(${project_name} /Users/lan/Library/SDL/SDL)
    
    opened by LanFly 6
  • [WINDIB vs. Windows 8+] SDL_SetVideoMode fails (freezes)

    [WINDIB vs. Windows 8+] SDL_SetVideoMode fails (freezes)

    Calling SDL_SetVideoMode with (640, 480, 0, SDL_FULLSCREEN) freezes the application on Windows 8.1 with windib video driver.

    The reason is ChangeDisplaySettingsA does not return on line 763 in SDL_dibvideo.c . Tried add CDS_TEST to the flags and that seems to work, but as soon as the display would be changed the function does not return. Without SDL_FULLSCREEN the application runs just fine too.

    According to Microsoft, the minimum resolution of the applications is 1024x768 from Windows 8+. It seems that they forgot to update ChangeDisplaySettingsA to reflect on this new requirement.

    Apparently they dropped this requirement in Windows 10...

    wontfix 
    opened by pionere 5
  • SDL 1.2 programs crash with certain libGL implementations

    SDL 1.2 programs crash with certain libGL implementations

    This bug report was migrated from our old Bugzilla tracker.

    Reported in version: 1.2.15 Reported for operating system, platform: Linux, x86_64

    Comments on the original bug report:

    On 2015-01-12 12:02:20 +0000, Petr Pisar wrote:

    This is a bug report regarding not calling XInitThreads(). Especially if underlying OpenGL implementation uses threads. It's copied from a Fedora bug report https://bugzilla.redhat.com/show_bug.cgi?id=1181085:

    Some libGL implementations call XInitThreads() on dlopen. For example, the latest nVidia proprietary implementation does it, probably because it needs to use threads for performance. This causes applications that use SDL 1.2 to crash.

    From XInitThreads(3):

    The XInitThreads function initializes Xlib support for concurrent threads. This function must be the first Xlib function a multi-threaded program calls, and it must complete before any other Xlib call is made.

    From https://wiki.libsdl.org/SDL_GL_LoadLibrary:

    This should be done after initializing the video driver, but before creating any OpenGL windows. If no OpenGL library is loaded, the default library will be loaded upon creation of the first OpenGL window.

    But SDL_VideoInit() calls XOpenDisplay() and nVidia libGL implementation calls XInitThreads() on dlopen:

    	(gdb) break XInitThreads
    	Function "XInitThreads" not defined.
    	Make breakpoint pending on future shared library load? (y or [n]) y
    	Breakpoint 1 (XInitThreads) pending.
    	(gdb) run
    	Starting program: /mnt/data/home/woky/src/xonotic/darkplaces/darkplaces-sdl 
    	[Thread debugging using libthread_db enabled]
    	Using host libthread_db library "/lib64/libthread_db.so.1".
    	Game is DarkPlaces-Quake using base gamedir id1
    	gamename for server filtering: DarkPlaces-Quake
    	DarkPlaces-Quake Linux 18:50:26 Jan 11 2015 - debug
    	Current nice level is below the soft limit - cannot use niceness
    	Playing shareware version.
    	Skeletal animation uses SSE code path
    	DPSOFTRAST available (SSE2 instructions detected)
    	Failed to init SDL joystick subsystem: 
    	couldn't exec quake.rc
    	couldn't exec default.cfg
    	execing config.cfg
    	couldn't exec autoexec.cfg
    	Client using an automatically assigned port
    	Client opened a socket on address 0.0.0.0:0
    	Linked against SDL version 1.2.15
    	Using SDL library version 1.2.15
    
    	Breakpoint 1, XInitThreads () at locking.c:573
    	573	{
    	(gdb) thread apply all bt
    
    	Thread 1 (Thread 0x7ffff7fcc700 (LWP 8884)):
    	# 0  XInitThreads () at locking.c:573
    	# 1  0x00007fffea173136 in ?? () from /usr/lib64/nvidia/libGL.so.1
    	# 2  0x00007fffea1956cd in ?? () from /usr/lib64/nvidia/libGL.so.1
    	# 3  0x00007fffea173b9d in ?? () from /usr/lib64/nvidia/libGL.so.1
    	# 4  0x00007ffff7deaf0d in call_init (l=0x2923d80, [email protected]=1, [email protected]=0x7fffffffe038, [email protected]=0x7fffffffe048) at dl-init.c:62
    	# 5  0x00007ffff7deb05b in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:34
    	# 6  _dl_init ([email protected]=0x2923d80, argc=1, argv=0x7fffffffe038, env=0x7fffffffe048) at dl-init.c:124
    	# 7  0x00007ffff7defa51 in dl_open_worker ([email protected]=0x7fffffffcdc8) at dl-open.c:566
    	# 8  0x00007ffff7deadf4 in _dl_catch_error ([email protected]=0x7fffffffcdb8, [email protected]=0x7fffffffcdc0, [email protected]=0x7fffffffcdb7, 
    			[email protected]=0x7ffff7def590 <dl_open_worker>, [email protected]=0x7fffffffcdc8) at dl-error.c:187
    	# 9  0x00007ffff7deeee3 in _dl_open (file=0x7ffff701a7b6 "libGL.so.1", mode=-2147483390, caller_dlopen=0x7ffff6ff968b <X11_GL_LoadLibrary+59>, nsid=-2, argc=<optimized out>, 
    			argv=<optimized out>, env=0x7fffffffe048) at dl-open.c:650
    	# 10 0x00007ffff725c039 in dlopen_doit ([email protected]=0x7fffffffcfe0) at dlopen.c:66
    	# 11 0x00007ffff7deadf4 in _dl_catch_error (objname=0x292d090, errstring=0x292d098, mallocedp=0x292d088, operate=0x7ffff725bfe0 <dlopen_doit>, args=0x7fffffffcfe0) at dl-error.c:187
    	# 12 0x00007ffff725c69d in _dlerror_run ([email protected]=0x7ffff725bfe0 <dlopen_doit>, [email protected]=0x7fffffffcfe0) at dlerror.c:163
    	# 13 0x00007ffff725c0d1 in __dlopen ([email protected]=0x7ffff701a7b6 "libGL.so.1", [email protected]=258) at dlopen.c:87
    	# 14 0x00007ffff6ff968b in X11_GL_LoadLibrary (this=0x2975760, path=0x7ffff701a7b6 "libGL.so.1") at src/video/x11/SDL_x11gl.c:506
    	# 15 0x0000000000409616 in VID_InitModeGL (mode=0x7fffffffd4e0) at ../../../vid_sdl.c:2461
    	# 16 0x0000000000409cdf in VID_InitMode (mode=0x7fffffffd4e0) at ../../../vid_sdl.c:2758
    	# 17 0x00000000006fdbfd in VID_Mode (fullscreen=1, width=640, height=480, bpp=32, refreshrate=60, stereobuffer=0, samples=1) at ../../../vid_shared.c:1857
    	# 18 0x00000000006fe4e5 in VID_Start () at ../../../vid_shared.c:2022
    	# 19 0x000000000057400c in Host_StartVideo () at ../../../host.c:1088
    	# 20 0x000000000047ad16 in SCR_BeginLoadingPlaque (startup=true) at ../../../cl_screen.c:761
    	# 21 0x000000000057454b in Host_Init () at ../../../host.c:1324
    	# 22 0x0000000000572d99 in Host_Main () at ../../../host.c:679
    	# 23 0x000000000040444e in main (argc=1, argv=0x7fffffffe038) at ../../../sys_sdl.c:223
    

    So if a program is written according to the SDL docs and runs with nVidia libGL implementation, the XInitThreads() is called too late from libGL and bad things happen[1]. This problem doesn't occur with SDL 2.0.3 because it calls XInitThreads() during video initialization.

    I experience this problem for about 3-6 months now so it's probably caused by change in nVidia proprietary libGL implementation. However, it breaks some packages already present in Fedora which use SDL 1.2. Xonotic is affected for example. The crash happens during closing of the display where libX11 tries to release mutex which is NULL (or some random memory, see [1]).

    SDL 1.2 should be patched to explicitly call XInitThreads in SDL_VideoInit() to avoid such crashes under arbitrary libGL implementations.

    I wouldn't be able to figure this out without the insight of Xonotic core team wizards, especially divVerent. Thank you.

    [1] http://forums.fedoraforum.org/showthread.php?t=302471

    Version-Release number of selected component (if applicable): SDL-1.2.15-17.fc21.x86_64

    Steps to Reproduce:

    1. sudo dnf install xonotic
    2. xonotic-sdl
    3. # from game UI, either exit the game or change the resolution

    Actual results: Game segfaults.

    Expected results: Game doesn't segfault.

    On 2015-02-01 10:29:56 +0000, wrote:

    Whoops. Found the problem. Some time ago, out of curiosity, I put this into my profile.

    export __GL_THREADED_OPTIMIZATIONS=1

    Removing it or setting it to 0 fixes the problem for me. Sorry for the noise.

    On 2015-08-25 09:38:21 +0000, Ryan C. Gordon wrote:

    Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

    We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

    Our current focus is on SDL 2.0.

    If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

    Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

    Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

    Thank you, --ryan.

    opened by SDLBugzilla 5
  • Wrong IOCTL used for VSYNC

    Wrong IOCTL used for VSYNC

    This bug report was migrated from our old Bugzilla tracker.

    These attachments are available in the static archive:

    Reported in version: 1.2.15 Reported for operating system, platform: Linux, All

    Comments on the original bug report:

    On 2013-05-20 19:04:37 +0000, Paul Cercueil wrote:

    Created attachment 1145 Patch to address the issue

    The fbcon backend uses a non-standard IOCTL to wait for the vertical refresh. The Linux kernel provides a standard IOCTL for that task that should be used instead. See the attached patch.

    On 2015-08-25 09:38:22 +0000, Ryan C. Gordon wrote:

    Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

    We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

    Our current focus is on SDL 2.0.

    If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

    Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

    Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

    Thank you, --ryan.

    outdated 
    opened by SDLBugzilla 5
  • SDL_CloseAudio takes 2 seconds to return when using the Pulseaudio driver.

    SDL_CloseAudio takes 2 seconds to return when using the Pulseaudio driver.

    This bug report was migrated from our old Bugzilla tracker.

    These attachments are available in the static archive:

    Reported in version: 1.2.14 Reported for operating system, platform: Linux, x86

    Comments on the original bug report:

    On 2012-03-15 17:20:57 +0000, wrote:

    Created attachment 838 Testcase.

    When SDL_CloseAudio is called on the pulse backend, a delay of around 2 seconds will sometimes occur (about 50% of the time). The rest of the time, the function returns almost immediately. A testcase is attached.

    My OS is a fairly vanilla installation of Ubuntu 11.04.

    On 2012-03-15 17:40:48 +0000, wrote:

    Did a little more testing. Setting the audio driver to alsa rather than pulse has no effect on the bug, presumably because ALSA is emulated as a client of the PulseAudio server. However, setting it to esd removes the bug.

    My system has a universal sound latency of around 500ms; I've always presumed it was some sort of driver issue. When terminating the loopwave test with Ctrl+C (using the esd driver), the program will stop running as soon as this latency is over (that is, as soon as sound stops coming out the speakers). Using the pulse and alsa drivers, loopwave will keep running for an additional 1 - 2 seconds beyond this point.

    On 2012-03-19 15:43:22 +0000, wrote:

    Decided to attempt to fix this bug myself. The delay occurs in SDL_pulseaudio.c, within the call to pa_mainloop_iterate around line 427. This call blocks waiting for completion of an asynchronous pa_stream_drain operation, initiated earlier in the same function.

    This bug can be trivially solved by replacing the call to pa_stream_drain with a call to pa_stream_flush, which discards the data rather than waiting for a guarantee that it's finished.

    On 2012-03-19 15:47:38 +0000, wrote:

    PS: The above fix wouldn't resolve the same problem in the ALSA driver, when ALSA is being emulated on a Pulse system. I haven't tested this, but I believe the issue could be fixed in a similar way by replacing the call to snd_pcm_flush (in ALSA_CloseAudio) with snd_pcm_drop.

    On 2012-03-19 16:37:25 +0000, wrote:

    Created attachment 839 Patch to fix the delay when closing the ALSA and Pulse drivers.

    On 2012-03-19 16:43:19 +0000, wrote:

    Sorry for the comment spam, but I forgot to mention: The above patch was generated against the current SDL-1.2 branch of hg. Should also be relevant to SDL2, although I haven't checked that it will apply as-is.

    On 2012-03-22 21:24:36 +0000, Ryan C. Gordon wrote:

    Is dropping the last buffer of audio the correct approach, though? If you had a music player, should it cut off the last half second of a song so the process can quit quickly?

    This bug is real, but I think the culprit is PulseAudio and not SDL:

      http://pulseaudio.org/ticket/866
    

    We mentioned this in Bug # 1013, in regards to SDL_mixer, at one point.

    The gist is that we need to tell PulseAudio "wait until you've definitely played what we asked you to and get back to us" and it waits way too long.

    I suppose we could work around this in SDL by timing out how long it should take for Pulse to play all our data and just quitting at that point, but that's a goofy solution, too.

    --ryan.

    On 2012-03-23 15:36:48 +0000, wrote:

    Am I right in thinking that patching library or application X to accommodate a difficult-to-fix or widely-deployed bug in library Y isn't usually done in FOSS circles, then? I mean, I'd personally go for the more pragmatic option of patching X, but I can see how that could turn X into a hackjob in the long run.

    Philosophical issues aside, though, I'd say that dropping ~500ms of trailing audio will be less harmful in the general case than halting on shutdown for 2s. It's worth noting that without explicitly working around this bug by calling SDL_QuitSubSystem(SDL_INIT_VIDEO) before SDL_CloseAudio, SDL will always close down the audio subsystem before video; therefore, practically all SDL applications that use both audio and video (ie, games) will suffer from an ugly 2-second pause on closing, with an unresponsive window still visible to the user. I haven't tested this broadly, but I can at least confirm that it applies to Frets on Fire.

    On 2012-08-06 08:35:35 +0000, Stas Sergeev wrote:

    Me too on this bug.

    I'd like to note that the problem does NOT depend on how much audio was played and when. For me it pauses for 3 seconds even if SDL_PauseAudio(0) was never called at all, and the sound callback was never called. So I am not sure if the Comment 6 applies well. Or is the PA bug so bad that it hangs even when nothing was played?

    On 2013-11-11 01:21:19 +0000, Sam Lantinga wrote:

    Created attachment 1415 SDL 2.0 pulseaudio patch

    I don't think we actually need to wait for the drain operation to complete. Can you try out this patch and see if it: a) solves your issue b) you actually hear all the audio from the application as it quits?

    Thanks!

    On 2015-02-16 19:04:15 +0000, Stas Sergeev wrote:

    For me the problem no longer happens. I think because of the new pulseaudio-5.0. Tested with SDL-1.2.15 and SDL2-2.0.3 without any patches - all good.

    On 2015-08-25 09:38:23 +0000, Ryan C. Gordon wrote:

    Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

    We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

    Our current focus is on SDL 2.0.

    If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

    Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

    Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

    Thank you, --ryan.

    wontfix 
    opened by SDLBugzilla 5
  • Saitek ProFlight Rudder Pedals : modifications update only 2 axis while 3 axis are detected

    Saitek ProFlight Rudder Pedals : modifications update only 2 axis while 3 axis are detected

    This bug report was migrated from our old Bugzilla tracker.

    These attachments are available in the static archive:

    Reported in version: 1.2.14 Reported for operating system, platform: Windows (XP), x86

    Comments on the original bug report:

    On 2010-08-23 08:58:56 +0000, wrote:

    Created attachment 536 Fix bug on Saitek rudder pedals

    On Saitek ProFlight Rudder Pedals, there are 3 axis detected by SDL (left pedal, right pedal and rotation between the 2 pedals around Z axis). But when rudder is used, SDL updates only values for left and right pedals, rotation value is never changed. This behavior has been seen with SDL 1.2.14 on Windows XP SP 2.

    This problem has already been noticed here : http://www.orbiterwiki.org/wiki/FlyByWireEGCS#Saitek_Pro_Flight_Rudder_Pedals http://www.orbiter-forum.com/showthread.php?t=10010

    It is not a driver problem, because when I launch driver's test GUI, I can see that all movements are detected.

    After some code analysis, I think that I find the problem : MS API sends updated values in JOYINFOEX structure as following (for this rudder device) : dwXpos : left pedal dwYpos : right pedal dwZpos : nothing dwRpos : pedals rotation dwUpos : nothing dwVpos : nothing

    There are 3 values but the third one is not at the third position in this structure. So the code seems easy to fix in SDL_mmjoystick.c in SDL_SYS_JoystickUpdate(SDL_Joystick* joystick) function. I attach my own version of this file which has been successfully tested for this device and with some others (on Window XP only).

    Hope this can help.

    On 2011-04-12 20:18:06 +0000, Jen Spradlin wrote:

    Thank you for your bug report!

    We're busy working on getting SDL 1.3 ready for a high quality release, and want to make sure as many things are fixed there as possible. Could you check to see if your bug is resolved by the latest SDL 1.3 snapshot? http://www.libsdl.org/tmp/SDL-1.3.zip

    Thanks!

    On 2011-12-30 01:25:46 +0000, Ryan C. Gordon wrote:

    Bumping priority on a few bugs that I would like examined more closely before 1.2.15 is finalized. This is not a promise that a bug will be fixed. We may close it with WONTFIX or WORKSFORME or something, but I just want to make sure attention is paid.

    --ryan.

    On 2014-12-12 02:59:45 +0000, Kerrigan Bangs wrote:

    Created attachment 1967 Updated patch

    The original fix by the original reporter did not work for me. I made my own fix.

    On 2014-12-12 03:00:22 +0000, Kerrigan Bangs wrote:

    I know it's quite late but I know the precise cause of this problem:

    The mmjoystick method is written with the assumption that all joystick axes are contiguous.

    This is normally true, however apparently the Z axis is allowed to be skipped. (Source: http://msdn.microsoft.com/en-us/library/windows/hardware/ff543445%28v=vs.85%29.aspx at "No Holes" rule)

    More recently this problem also affects the Saitek X55 joystick, as its rudder axis is not detected, since the joysticks skips the Throttle axis.

    I have attached my own solution as the originally attached fix does not seem to work for me. Also, only the Z axis is allowed to be unmapped, so further checks afterward are not necessary assuming the axis count is correct.

    Note that this problem is still present in SDL2, for the mmjoystick method. It doesn't happen in the DX Joystick method. Still, it's easy enough to fix anyways, I think.

    On 2015-08-25 09:38:23 +0000, Ryan C. Gordon wrote:

    Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

    We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

    Our current focus is on SDL 2.0.

    If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

    Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

    Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

    Thank you, --ryan.

    endoflife 
    opened by SDLBugzilla 5
  • Use correct macros for Darwin PPC

    Use correct macros for Darwin PPC

    In few places wrong macros are used for Darwin PPC (it follows from code comments that MacOS is meant in those instances). There is no __powerpc__ on Darwin.

    Three definitions are there: __ppc__ = ppc32 __ppc64__ = ppc64 __POWERPC__ = ppc32/ppc64

    See, for example: https://opensource.apple.com/source/gcc/gcc-5465/gcc/config/rs6000/darwin.h.auto.html (Also, 10.6 does support ppc32.)

    opened by barracuda156 3
  • OpenGL severe display problem on macOS 11 Big Sur

    OpenGL severe display problem on macOS 11 Big Sur

    SDL 1.2x apps compiled against SDK 10.15 or SDK 11.x have severe display problems when started on macOS 11. All is fine on macOS < 11.x or when compiled against SDK 10.14. The window is as big as it should be but the actual video display is in the lower left corner, as if it only renders to the lower left quarter of the screen. Observed with DOSBox but reproduced with SDL's testgl program.

    It seems that it doesn't matter against which SDK you compiled SDL 1.2x.

    Tested with current git and also 5d441412 (as the next commit 718b76b8 added some macOS OpenGL fixes, I thought I'd try the commit before).

    Screenshot of testgl compiled against SDK 10.15 on macOS 11 testgl_SDK_1015

    Screenshot of testgl compiled against SDK 10.14 on macOS 11 testgl_SDK_1014

    Edit: with testdyngl, you can see that it really renders to the lower left quarter of the window testdyngl

    endoflife 
    opened by DominusExult 19
Owner
Simple Directmedia Layer
Simple Directmedia Layer (SDL) is a framework for creating cross-platform games and applications.
Simple Directmedia Layer
An SDL-1.2 compatibility layer that uses SDL 2.0 behind the scenes.

Simple DirectMedia Layer (SDL) sdl12-compat --- https://www.libsdl.org/ This is t

Simple Directmedia Layer 131 Nov 25, 2022
Image decoding for many popular formats for Simple Directmedia Layer.

SDL_image 2.0 The latest version of this library is available from: http://www.libsdl.org/projects/SDL_image/ This is a simple library to load image

Simple Directmedia Layer 235 Nov 14, 2022
Simple Directmedia Layer

Simple DirectMedia Layer (SDL) Version 2.0 --- https://www.libsdl.org/ Simple Di

Simple Directmedia Layer 4.3k Nov 25, 2022
Simple Directmedia Layer

hb-sdl Harbour bindings for SDL 2.0.16, a Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to aud

RafaƂ Jopek 3 Nov 8, 2022
In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch).

Intro In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch). It has been tested and work

Zero 1 Nov 11, 2021
MetaHook (https://github.com/nagist/metahook) porting for SvEngine (GoldSrc engine modified by Sven-Coop)

MetaHookSv This is a porting of MetaHook (https://github.com/nagist/metahook) for SvEngine (GoldSrc engine modified by Sven-Coop Team), mainly to keep

hzqst 63 Nov 20, 2022
A simple game framework written in C++ using SDL

SGF SGF (Simple Game Framework) is, as the name implies; a very simple and easy to use game framework written in C++ using SDL. Currently the project

Cam K. 1 Nov 4, 2021
A very simple 2D game engine written in C++, using SDL and Lua.

2D Game Engine written in C++, SDL, and Lua. This is a simple 2D game engine written in C++ and using SDL and Lua scripting

Gustavo Pezzi 22 Oct 31, 2022
crwusiz branch is comma.ai devel-staging base xx979xx HKG_community source add

crwusiz openpilot crwusiz branch is comma.ai devel-staging base xx979xx HKG_community source add v0.8.9 [ allow white panda and gray panda, OP3T suppo

Lee Jong Mun 35 Nov 16, 2022
DOSBox Pure is a new fork of DOSBox built for RetroArch/Libretro aiming for simplicity and ease of use.

DOSBox Pure is a fork of DOSBox, an emulator for DOS games, built for RetroArch/Libretro aiming for simplicity and ease of use.

Bernhard Schelling 547 Nov 12, 2022
A library for high-performance, modern 2D graphics with SDL written in C.

SDL_gpu, a library for making hardware-accelerated 2D graphics easy. by Jonathan Dearborn SDL_gpu is licensed under the terms of the MIT License. See

Jonathan Dearborn 1.1k Nov 17, 2022
Minecraft 4k: decompiled, translated to C using SDL for graphics and input, and improved upon

M4KC Minecraft 4K - C Rewrite For those who don't know, Minecraft 4K was a stripped down version of Minecraft submitted by Notch to the Java 4K Game P

Sasha Koshka 38 Oct 9, 2022
Cross-platform version of Heboris C7EX using a hardware-accelerated SDL 2.0 renderer

Heboris C7EX - unofficial version (YGS2K EX) This version contains the source code for Heboris C7EX. It requires a C compiler, SDL 2.0, SDL 2.0 mixer,

Brandon McGriff 13 Oct 18, 2022
sdl based game framework

Hallow Engine an sdl-based game framework Install Procedure Install SDL2[https://libsdl.org] and take the .h(header) files from the include/ folder, t

Hallow - The Game Framework 6 Nov 24, 2021
Raycaster demo in SDL, inspired by 3DSage

raycastersdl -Coded following 3DSage's tutorial. Part 1 -> https://www.youtube.com/watch?v=gYRrGTC7GtA Remeber to install SDL2 libraries first: sudo a

Velorek1 1 Oct 30, 2021
A Binary Clock. Written 3 different ways. C and SDL, Python and PyGame, Python and PyGame Zero.

Super Clock A Binary Clock. Written 3 different ways. Python with PyGame Zero, Python with PyGame and C with SDL2. Time is displayed in 3 groups of 8

null 3 Dec 8, 2021
A demo test game made from scratch using C++ and SDL

Dethroning Table of contents About This Game How to Compile the game About This Game This is a Cross-Platform Game Demo. How to Compile the game Run t

Haider Mirza 1 Jan 21, 2022
The official distribution of olcPixelGameEngine, a tool used in javidx9's YouTube videos and projects

olcPixelGameEngine The official distribution of olcPixelGameEngine, a tool used in javidx9's YouTube videos and projects. You only need the one file -

Javidx9 3.3k Nov 21, 2022
Collections of AndLua modding related projects

AndLua Modding Projects Just my collections of AndLua modding related projects. Sorry, if I become file hoarder now, I collect everything but never us

null 11 Sep 24, 2022