The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I talked with Ryan and Gabriel and we all agree that it's time to unleash SDL 2.0 on the masses.

Before we do that I want to get as many blocking issues resolved as soon as possible. The timing on this is interesting, because my computer is on a truck, but I think if we get the hot issues known publicly, then we'll be able to get them fixed more quickly and folks on the list can help bang them out.


I'd like everyone to reply to this thread with links to bugzilla reports that are blocking you.


... GO!

Sam wrote:


First off, congrats, Sam!

Second: 1505

That's all for me, and obviously I'm not blocked by it (as I just used my own patch), but it should probably be finalized before 2.0. I think the best solution is using SDL_SetEventFilter plus Piotr's naming: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-July/084999.html. The two must have would be iOS and Android.

Since the game center stuff was accomplished in a optional callback, this shouldn't effect that.

[>] Brian

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hello,

installing SDL2 from hg happens to not install SDL_system.h - so any test and
or test-build will fail.


BR

Gero
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Good call!

http://bugzilla.libsdl.org/show_bug.cgi?id=1323

http://bugzilla.libsdl.org/show_bug.cgi?id=1395

http://bugzilla.libsdl.org/show_bug.cgi?id=1428

On Fri, 13 Jul 2012 21:18:46 -0400
Sam Lantinga wrote:




--
driedfruit
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What about multimouse,multikeyboard etc?

On Fri, Jul 13, 2012 at 12:09 AM, Driedfruit wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Sat, Jul 14, 2012 at 6:26 AM, Dimitris Zenios
wrote:

Not in bugzilla (I can add it on sunday/monday). SDL2_Mixer failed to
work on MacOSX last time I tried it. I think the precompiled SMPEG
framework was linking to SDL and not SDL2. (could have sworn I posted
it to the list, but not seeing it at the moment.)

Also, thank you for everything.

--
Nathan Coulson (conathan)
------
Location: British Columbia, Canada
Timezone: PST (-
Webpage: http://www.nathancoulson.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi. I haven't really been keeping up with SDL for a long time, so sorry
if I'm a bit out of touch here, but I had a quick look at the event
system and have some comments and questions about that (specifically
tablets, touch and joysticks):

* Has pressure-sensitive tablet support been dropped? I see there's
events for them in SDL_events.h (SDL_INPUTMOTION etc), and the SDL_Touch
struct has fields for it, but there's no structs defined for the
SDL_INPUT* events anywhere, and testing with my tablet just gives me
regular mouse events for it.

Anyway, for tablets it'd probably be better to just use floats for
everything (x, y, pressure, rotation in x/y/z, etc), since the tablet's
resolution can be much, much higher than the resolution of a window or
screen.

* The SDL_Touch structure probably needs to reserve fields for tilt in
both x and y, not just "tilt". I thought I'd reported a bug about this
before, but couldn't find it when searching bugzilla now, so here's a
new one for that: http://bugzilla.libsdl.org/show_bug.cgi?id=1542

Actually, if that struct is for configuration of tablet capabilities and
limits (there doesn't seem to be any documentation about this
anywhere?), should there be max and min for those as well, in stead of
just the single value?

* Joystick events doesn't have a window id field (they're actually the
only events aside from SDL_QUIT that doesn't). Might be a good idea to
reserve space for one in case some windowing system adds support for
that? (Wayland?)

* Why is position information in SDL_TouchFingerEvent and SDL_Finger
16-bit values? I thought SDL 2 was going to move away from 16 bit ints
and just use regular ints everywhere? I guess you could argue that 16
bits is likely to be enough for in-window positions even with high
resolution displays, but with raw position and pressure information for
tablets, 16 bits is cutting it pretty close if it isn't already too
little (although, as I said before, it'd probably be better to use
floats for those). (Also, should SDL_Finger have a pressure delta field?
It can be calculated from pressure and last_pressure, but so can xdelta
and ydelta..)

* Nitpick: For events id fields, windowID has a capital D while
touchId/fingerId/gestureId has a lower case d.

-g

Den 14. juli 2012 03:18, skrev Sam Lantinga:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL_Touch & SDL_Finger look like they're used to represent the device,
instead of it's events.

If you're just getting regular mouse events for your touch screen,
then it might be worthwhile for you to dig into how your touchscreen
is represented in your OS. I wouldn't be surprised if some smaller
Linux distros represent touchscreens as mice.



Looking at the structure, it looks like tilt & rotation are probably
intended for gestures, instead of e.g. pen tilt or accelerometer tilt.

For the tilt of the tablet itself, I assume that the data would be
provided by a joystick or trackball event, because the finger event
doesn't list relevant data.



I'm pretty sure that it's tablet info, yes.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Den 16. juli 2012 03:38, skrev Jared Maddox:

Well, yes and no. Some of the fields do, but others would make more
sense as event information rather than device-wide configuration.
Otherwise you lose e.g. multiple changes in tilt between handling of events.


Yes, it's recognized by my Linux distro, but it's not that kind of
tablet =). I should've been more clear about that, I guess. I'm talking
about drawing tablets, like this:

http://en.wikipedia.org/wiki/Graphics_tablet
http://en.wikipedia.org/wiki/File:Wacom_Intuos4_Pen_Tablet.jpg

They're basically like touchscreens without the screen (though some do
have screens), and they're mostly used for drawing graphics. You draw
with a special pen in stead of your fingers. They provide high
resolution information about the pen's position and tablet proximity,
pressure, tilt and rotation, etc. You can also use several different
pens with a single tablet, and it can distinguish between them
automatically. (For example, the pen that came with my tablet has two
sides that can be used for drawing. In Gimp, I can attach different
tools and settings to the each side of the pen, and then select which
one to use simply by drawing with the corresponding side of the pen.)

Anyway, there at least used to be plans for adding support for these
devices to SDL 1.3/2. I'm wondering what's the status of that. As far as
I can tell, it seems unfinished, which is a bit worrisome now that SDL 2
is about to be released and its API set in stone.

-g
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Mon, Jul 16, 2012 at 5:37 AM, Gerry Jo wrote:



Hopefully they will do some alpha releases, beta releases, and perhaps even some release candidates before 2.0 API is locked in.  Best to enter bug reports

Such as tilt & rotation in SDL_Touch? Yes, I assume those are used
internally by the 'driver' code to store data that gets used to build
events later on.



I'm aware of them, until I did some more looking I was assuming that
tile & rotation were used to provide pen orientation data in relation
to the screen. I actually wouldn't be surprised if those DID show up
as mice in at least some Linux distros. Mouse support likely would
have been implemented quite some time ago (certainly before
multi-touch became famous), and at least the PS/2 mouse interface uses
a serial interface that can apparently encode much more than just
three axes and three buttons (I once saw a mouse that had a little
trackball instead of a normal scroll wheel, and mice with hordes of
buttons weren't really RARE before USB dominated the market).



Just because the API is about to be 'set in stone' doesn't mean that
all of the features have to be used at the time of first release. Why
don't you make a patch that adds the relevant data fields in the
various finger structures (with the pens represented as fingers)?
Since SDL 2 will presumably NORMALLY be used in the form of a
.dll/.so, usage could be implemented later as long as the needed data
fields were already available.

Also, providing the patch yourself makes it more likely for the
features that you want to get in, particularly if they're reasonable
features like this.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If the API is about to be set in stone, could we please get a concept of "logical resolution" first?

This is the one major feature that SDL 2 really needs and still doesn't have, IMO: A way to specify
a "logical resolution" of an SDL window that is different from the "physical" size in pixels. It's
trivial to implement in any modern, 3D-accelerated backend, and a lot more work to have to
emulate it outside of SDL, so putting it in SDL is the logical choice.

Mason

2012/7/13 Sam Lantinga
I don't know if these are really blockers, it's a list of bugs I was tracking and hoping to get fixed before an eventual release:


http://bugzilla.libsdl.org/show_bug.cgi?id=1431


http://bugzilla.libsdl.org/show_bug.cgi?id=1506


http://bugzilla.libsdl.org/show_bug.cgi?id=1428 / http://bugzilla.libsdl.org/show_bug.cgi?id=1520


http://bugzilla.libsdl.org/show_bug.cgi?id=1505




 

--
Gabriel.

On, Sat Jul 14, 2012, Sam Lantinga wrote:


I'm currently looking into a SDL-related joystick issue for FreeBSD[1],
which should be analysed and fixed within the next few days and that
will have an impact on both, SDL 1.2 and 2.0. I'd like to get that
committed before a release package for SDL 2.0 is made :-)

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169042

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On, Tue Jul 17, 2012, Marcus von Appen wrote:


Filed as #1552 (for SDL 1.2) and #1553.

http://bugzilla.libsdl.org/show_bug.cgi?id=1552
http://bugzilla.libsdl.org/show_bug.cgi?id=1553

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sam, congrats on landing at Valve.


Here's another blocker for SDL 2.0:

http://bugzilla.libsdl.org/show_bug.cgi?id=1495

.

I am creating a GUI toolkit for SDL on Android, and I ran into 2 issues, one small and one big. First the small one.

To make multitouch work, you must know which finger created the touch. This can be done with SDL_GetFingerIndexId() from the SDL source code, which works well for SDL_FINGERDOWN and SDL_FINGERMOTION events, however for SDL_FINGERUP events always -1 is returned. Is it possible to get the correct value?

Now the big issue. The main reason that I want to use SDL for Android is, beside to get rid of that irritating java language, the expectation that maybe the audio latency might be better then in pure Android. This seems to be not the case. You can ask what you want, you will always get a buffer size of 4096 samples (at 44100 sample rate). I looked into SDL_audio.c, and saw that the audio streambuffer is copied into another buffer in order to facilitate sample-rate conversion and other effects. Wouldn't it be a good idea to inforce to the developer one sample frequency and one buffer size, such that as less as possible extra delay is introduced? Please don't underestimate the importance of low audio latency. There exists an Android audio forum, and nearly all discussions there are about latency. We envy the iOS platform, where audio latency is only about 50ms.

wboe

Apologies for bringing back a dead thread, but it was the most appropriate one.

http://bugzilla.libsdl.org/show_bug.cgi?id=1353

This bug is my only real SDL2 blocker. There are more things, but I could ship without them. This bug, FullScreen SDL on Windows 7 is kinda busted (the taskbar overlays, or is hidden completely, like my OpenGL context is way below everything).

Also, in the latest mainline, some of the haptic code is broken on MinGW. I had to ./configure with --disable-haptic to build an SDL.