There is a patch to convert them to [0; 1] on X11. (note: it might
break some trackpad)
And also a patch to convert the fingertouch coordinates to the Logical
Render size, if needed. (I haven’t tested it on android, but I will do
it).
Patches are tested to be working on linux/x11.
The idea is that there are more and more touch-screens on desktops,
laptops and that it would be better if the same events on different
platform were using the same convention.
Cheers,
Sylvainfrom my touch-screen were in pixels, whereas there were scaled to [0;
On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:
Hey everyone, we’d like to release 2.0.4 early next month.
If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.
I’d like to see bug https://bugzilla.libsdl.org/show_bug.cgi?id=2269 fixed.
It is a showstopper to anyone who uses logical size and clipping rectangle
as it doesn’t consider the logicalsize x/y when set. Everytime black bars
are needed (desired ratio != screen ratio), the clipping rectangle gets
misplaced.
I wrote a patch for the OpenGL(ES(2)) renderer (which is attached to the
bug), but I couldn’t test if DirectX renderers has the same problem.
2014-07-21 3:49 GMT-03:00 Sylvain Becker <sylvain.becker at gmail.com>:> Hello,
This is not a showstopper bug, but may be important : I notice events
from my touch-screen were in pixels, whereas there were scaled to [0;
1] in Android and IOS.
There is a patch to convert them to [0; 1] on X11. (note: it might
break some trackpad)
And also a patch to convert the fingertouch coordinates to the Logical
Render size, if needed. (I haven’t tested it on android, but I will do
it).
Patches are tested to be working on linux/x11.
The idea is that there are more and more touch-screens on desktops,
laptops and that it would be better if the same events on different
platform were using the same convention.
Cheers,
Sylvain
On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:
Hey everyone, we’d like to release 2.0.4 early next month.
If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.
The patch there handles this by getting the intersecting rectangle of the
viewport and the clipping rectangle.
I’d say there’s a good chance that this needs to be done for (at least some
of) the other renderers as well, although
I haven’t checked the code.
Also, should the user be expected to clear the renderer to get neat black
bars, or should that be handled implicitly by
the renderer? Different configurations produce different results in regards
to the behaviour of the unrendered area, especially when resizing.
On my Intel/Mesa laptop, the software renderer (with the patch from the bug
report) will render the black boxes reliably,
yet produces garbage with the OpenGL renderer. On my desktop with the
nVidia blob, however, the behaviour is inverse:
the software renderer produces lots of garbage, but the OpenGL equivalent
shows none. This is with the same shared library on both machines.–
Melker Narikka
On Mon, Jul 21, 2014 at 6:26 PM, Leonardo Guilherme < leonardo.guilherme at gmail.com> wrote:
Hello,
I’d like to see bug https://bugzilla.libsdl.org/show_bug.cgi?id=2269
fixed. It is a showstopper to anyone who uses logical size and clipping
rectangle as it doesn’t consider the logicalsize x/y when set. Everytime
black bars are needed (desired ratio != screen ratio), the clipping
rectangle gets misplaced.
I wrote a patch for the OpenGL(ES(2)) renderer (which is attached to the
bug), but I couldn’t test if DirectX renderers has the same problem.
If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.
At the very least it would be good to get more eyes on the issue so we can come up with a usable fix.
I also have a small patch to fix compilation when SDL_syswm.h is included in modern Objective-C (or Objective-C++) code on OS X and iOS: https://bugzilla.libsdl.org/show_bug.cgi?id=2641On Jul 15, 2014, at 1:23 PM, Sam Lantinga wrote:
Hey everyone, we’d like to release 2.0.4 early next month.
If you have long standing or showstopper bugs that you’d like addressed, please reply to this thread with a link to a bug report. If there isn’t a patch already hopefully the community will jump on and take a look.
This one is in, thank you. I’ll take a look at reproducing the other issue.
–ryan.On 7/30/14, 1:33 PM, Alex Szpakowski wrote:
A crash bug on OS X was introduced since 2.0.3?s release, it?d be great
to get that fixed before 2.0.4 goes live:
[…snip…]
I also have a small patch to fix compilation when SDL_syswm.h is
included in modern Objective-C (or Objective-C++) code on OS X and iOS: https://bugzilla.libsdl.org/show_bug.cgi?id=2641
If this bug https://bugzilla.libsdl.org/show_bug.cgi?id=2500 could be
addressed prior to releasing 2.0.4 it would be great. It’s certainly
not a show stopper though! It has a couple of patches that could fix
the issue. I am willing to make any corrections, test and submit new
patches if that makes it easier.On Tue, Jul 15, 2014 at 1:23 PM, Sam Lantinga wrote:
Hey everyone, we’d like to release 2.0.4 early next month.
If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.
If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.
If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.
Seems to be broken on OpenBSD 5.5 right now. I just tried to compile SDL from hg:> Warning, configure.in is out of date
#(cd /root/SDL && sh autogen.sh && sh configure)
/bin/sh build-scripts/updaterev.sh
CC build/SDL_render_gl.lo
In file included from include/SDL_opengl.h:80,
from /root/SDL/src/render/opengl/SDL_render_gl.c:28:
include/SDL_opengl_glext.h:412: error: redefinition of typedef ‘PFNGLBLENDCOLORPROC’
/usr/X11R6/include/GL/gl.h:1739: error: previous declaration of ‘PFNGLBLENDCOLORPROC’ was here
include/SDL_opengl_glext.h:413: error: redefinition of typedef ‘PFNGLBLENDEQUATIONPROC’
/usr/X11R6/include/GL/gl.h:1740: error: previous declaration of ‘PFNGLBLENDEQUATIONPROC’ was here
/root/SDL/src/render/opengl/SDL_render_gl.c: In function ‘GL_CreateRenderer’:
/root/SDL/src/render/opengl/SDL_render_gl.c:493: warning: dereferencing type-punned pointer will break strict-aliasing rules
/root/SDL/src/render/opengl/SDL_render_gl.c: In function ‘GL_RenderDrawLines’:
/root/SDL/src/render/opengl/SDL_render_gl.c:1127: warning: declaration of ‘y1’ shadows a global declaration
/usr/include/math.h:233: warning: shadowed declaration is here
Makefile:399: recipe for target ‘build/SDL_render_gl.lo’ failed
gmake: *** [build/SDL_render_gl.lo] Error 1
Certainly not critical, but it would be useful if this behaved consistently
with the rest of the API.On Sun, Aug 10, 2014 at 7:41 AM, Alex Baines wrote:
There is no patch because even though the issue is extremely simple to fix (either TranslateMessage is removed and its behavior reproduced fully or ToUnicode is replaced with WM_CHAR handling), there’s the problem of me not knowing if either fix would break something. The original author of the change clearly had something in mind when WM_CHAR handling was partially replaced with ToUnicode and the related code, and if I could know what that was, I would most likely be able to make a patch myself.------------------------
SGScript scripting engine (http://www.sgscript.org)
You should need the ibus header file (from a package like libibus-dev),
a kernel compiled with inotify support (which you most likely have),
and also to compile SDL with DBus support (which should happen by default).
libibus-dev is installed on the Linux buildbots (as of right now), so
we’ll get some basic coverage on this code now.
SDL_WINDOW_FULLSCREEN produces a cropped window on Windows 8 w/ DPI scaling on above 100%. The test case is easy, just set 150% scaling in Windows settings, log out and log back in, run testgl2 included with SDL’s source, and press Ctrl+Enter to go fullscreen, and the drawing will be off-center.
Would be interested if it is just my computer or happens on other versions of Windows too.