Sam Lantinga | 1 Feb 03:00
Favicon

Re: About focusing out of a fullscreen game (alt-tab or minimize)

Starting a discussion on the wm-spec mailing list is a great idea.  I was thinking about doing that myself with respect to SDL 2.0 window management.


FYI, SDL 1.2 window management is not likely to change at this point.  For better or worse, it has pretty much been consistent for the last 10 years and I'm loathe to introduce changes to it at this point.

SDL 2.0 window management is completely different, and my goal for it is to embrace and create the next generation fullscreen window management for modern desktops.  To that end, I would love it if I and other people on this list can put our heads together and worked out the best way to do this, in collaboration with the window manager folks at freedesktop.org.

Cheers!

On Tue, Jan 31, 2012 at 2:53 PM, Karl <karl.glatzer <at> gmx.de> wrote:


Am 31.01.2012 19:49, schrieb Forest Hale:
> On 01/26/2012 04:13 AM, Sylvain Brunerie wrote:
>> 2012/1/20 Forest Hale <havoc <at> ghdigital.com <mailto:havoc <at> ghdigital.com>>
>>
>>     My own experience suggests the desired behavior in 99% of cases on Linux is the following:
>>     1. do not resize the desktop in any way (on Linux this tends to kill secondary monitors, and shuffle icons and windows around to fit the small space, both are very annoying).
>>     2. open a maximized window and request the window manager to make it borderless (there's an Atom to negotiate for this).
>>     3. grab mouse only, do not grab keyboard.
>>
>>
>> A maximized borderless window will still have panels (in any) under/over it, won't it?
>>
>> I agree with points 1 and 3, as I hate having my resolution changed and my desktop icons messed up when a game doesn't quit correctly, and as I don't see what could be prohibitive with not grabbing
>> the keyboard (this would allow Alt-F4 to close the window, Alt-F1 to open the Gnome Applications menu, but why not?). Not being able to change volume when in a fullscreen game may be, when I think of
>> it, the first issue preventing me to play games under Linux.
>
> #2 is only a clarification, it describes the current behavior.
>
> X11 allows a window to be created that is managed by the window manager (this is the normal kind) and that can then negotiate for an Atom asking for fullscreen (borderless, covers panel, etc).
>
> X11 also allows a window to be created that is NOT managed by the window manager, this kind is borderless by nature (without the window manager to add decorative window rects around it for
> interactivity), and CAN NOT receive keyboard or mouse events unless it grabs these input sources intentionally, which overrides the window manager shortcuts.

Yes this is how things work with X11, but this:

> As far as I understand it, SDL currently uses the managed type, and this is what I am saying we should stick to.

is only true for SDL 2.0. SDL 1.2 still uses windows which are not
(cannot be) managed by the window manager aka setting xoverride-redirect.

I tried to backport the SDL 2.0 window handling to SDL 1.2 and even send
a patch to Sam with an implementation that I thought was working.

Luckily he refused it and I now found out that my backport broke the old
behaviour which should be kept for window managers which don't support
the fullscreen atom and in addition the current implementation in SDL
2.0 also isn't sufficient because it will only work correctly with
XRandr mode switching.

The better XVidMode mode switching sadly can't be used reliably with
windows which are managed by the window manager.

I already have an Idea how to solve this. I think the best way would be
to add a new fullscreen method to the wm-specs on freedesktop.org which
gives more control over the window to the application and is closer to
the xoverride-redirect method in the way that it should be possible to
place the window anywhere (not restricted by panels) and on top of the
window stack when it is focused.

I have worked this out a lot more and will start a discussion about it
on the wm-spec mailing list of freedesktop.org soon.

Now to Keyboard Grabs: Yes they are really bad and i think sdl shouldn't
use them at all except for old window managers which don't support the
fullscreen atom. That's all i want to say about it now, but it
definitely needs to be discussed.

PS: I also think that the keyboard shortcut handling should be improved
possible by making another spec for it on freedesktop.org ;)
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Gabriel Jacobo | 1 Feb 14:06
Picon
Gravatar

Re: SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

2012/1/22 Sam Lantinga <slouken <at> libsdl.org>
Tell ya what... if somebody provides a fully working patch for all renderers including software, and all the filtering and scaling issues are resolved to the satisfaction of everyone on the list, I will either officially incorporate it into SDL_render or make it available as a recommended extension (crediting everyone involved, of course).

Remember, keep it simple, and it needs to be fast enough to be a viable API using the software renderer.

Here are some good places to start:

Cheers!



I've updated the RenderCopyEx patch at http://bugzilla.libsdl.org/show_bug.cgi?id=1308 , it now supports all renderers (including software). The software renderer functionality is implemented with lightly modified code taken from the SDL_gfx library (Zlib license acording to http://www.ferzkopp.net/joomla/content/view/19/14/ ). The total bloat coming from this incorporation is fairly small in my opinion (two functions to rotate 24 and 8 bit surfaces, one to precalculate a few values), and it is all kept in a separate file. The RenderCopyEx provides rotation around the center or arbitrary point, and flipping in both directions. The 24 bit software backend does nearest and bilinear interpolation as well.
Sam told me to submit the new patch to the list to see the repercusion it gets, after which he'll consider it for adoption...so, let us know what you think! 

Thanks!
 
--
Gabriel.
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Dimitris Zenios | 1 Feb 17:43
Picon

RGBA->RGBA blit error

It seems there is a bug when blitting RGBA->RGBA.The final surface is
always blank.

Attached is the test application and the image used

Best Regards
Dimitris Zenios
Attachment (main.c): text/x-csrc, 3345 bytes
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Dimitris Zenios | 1 Feb 17:50
Picon

RGBA->RGBA blit error

It seems there is a bug when blitting RGBA->RGBA.The final surface is
always blank.

Attached is the test application and the image used

Best Regards
Dimtiris Zenios
Attachment (main.c): text/x-csrc, 3345 bytes
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Rainer Deyke | 1 Feb 19:00

Re: SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

On 2012-02-01 14:06, Gabriel Jacobo wrote:
> I've updated the RenderCopyEx patch at
> http://bugzilla.libsdl.org/show_bug.cgi?id=1308 , it now supports all
> renderers (including software). The software renderer functionality is
> implemented with lightly modified code taken from the SDL_gfx library (Zlib
> license acording to http://www.ferzkopp.net/joomla/content/view/19/14/ ).
> The total bloat coming from this incorporation is fairly small in my
> opinion (two functions to rotate 24 and 8 bit surfaces, one to precalculate
> a few values), and it is all kept in a separate file. The RenderCopyEx
> provides rotation around the center or arbitrary point, and flipping in
> both directions. The 24 bit software backend does nearest and bilinear
> interpolation as well.

Wouldn't it make more sense to have a function to render arbitrary 
textured quads?  It's easy to implement rotation on top of arbitrary 
quads, but it's impossible to implement arbitrary quads on top of rotation.

--

-- 
Rainer Deyke (rainerd <at> eldwood.com)
RodrigoCard | 1 Feb 21:11
Picon

Drag n drop API linker error.

I got a linker error when building SDL in Xcode with the new drag n drop API enabled.
Since I was not using it I just commented the code and built it normally.

Now I want to take a look, but dont know what to do.
I need to include some framework or library I dont know?

thanks!
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
RodrigoCard | 1 Feb 23:48
Picon

Optional SDL 1.2 Key Repeat Behavior in 2.0 ?

I know I can check the repeat flag in the KEYDOWN event, but my case is more specific.
My loop looks somewhat like this:

while (running) {
SDL_WaitEvent(NULL);
while (SDL_PollEvent(&e)) {
// Handle Useful Events
}
updateStuff();
}

I basically I want to let the updateStuff() run only when there is events that matter for it, and I filter all the stuff I dont need before the main loop.
But SDL 2.0 keep firing KEYDOWN events (with repeat = 1), and updateStuff() is called needlessly.
in SDL 1.2 I can just disable key repeat and it works.
If I need to handle this case, it will complicate the code inside the while loop.

Is there any way to disable key repeat events currently?

Thanks
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Patrick Baggett | 2 Feb 00:01
Picon

Re: Optional SDL 1.2 Key Repeat Behavior in 2.0 ?

Looks like it was axed:   http://forums.libsdl.org/viewtopic.php?t=6182&sid=36762cb583d97488f7c5f01505f6ee95 


That having been said, it is trivial to modify your code to detect repeat events and not do anything when the repeat flag is set, e.g:


while (running) {
    bool update = false;

    SDL_WaitEvent(NULL);
    while (SDL_PollEvent(&e)) {
        if(!repeat_event)
            update = true;
    
    }

    if(update)
        updateStuff();
}

Patrick

On Wed, Feb 1, 2012 at 4:48 PM, RodrigoCard <cuecax <at> gmail.com> wrote:
I know I can check the repeat flag in the KEYDOWN event, but my case is more specific.
My loop looks somewhat like this:

while (running) {
SDL_WaitEvent(NULL);
while (SDL_PollEvent(&e)) {
// Handle Useful Events
}
updateStuff();
}

I basically I want to let the updateStuff() run only when there is events that matter for it, and I filter all the stuff I dont need before the main loop.
But SDL 2.0 keep firing KEYDOWN events (with repeat = 1), and updateStuff() is called needlessly.
in SDL 1.2 I can just disable key repeat and it works.
If I need to handle this case, it will complicate the code inside the while loop.

Is there any way to disable key repeat events currently?

Thanks

_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
JeZ-l-Lee | 2 Feb 00:45
Picon
Favicon

Re: JeZ+Lee's "TetriStory 2 100% A.I." - Super Project

www.TetriStory.com

URL Link To The Official Post On The Official SDL Forums:
http://forums.libsdl.org/viewtopic.php?t=7906
(for people in the mailing list)
________________________________________________________________________
"TetriStory 2 100% A.I." - PreAlphaFinal - Windows(R)/Linux Dual Build:
http://tetristory.com/files/PreAlpha/TetriStory2-PreAlphaFinal.zip
For ALL Windows(R) and ALL Linux desktops/notebooks/netbooks
( Linux requires: SDL 1.2/SDL_Mixer/SDL_Image/SDL_TTF(+dev libs), G++, OpenGL(R) )

UPDATED:
- Game engine shell completed(everything but playing is finished).
________________________________________________________________________

More to come! I'll update this post as we progress with development...



JeZ+Lee
JessePalser <AT> Gmail <DOT> com
16BitSoft(R)
Video Game Design Studio
www.16BitSoft.com
_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
RodrigoCard | 2 Feb 00:58
Picon

Re: Optional SDL 1.2 Key Repeat Behavior in 2.0 ?

well, too bad that is not so simple =/
I posted just a simple example of the outside loop.

Inside the while(poolevent) loop I pass the event to another function, which does not have access to the caller. I might need to modify other things, and make my code more coupled. I am even considering using a goto, so I wont need to increase the class coupling (right now it is what i am doing temporally).

I know it is not hard to fix, but it is ugly.


------

About the link: It is great that now it is handled by the OS, so much better than the old SDL_EnableKeyRepeat(), but I wish there was still a way to disable it =/

I will use the goto for while, if it becomes unpractical at some point, maybe I will try to patch sdl.

Thanks for the link anyway. \o








Patrick Baggett wrote:
Looks like it was axed:   http://forums.libsdl.org/viewtopic.php?t=6182&sid=36762cb583d97488f7c5f01505f6ee95 

That having been said, it is trivial to modify your code to detect repeat events and not do anything when the repeat flag is set, e.g:

while (running) {
    bool update = false;

    SDL_WaitEvent(NULL);
    while (SDL_PollEvent(&e)) {
        if(!repeat_event)
            update = true;
    
    }


    if(update)
        updateStuff();
}

Patrick

On Wed, Feb 1, 2012 at 4:48 PM, RodrigoCard wrote:







Quote:
I know I can check the repeat flag in the KEYDOWN event, but my case is more specific.
My loop looks somewhat like this:

while (running) {
SDL_WaitEvent(NULL);
while (SDL_PollEvent(&e)) {
// Handle Useful Events
}
updateStuff();
}

I basically I want to let the updateStuff() run only when there is events that matter for it, and I filter all the stuff I dont need before the main loop.
But SDL 2.0 keep firing KEYDOWN events (with repeat = 1), and updateStuff() is called needlessly.
in SDL 1.2 I can just disable key repeat and it works.
If I need to handle this case, it will complicate the code inside the while loop.

Is there any way to disable key repeat events currently?

Thanks


_______________________________________________
SDL mailing list

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

_______________________________________________
SDL mailing list
SDL <at> lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Gmane