Elias Vanderstuyft | 25 Nov 19:47 2014

Re: [PATCH] Haptic coding bugs and fixes for Linux FF: periodic.phase handled as time instead of angle; + direction clarification


On Sun, Oct 26, 2014 at 6:06 PM, Sam Lantinga <slouken <at> libsdl.org> wrote:
Yep, thanks!

On Sun, Oct 26, 2014 at 2:45 AM, Elias Vanderstuyft <elias.vds <at> gmail.com> wrote:
I'm not sure what you mean by "these match the behavior on Mac and Windows".
I assume you mean when a SDL periodic.phase of "9000" (= +90deg) is applied, the behavior is the same across Linux, Mac, and Windows?

They are the same between Mac and Windows, since they essentially use the same API (based on DInput).
Now the remaining thing to prove, is whether a Linux phase of "0x4000" corresponds with a DInput phase of "9000".
If you use FEdit (Microsoft Force Editor), you can see that the DInput phase is indeed interpreted as a "positive phase".
For the Linux case, we will standardize the phase as "positive phase", as can be seen in QForceStudio (https://github.com/Logitech/qforcestudio).
This means that every Linux FF driver will have to follow this convention. At the moment, very few Linux FF drivers take the phase parameter into account,
but this will change in the future (hence the "verification" you asked for will become a "constraint").

I hope this answered your question.


On Sat, Oct 25, 2014 at 9:12 PM, Sam Lantinga <slouken <at> libsdl.org> wrote:
Have you verified that these match the behavior on Mac and Windows?


On Sat, Oct 25, 2014 at 5:33 AM, Elias Vanderstuyft <elias.vds <at> gmail.com> wrote:
Hi all,

Here's yet another bug report (https://bugzilla.libsdl.org/show_bug.cgi?id=2766) that handles the subject of this mail.
You might find the argumentation of the 3rd patch a bit sketchy, but "we" refers to some people included in Cc.


SDL mailing list
SDL <at> lists.libsdl.org
DLudwig | 25 Nov 17:26 2014

Re: SDL2 WinRT performance issues

Meldryt wrote:
We develop a simple 2D game for ios and windows phone. Both versions are quiet similar
The game runs fluenty on an old IPhone with 50-60 fps but on windows phone it runs only at 20-25fps.

Maybe it has something to do with the multitouch handling or draw calls.
We use some SDL draw functions for simple primitives like SDL_RenderFillRect, filled circles (filledPolygonRGBA from gfxprimitives) or draw text functions like TTF_RenderText_Solid.
I have already tried to gain more performance by reducing draw calls for single primitives, but it didnt help.

I'd be surprised if it had to do with multitouch code, and suspect the D3D11 renderer could use some additional optimization.

Might you be able to provide some sample code that illustrates the issue?

-- David L.
SDL mailing list
SDL <at> lists.libsdl.org
DLudwig | 25 Nov 15:48 2014

Re: SDL_StartTextInput WinRT

Support for StartTextInput in WinRT is still pending. I can plan on trying to take a closer look at implementing SDL_TEXTINPUT event support within the next few weeks. Alternatively, if you'd like to submit a patch to add support for such, this could expedite things substantially (and be much appreciated!)

One technical note regarding user input: it may be a while, and potentially impossible, to add programmatic show/hide on-screen keyboard support in WinRT, for the time being. For one, my understanding is that on-screen keyboards in WinRT require XAML, support for which is being worked on (for SDL), but is apt to take a while to get working well + reasonably stable (beyond some fairly experimental XAML code that's in-place now). Second, my understanding is that Microsoft has taken steps to prevent on-screen keyboards from being shown programmatically. MSDN has an article at http://msdn.microsoft.com/en-us/library/windows/apps/hh465404.aspx with more details (see the section titled, "User-driven invocation", which is currently near the bottom of the page.) There may be a workaround to this, or they may have changed policy since, but it doesn't look promising, IMO.

-- David L.
SDL mailing list
SDL <at> lists.libsdl.org
Alex | 25 Nov 01:12 2014

Re: Linux port tutorial for "Handmade Hero" using SDL

MrPhil wrote:
Worth noting that Handmade Hero is currently showing software render on purpose as a learning exercise. The plan is to do hardware acceleration later after software rendering is done.

I don't speak about Casey Muratori's "Handmade Hero" - it is not positioned as SDL tutorial. May be this tutorial is made for learning software rendering as you said.

I speak about this tutorial (David Gow's). This is two different tutorials and this one is based on previous. But this one is positioned as SDL tutorial from the start. Because of this reason I post here my opinion about this tutorial.
I think developers, who started to learn SDL, should not reinvent the wheel. In my opinion good teacher must teach them best practices in SDL development. This is looks strange when someone teach me bad practices, but he plan to teach me good later.
May be better to write in SDL tutorial: what is SDL_Surface, what fields in this srtuct, and how we can use this fields including pixel buffer. And explain why SDL_UpdateTexture is not best function to use every frame. And if we using software rendering (for learning or other reason), we should use SDL functions and structures for software rendering (not only for hardware accelerated).
Imagine that someone read this tutorial and think: "this is best practices in SDL" or "this is only way to do this tasks in SDL". May be this developer start to develop with SDL using wrong practices.
If author want to teach SDL development, he must use "SDL way" (all SDL functions, best rendering practices etc). If he don't teach SDL, why his tutorial looks like this is SDL tutorial?
All of this is my own opinion.

In all cases (even if I am wrong), I don't understand why author don't use SDL_Surface for software rendering (if he teach SDL development).
SDL mailing list
SDL <at> lists.libsdl.org
mattbentley | 23 Nov 09:46 2014

SDL_Texture, main-memory usage?

I've just been building some apps in SDL2 and am surprised to find that even when hardware acceleration is available, creating a texture still uses main memory as well, as reported by Windows Task Manager.
For example, this:
SDL_Texture *texturer = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STATIC, 8192,8192);

makes the app use ~226000kb memory. While this:
SDL_Texture *texturer = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STATIC, 4096, 4096);

makes the app use about 44000kb.

Is this the same for everyone, and if so, why?
I'm using an HD5800 1GB on x86 Winxp OS (4GB, 3.6GB addressable), so I wondered if the graphics driver is sharing memory addressing space with the OS. Otherwise I can't account for this.
SDL mailing list
SDL <at> lists.libsdl.org
T. Joseph Carter | 22 Nov 07:03 2014

Re: CONTROLLERDEVICEREMOVED .which increments on each unplug


If you lose the device indices, you would lose the enumeration loop 
and events will become essentially required.  Which IMO is fine, as 
all major platforms SDL supports are event-based, most including 
events an application MUST respond to or be regarded as fundamentally 

I think one of the goals of the ability for events to be optional in 
the first place was to allow for extra-lean static builds of SDL on 
embedded platforms such as game consoles maybe?  In practice, any 
such thing SDL still supports has gone to having mandatory event 
structures like everything else.  :)

I would not mind seeing a little break with backwards compatibility 
even with the event interface in 2.1 a little bit if it meant that 
you no longer needed to keep a laundry list of open controllers.

I also wouldn't mind seeing some API changes in how joysticks and 
game controllers rrelate and interoperate a bit to reflect a little 
better how these things are used—but that kind of requires that I say 
"Arrrgh!  Thread hijacked!"  

Of course at the time I wanted to discuss that, 2.0 was fresh and 
new, the controller DB was only available burned-in and was sparse, 
the only real effective configurator tool for end-users to generate 
mappings was Steam, and a number of popular retro controllers simply 
couldn't be mapped.  Then I got totally distracted by 10^6 different 
higher-priority things forcing hobby interests out of the foreground 
and other people began dealing with some of the above problems 
without me.  Haven't been tracking closely enough to see where things 
stand now.  So with that in mind, I'll discus some personal 2.1 goals 
for joystick/controller management:


Controller TYPE!

Reflecting the way people actually use these controller devices both 
on consoles and on PCs (which aren't always the same), and giving 
devs some hints so that when a controller appears, they have some 
idea what to do with it.  I imagine mappings would include a major 
class (which may affect SDL's handling) and a delineation hint that 
SDL will almost certainly never care about.  Might be an unsigned 32 
bit value intended to be used as a bit field?

Major classes I envision:

- Basic "modern" controller (non-Nintendo!)  Pretty much the status 
quo now, though perhaps with the added benefit of knowing that 
mappings providing this WILL have certain controls.  Two analog 
sticks, shoulder buttons, two triggers (may be digital), DPad, four 
face buttons, and at least one control button (start/pause/menu).  
Hints might include that the triggers are analog and that additional 
features beyond the basic definition exist.

Hints for the above: Sony has included accelerometers, now a 
touchpad, and on PS2 controllers, analog buttons (though I don't know 
if any PC interface exposes that feature…)  Microsoft has chatpads 
and sound devices.  Apple makes all controls optionally analog, 
including the DPad for the greatest WTF in gaming…  Easily 99% of 
games would never care about the hint, unless there's something 
specific they need.

- Retro controllers and arcade sticks.  Why?  The modern controllers 
do a fine job standing in for the SNES controller unless you have a 
Microsoft XBox 360 controller, anyway.  ;)  The thing is, some of us 
like the feel of the older controllers.  (FWIW, I recommend Buffalo's 
SNES controller which is on Amazon here: http://goo.gl/K7rJ90   They 
also do an original Famicom style controller, but sadly no analogues 
to the Genesis/Saturn, N64, or GameCube…  The cheap USB copies CAN be 
made good enough if you're willing to mod them…)

Anyway, here the hints become actually more useful.  Some useful 
hints I see are Arcade/fighter (Genesis/Saturn/SF2 arrangement), 
old-school (DPad, only one button), NES, SNES, Genesis 3 button, N64, 
GameCube, and some odd birds on a modern system like paddles (two 
players, traditionally "one" analog stick and two fire buttons, but 
we could use X axis of left and right stick if we decide to…), and 
old-school analog (the two paddles as a single analog joystick with 
two fire buttons…)

- Dance mats(?), perhaps so they can be ignored when looking for 
normal controllers?

- Band instruments.  Definitely so they can be ignored when looking 
for normal controllers.  Notably, there are multiple franchises with 
slightly different mappings.  We could sort that in mappings I 
suppose?  Obvious hint is the type of instrument.

- Modern Nintendo.  May be totally outside of the realm of the game 
controller API.  I dunno, I don't own a Wii, shockingly enough.  I 
figure the Wii U iPad wannabe is off the table for now, but if we can 
make the rest work, why not?

That just leaves the stuff that's not really a gamecontroller model 
device in any way (flight control stuff for example) and stuff that 
is, but has more than we can express with the current API.

I'd be interested in discussing a way to query features of things 
like that and figuring out how to access them.  But I don't have much 
to offer about how to go about it now.

Sorry for the novel,


On Tue, Oct 07, 2014 at 11:40:30AM -0400, Ryan C. Gordon wrote:
>>Is this a bug, or have I misunderstood the 'event.cdevice.which' value
>We should make this more clear at the API level for SDL 2.1, but 
>"which" means something different for each of those events:
>    Sint32 which;       /**≤ The joystick device index for the ADDED 
>event, instance id for the REMOVED or REMAPPED event */
>The idea is when it's added, you can do 
>SDL_GameControllerOpen(which)...and several other things that operate 
>on unopened joystick indexes. This is a number that might get recycled 
>if we add a stick after one has been removed, to keep 
>SDL_NumJoysticks()-sized arrays reasonable).
>On removal, though, this will be an instance id. This number is unique 
>and increments on each new joystick the system sees. You can get this 
>for a controller with:
>    myInstance = 
>(maybe for 2.1, we'll get rid of joystick indexes and use instance ids 
>for everything.)
>SDL mailing list
>SDL <at> lists.libsdl.org
SDL mailing list
SDL <at> lists.libsdl.org
ShiroAisu | 21 Nov 21:57 2014

Acounting for key modifiers on diferent keyboards

I know how to check for a key modifier, but the problem is I can't just predict the output of a key with a modifier on all keyboards. For instance, if I press Shift + 1 in my keyboard I get !, but this is not the case with every keyboard. How do I go about fixing this issue?
SDL mailing list
SDL <at> lists.libsdl.org
David Gow | 21 Nov 10:00 2014

Linux port tutorial for "Handmade Hero" using SDL

Hey all,

I've been writing a tutorial on how to port Casey Muratori's "Handmade 
Hero" game project to Linux, and am using SDL quite heavily. "Handmade 
Hero" is a set of videos detailing, line-by-line, the development of a 
game in C: http://handmadehero.org/

The Linux tutorial, which uses SDL, is located here: 

Hopefully people who are learning to use SDL might find a few bits and 
pieces there useful.

— David

SDL mailing list
SDL <at> lists.libsdl.org
Eric Wing | 21 Nov 01:32 2014

SDL 2D renderer losing Render-to-Textures on Windows when toggling fullscreen

I'm using the SDL 2D renderer. I've discovered that when I toggle
between fullscreen and windowed mode, I lose all my textures that were
created with render-to-texture. But the regular textures seem to
survive, and render-to-textures that are recreated will correctly

I'm wondering if this is related to the recent thread:
[D3D9]Cannot recreate streaming texture

I'm just using defaults with the SDL 2D renderer. I didn't request
anything. I don't even know what is being used behind the scenes to
render in this case. This is regular Windows, not WinRT.

This only happens on Windows. Mac and Linux don't have any problems
with this. (Though, minor digression: On Mac, there is a few second
delay on launch where the image is not resized to fit the whole
screen...I would love to know the cause of that.) Here are some
prebuilt binaries that can demonstrate the issue.

Hit Alt-Enter or Ctrl-F to toggle fullscreen. (Use Cmd instead of Alt on Mac.)

Windows (Windows 7+ 64-bit)
zip: http://playcontrol.net/tempdownload/BlurrrBinaries/FlappyBlurrrCWindows.zip
installer: http://playcontrol.net/tempdownload/BlurrrBinaries/FlappyBlurrrC-1.0.0-win64.exe


Linux (64-bit, SteamOS runtime compliant)

Source code is here. It is a little lengthy and not fully cleaned up,
but you should be able to verify if I'm not doing anything wrong.

(If you are curious, I will write a formal tutorial for this in the
coming months. This is part of a new initiative to launch a new
commercial SDK that uses and embraces (instead of hides) SDL as the


Beginning iPhone Games Development
Jared Maddox | 21 Nov 01:05 2014

Re: SDL Digest, Vol 95, Issue 30

> Date: Thu, 20 Nov 2014 08:13:52 +0400
> From: Alexander Sabourenkov <llxxnntt <at> gmail.com>
> To: SDL Development List <sdl <at> lists.libsdl.org>
> Subject: [SDL] TTF text shaping
> Message-ID:
>         <CABZtw9OTxA=Q5aLnRuvvtRhtVBGZi2w8qDEWRqt8VpFb3ErrQg <at> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> Hello.
> https://github.com/lxnt/zhban
> A library for rendering lots of pretty text fast.
> Aimed more at OpenGL than pure SDL, though can be used with pure SDL  - see
> test.py.
> Pure C. Does not reinvent text shaping. Caches as much as makes sense. Will
> support vertical and RTL scripts if there would be a test case.

I think there's a few Japanese users of SDL, maybe one will provide
some test text and a "correct" image.

> Correctly
> renders most sorts of obscure scripts including Tengwar
> (freemono/telcontar). Supports per-cluster fg/bg coloring.

Does it properly support all four "cases" of Arabic? There was someone
wanting to display that a few months ago.
JeZ-l-Lee | 20 Nov 13:07 2014

Re: USB Gamepad Not Found By SDL2 In Win 8.1 VM?

theGiallo wrote:
Could you post the code with which you detect the pads? I bet you are using SDL_GameController and it does not have the mapping. If so try to SDL_JoystickOpen

    DEBUG = false;

    EXIT_Game = false;

    DelayAllUserInput = 0;

    KeyOnKeyboardPressedByUser = -1;

    MouseButtonPressed[0] = false;
    MouseButtonPressed[1] = false;

    JoystickDeviceOne = NULL;
    JoystickDeviceTwo = NULL;
    JoystickDeviceThree = NULL;

    if (SDL_NumJoysticks() == 0)
        printf("No USB joysticks are plugged in.\n");
        if (SDL_NumJoysticks()>0)
            JoystickDeviceOne = SDL_JoystickOpen(0);
            NumberOfJoyButtons[0] = SDL_JoystickNumButtons(JoystickDeviceOne);
            NumberOfJoyAxises[0] = SDL_JoystickNumAxes(JoystickDeviceOne);
            printf("SDL2 Joystick 0 initialized.\n");

        if (SDL_NumJoysticks()>1)
            JoystickDeviceTwo = SDL_JoystickOpen(1);
            NumberOfJoyButtons[1] = SDL_JoystickNumButtons(JoystickDeviceTwo);
            NumberOfJoyAxises[1] = SDL_JoystickNumAxes(JoystickDeviceTwo);
            printf("SDL2 Joystick 1 initialized.\n");

        if (SDL_NumJoysticks()>2)
            JoystickDeviceThree = SDL_JoystickOpen(2);
            NumberOfJoyButtons[2] = SDL_JoystickNumButtons(JoystickDeviceThree);
            NumberOfJoyAxises[2] = SDL_JoystickNumAxes(JoystickDeviceThree);
            printf("SDL2 Joystick 2 initialized.\n");

    for (int joy = 0; joy     {
        JoyUP[joy] = Axis1;
        JoyDOWN[joy] = Axis1;
        JoyLEFT[joy] = Axis0;
        JoyRIGHT[joy] = Axis0;
        JoyButton1[joy] = Button0;
        JoyButton2[joy] = Button1;

    JoystickSetupProcess = JoySetupNotStarted;

    for (int index = 0; index     {
        JoystickDirectionHorizonal[index] = CENTER;
        JoystickDirectionVertical[index] = CENTER;
        JoystickButtonOne[index] = OFF;
        JoystickButtonTwo[index] = OFF;
        JoystickButton1Pressed[index] = false;
        JoystickButton2Pressed[index] = false;

    KeyboardSetupProcess = KeyboardSetupNotStarted;
    UserDefinedKeyButtonOne = -1;
    UserDefinedKeyButtonTwo = -1;
    UserDefinedKeyUP = -1;
    UserDefinedKeyRIGHT = -1;
    UserDefinedKeyDOWN = -1;
    UserDefinedKeyLEFT = -1;
    UserDefinedKeyPause = -1;

    DelayAllUserInput = -1;


JessePalser <AT> Gmail <DOT> com
16BitSoft Inc.
Video Game Design Studio
SDL mailing list
SDL <at> lists.libsdl.org