SDL 2.0 blockers? |
SDL 2.0 blockers? |
Brian Barnes
Guest
|
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 |
|||||||||||||
|
SDL 2.0 blockers? |
gero
|
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 |
|||||||||||
|
SDL 2.0 blockers? |
Driedfruit
Guest
|
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 |
|||||||||||||
|
SDL 2.0 blockers? |
Dimitris Zenios
Guest
|
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 |
|||||||||||||||
|
SDL 2.0 blockers? |
Nathan Coulson
Guest
|
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 |
|||||||||||||||||
|
SDL 2.0 blockers? |
Gerry Jo
Guest
|
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 2.0 blockers? |
Jared Maddox
Guest
|
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 |
|||||||||||||||||||
|
SDL 2.0 blockers? |
Gerry Jo
Guest
|
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 |
|||||||||||||||
|
SDL 2.0 blockers? |
René Dudfield
Guest
|
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 |
|||||||||||||||||
|
SDL 2.0 blockers? |
Jared Maddox
Guest
|
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 |
|||||||||||||||||||
|
SDL 2.0 blockers? |
Mason Wheeler
Guest
|
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 |
|||||||||||
|
SDL 2.0 blockers? |
gabomdq
|
2012/7/13 Sam Lantinga
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. |
|||||||||||||
|
SDL 2.0 blockers? |
Marcus von Appen
Guest
|
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 |
|||||||||||||
|
SDL 2.0 blockers? |
Marcus von Appen
Guest
|
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 |
|||||||||||||||
|
greno
|
Sam, congrats on landing at Valve.
Here's another blocker for SDL 2.0: http://bugzilla.libsdl.org/show_bug.cgi?id=1495 . |
|||||||||||
|
wboe
|
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 |
|||||||||||
|
PoV
|
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. |
|||||||||||
|