Sdl 2.0.1 rc1

tehcloud · October 22, 2013, 7:44pm

http://forums.libsdl.org/viewtopic.php?t=9578

I’d like to see something like this included. It would be very helpful for me, and a lot of other people. The ability to SDL_CreateWindowFrom() using OpenGL would be a dream come true.

Gerry_Jo_Jellestad · October 22, 2013, 8:18pm

Den 22. okt. 2013 14:52, skrev Jonas Kulla:

I think this roots in the folder name “share”. If you look under
"/usr/share/" and “/usr/local/share"
you will find that it’s only ever application names, not “Gnome
Foundation/galculator” but just
"galculator”. I think that’s fine.

The things put in /usr/share are controlled by the distribution, and
/usr/local/share is mostly things you compile yourself, so if something
conflicts, you can fix it. Also, neither place is writable by users, so
you know at install time what’s going to be there. ~/.local/share is
used for writable data by binaries from all over.

I mean, collisions are rare, but they happen. There’s at least two open
source games called ‘enigma’, for example. Someone coming from Windows
wouldn’t know not to name their game about mimes ‘mime’ and collide with
the mime database. Or nautilus, or whatever some common program calls
itself in the future.

Consistency between platforms is good, too.

Oh, and passing in NULL for the org wouldn’t work as you would then lose
the correct behavior
where it does form the path, such as Windows.

If having organization dir is correct on Windows, why isn’t it on Linux?
I’ve seen both behaviors on both. There’s no reason for Linux to ignore
the org parameter by default, so why do it?

-g

Jonas_Kulla · October 22, 2013, 9:10pm

2013/10/22 Gerry JJ

Den 22. okt. 2013 14:52, skrev Jonas Kulla:

I think this roots in the folder name “share”. If you look under

“/usr/share/” and “/usr/local/share"
you will find that it’s only ever application names, not “Gnome
Foundation/galculator” but just
"galculator”. I think that’s fine.

The things put in /usr/share are controlled by the distribution, and
/usr/local/share is mostly things you compile yourself, so if something
conflicts, you can fix it. Also, neither place is writable by users, so you
know at install time what’s going to be there. ~/.local/share is used for
writable data by binaries from all over.

I mean, collisions are rare, but they happen. There’s at least two open
source games called ‘enigma’, for example. Someone coming from Windows
wouldn’t know not to name their game about mimes ‘mime’ and collide with
the mime database. Or nautilus, or whatever some common program calls
itself in the future.

Consistency between platforms is good, too.

Yeah, you have a fair point there. I tried to rationalize why it is done the
way it is now, but in the end these were things that were done long before
anyone decided what “the right way to do it” was, and so people either named
the folder after their organization or, more commonly, directly after their
product. Off topic, but one thing that has always irked me was when they
put spaces in their folder names urgh.

So yeah, the biggest problem is that there is little of what one would call
a defined standard (like with so many things on Desktop Linux), I think it’s
a wonder we even got to the point of XDG_* variables.

The only problem I see now is that SDL2 has already been released with this
function and changing the behavior now would probably catch a few people
unprepared. Maybe introduce a second function? I don’t know. I think you
should ask Ryan for the specifics as he’s the one that implemented the
function in the first place and also has over a decade experience in
shipping
closed source titles on Linux.

Oh, and passing in NULL for the org wouldn’t work as you would then lose

the correct behavior
where it does form the path, such as Windows.

If having organization dir is correct on Windows, why isn’t it on Linux?
I’ve seen both behaviors on both. There’s no reason for Linux to ignore the
org parameter by default, so why do it?

-g

Jonas

DJLink · October 22, 2013, 9:11pm

Hi everyone.
There is one bug I would like to see fixed in this version, regarding the SDL_SetWindowMode and SDL_SetWindowSize, which doens’t work properly when in fullscreen. Right now I have to set the Window to Windowed Mode, resize it and then set it back to fullscreen for it to work properly. But this causes some undesired overhead.

Bug Issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1742#

Regards,
David------------------------
@DJ_Link

www.david-amador.com

Justin_Skiles · October 22, 2013, 11:25pm

I tried using the new GetSystemRAM function, but it always returns 0 on my
machine.

Relevant system information is:

Time of this report: 10/22/2013, 19:23:45
Machine name: PC
Operating System: Windows 8.1 Pro 64-bit (6.3, Build 9600)
(9600.winblue_gdr.130913-2141)
Language: English (Regional Setting: English)
System Manufacturer: To Be Filled By O.E.M.
System Model: To Be Filled By O.E.M.
BIOS: BIOS Date: 06/29/12 21:05:02 Ver: 04.06.05
Processor: Intel® Core™ i5-2500K CPU @ 3.30GHz (4 CPUs), ~3.3GHz
Memory: 8192MB RAM
Available OS Memory: 8086MB RAM
Page File: 3226MB used, 6779MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 11
DX Setup Parameters: Not found
User DPI Setting: Using System DPI
System DPI Setting: 96 DPI (100 percent)
DWM DPI Scaling: Disabled
DxDiag Version: 6.03.9600.16384 64bit UnicodeOn Tue, Oct 22, 2013 at 5:11 PM, ^DJ_Link^ <david.djlink at gmail.com> wrote:

**
Hi everyone.
There is one bug I would like to see fixed in this version, regarding the
SDL_SetWindowMode and SDL_SetWindowSize, which doens’t work properly when
in fullscreen. Right now I have to set the Window to Windowed Mode, resize
it and then set it back to fullscreen for it to work properly. But this
causes some undesired overhead.

Bug Issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1742#

Regards,
David

@DJ_Link

www.david-amador.com

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

T_Joseph_Carter · October 23, 2013, 12:21am

Sam,

What solution have you got in mind for this? I offered the patch to
get the pointer, but you pointed out that creates problems, and I
agree with you.

JosephOn Tue, Oct 22, 2013 at 12:59:19AM -0700, Sam Lantinga wrote:

Yes, but not for 2.0.1. Are you just discarding the joystick pointer after
you open it?

On Mon, Oct 21, 2013 at 11:25 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

Can we get a way to close a joystick out of the data from the joystick
remove event? Or at least something to clean up easily?

T_Joseph_Carter · October 23, 2013, 12:34am

That one’s not gonna happen for 2.0.1, since that needs releasing and
we don’t actually have a patch for it, much less testing on it. At
least, not so far.

JosephOn Tue, Oct 22, 2013 at 07:44:10PM +0000, tehcloud wrote:

http://forums.libsdl.org/viewtopic.php?t=9578

I’d like to see something like this included. It would be very helpful for me, and a lot of other people. The ability to SDL_CreateWindowFrom() using OpenGL would be a dream come true.

slouken · October 23, 2013, 3:46am

SDL_UpdateYUVTexture() just allows you to update the texture without having
to make sure your Y, U, and V planes are in a contiguous block of memory.
It otherwise works just like the normal texture update function and you
would use it the same way with the same textures.

The only time this is advantageous is if your video decoder returns
separate YUV planes, and you can avoid a buffer copy. Otherwise it doesn’t
matter.On Tue, Oct 22, 2013 at 6:01 AM, Gabriele Greco <gabriele.greco at darts.it>wrote:

General:

Added an API to get common filesystem paths in SDL_filesystem.h:
SDL_GetBasePath(), SDL_GetPrefPath()

Great addictions! I’ll add some examples about SD_GetPrefPath in iOS and
Android and the other supported platforms not documented, since it’s not
obvious where the files are places on every platform, and it should be
since the programmer should be able to find the file he just wrote for
debugging purposes

I find GetBasePath() particulary helpful on OSX where I always have to add
some not-cross-platform “glue” to find the resources inside the application
bundle…

Added an API to do optimized YV12 and IYUV texture updates:
SDL_UpdateYUVTexture()

I’ve just updated the HG to head, and looking at the function
documentation in SDL_render.h I cannot understand if the preferred method
to update a LIVE YUV texture is using this function or allocating a
streaming texture in YUV format and updating it with lock/unlock surface.

I’m doing this way to update 24 CIF live H.264 videos in the same full HD
full screen window and works without a glitch (no frame skips) at 25fps on
a i5, using SDL_UpdateYUVTexture can I gain something or it’s better to
stick to the actual streaming surface code considering that I have to
update a lot of textures, and possibly 25 times per second?

iOS:

Fixed status bar visibility on iOS 7

Great, I was waiting for this to release the 1.1 version of my soccer
game

Android:
IMPORTANT: You MUST get the updated SDLActivity.java to match C code

Sigh, I find really annoying the fact SDLActivity changes in SDL require
changes to my application, I remember someone posted a method to avoid
"touching" SDL activity, but I don’t find the post, can someone give me a
pointer?

–
Bye,
Gabry

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

slouken · October 23, 2013, 4:10am

That’s a good question.

Maybe something like this between the table of contents and syntax?

||<tablestyle=“float:right;” style=“border: 0;”:>’’‘SDL 2.0.1’’’||

Let me know what you think? (I’m CC’ing the documentation list)On Tue, Oct 22, 2013 at 10:55 AM, Edward Rudd wrote:

On 10/22/2013 01:32 AM, Sam Lantinga wrote:

Hey everybody, we plan on releasing SDL 2.0.1 this week and would like
to get feedback on any regressions:
http://www.libsdl.org/tmp/download-2.0.php

[snip]

Awesome!!

BTW. What is the “official” way we are going to document these new
functions that are only available in 2.0.1+ (or in the future 2.1+ etc…)

For example I’ve started documenting the Filesystem functions here
http://wiki.libsdl.org/SDL_GetBasePath

–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

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

slouken · October 23, 2013, 4:13am

Well, in that case SDL will automatically clean up open joysticks when you
quit, and you shouldn’t need to worry about it.

SDL has an instance ID to automatically handle the hot-plug scenario, where
someone unplugs a joystick and plugs a new one in, so you can just handle
all joystick events without caring where they come from and it’s all good.
If you handle distinct joysticks differently, then you’d of course need to
update your internal state when a joystick is plugged and unplugged.On Tue, Oct 22, 2013 at 12:29 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2013/10/22, Sam Lantinga <@slouken>:

Yes, but not for 2.0.1. Are you just discarding the joystick pointer
after
you open it?

Yeah, because I just use the events themselves (which never use the
pointer).

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

slouken · October 23, 2013, 4:17am

Justin, can you file a bug report and include the contents of the stat
structure on your system?

        MEMORYSTATUSEX stat;
        GlobalMemoryStatusEx(&stat);

Thanks!On Tue, Oct 22, 2013 at 4:25 PM, Justin Skiles <justin.d.skiles at gmail.com>wrote:

I tried using the new GetSystemRAM function, but it always returns 0 on my
machine.

Relevant system information is:

Time of this report: 10/22/2013, 19:23:45
Machine name: PC
Operating System: Windows 8.1 Pro 64-bit (6.3, Build 9600)
(9600.winblue_gdr.130913-2141)
Language: English (Regional Setting: English)
System Manufacturer: To Be Filled By O.E.M.
System Model: To Be Filled By O.E.M.
BIOS: BIOS Date: 06/29/12 21:05:02 Ver: 04.06.05
Processor: Intel® Core™ i5-2500K CPU @ 3.30GHz (4 CPUs), ~3.3GHz
Memory: 8192MB RAM
Available OS Memory: 8086MB RAM
Page File: 3226MB used, 6779MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 11
DX Setup Parameters: Not found
User DPI Setting: Using System DPI
System DPI Setting: 96 DPI (100 percent)
DWM DPI Scaling: Disabled
DxDiag Version: 6.03.9600.16384 64bit Unicode

On Tue, Oct 22, 2013 at 5:11 PM, ^DJ_Link^ <david.djlink at gmail.com> wrote:

**
Hi everyone.
There is one bug I would like to see fixed in this version, regarding the
SDL_SetWindowMode and SDL_SetWindowSize, which doens’t work properly when
in fullscreen. Right now I have to set the Window to Windowed Mode, resize
it and then set it back to fullscreen for it to work properly. But this
causes some undesired overhead.

Bug Issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1742#

Regards,
David

@DJ_Link

www.david-amador.com

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

slouken · October 23, 2013, 4:21am

Alex, this is something we definitely want to fix and will look at post
2.0.1.On Mon, Oct 21, 2013 at 10:55 PM, Alex Szpakowski wrote:

Hey all - there’s a bug in SDL I’d really like to see fixed for 2.0.1, but
I don’t have the knowledge to create a patch for it. Perhaps someone else
does?

In Windows, if a window is fullscreen and SDL_SetWindowFullscreen(window,
SDL_FALSE) is called, the window will not properly resize to its original
resolution when going back to windowed mode.

A bugzilla report for it has been filed by another person already, and it
includes more detail about the cause of the bug:
https://bugzilla.libsdl.org/show_bug.cgi?id=2067

My apologies for cluttering the mailing list with this, I just really want
to see this feature working properly.

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

slouken · October 23, 2013, 4:22am

David, this is something we definitely want to fix and will look at post
2.0.1.On Tue, Oct 22, 2013 at 2:11 PM, ^DJ_Link^ <david.djlink at gmail.com> wrote:

**
Hi everyone.
There is one bug I would like to see fixed in this version, regarding the
SDL_SetWindowMode and SDL_SetWindowSize, which doens’t work properly when
in fullscreen. Right now I have to set the Window to Windowed Mode, resize
it and then set it back to fullscreen for it to work properly. But this
causes some undesired overhead.

Bug Issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1742#

Regards,
David

@DJ_Link

www.david-amador.com

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

slouken · October 23, 2013, 4:23am

Somebody modified SDL to get this working. I’ll reply to them again and
see if they have a patch post 2.0.1.On Tue, Oct 22, 2013 at 12:44 PM, tehcloud wrote:

**
http://forums.libsdl.org/viewtopic.php?t=9578

I’d like to see something like this included. It would be very helpful for
me, and a lot of other people. The ability to SDL_CreateWindowFrom() using
OpenGL would be a dream come true.

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

Sik_the_hedgehog · October 23, 2013, 8:09am

2013/10/23, Sam Lantinga :

Well, in that case SDL will automatically clean up open joysticks when you
quit, and you shouldn’t need to worry about it.

Except for the scenario where there keep being joysticks getting added
and removed, without closing those joysticks it becomes a memory leak
until the program closes (yes, I know the chances of this happening
are pretty much non-existent, but let’s not tempt fate, and also can
annoy with debugging tools that report leaks).

SDL has an instance ID to automatically handle the hot-plug scenario, where
someone unplugs a joystick and plugs a new one in, so you can just handle
all joystick events without caring where they come from and it’s all good.

Do events get reported at all if the joystick isn’t explicitly opened,
though? (added/removed aside, obviously)

Alberto_Luaces_Ferna · October 23, 2013, 9:28am

Sik the hedgehog writes:

SDL has an instance ID to automatically handle the hot-plug scenario, where
someone unplugs a joystick and plugs a new one in, so you can just handle
all joystick events without caring where they come from and it’s all good.

Do events get reported at all if the joystick isn’t explicitly opened,
though? (added/removed aside, obviously)

Not in my experience.–
Alberto

Sik_the_hedgehog · October 23, 2013, 10:14am

So… one still has to open them just to get the events, and keep
track of those pointers just to be able to close them in case the
joystick gets unplugged…

2013/10/23, Alberto Luaces :> Sik the hedgehog writes:

SDL has an instance ID to automatically handle the hot-plug scenario,
where
someone unplugs a joystick and plugs a new one in, so you can just
handle
all joystick events without caring where they come from and it’s all
good.

Do events get reported at all if the joystick isn’t explicitly opened,
though? (added/removed aside, obviously)

Not in my experience.

–
Alberto

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

Gabriele_Greco · October 23, 2013, 1:31pm

SDL_UpdateYUVTexture() just allows you to update the texture without
having to make sure your Y, U, and V planes are in a contiguous block of
memory. It otherwise works just like the normal texture update function
and you would use it the same way with the same textures.

The only time this is advantageous is if your video decoder returns
separate YUV planes, and you can avoid a buffer copy. Otherwise it doesn’t
matter.

Sorry Sam,

Let me understand better:

Actually I thought the best way to display video with SDL was:

Create a STREAMING texture
decode the frame
lock texture
copy my framedata into the “pixels” of the texture
unlock the texture

This will imply a data copy more than needed since I have to copy my
decoded frame (that I have to keep, to decode the following frame) to the
"shadow" texture allocated inside the hidden part of the SDL_Texture
structure, the pixels modified between lock/unlock are then sent to the
hardware through glTexSubImage2D or similar.

I’ve looked inside the renderer implementation and I’ve seen that using
SDL_UpdateYUVTexture will directly upload with three calls
of glTexSubImage2D my “decoded frame” to the real HW opengl texture(s)
without intermediate copy (I suppose there is a pixel shader that create a
single RGB color from the 3 differents Y U V textures), so my conclusion is
that:

For video output purpose there is no advantage in using a streaming texture
and low level lock/unlock over a “not streaming” yuv texture and
SDL_UpdateYUVTexture that is really the most performing way to do this kind
of operation.

Actually I’m trying to verify this modifying my h.264 “multiviewer” to
using this approach :)On Wed, Oct 23, 2013 at 5:46 AM, Sam Lantinga wrote:

–
Bye,
Gabry

Gabriele_Greco · October 23, 2013, 2:03pm

For video output purpose there is no advantage in using a streaming
texture and low level lock/unlock over a “not streaming” yuv texture and
SDL_UpdateYUVTexture that is really the most performing way to do this kind
of operation.

Actually I’m trying to verify this modifying my h.264 “multiviewer” to
using this approach

I’ve done some tests and I’ve found a bug in SDL_UpdateYUVTexture, if you
specify an SDL_Rect with the dimensions of the area to be updated the
texture is NOT updated, at least in the OpenGL backend, but if you specify
NULL in “rect”, the SDL_UpdateYUVTexture works and, with 24 video streams,
let me gain about 5% of CPU time (I suppose it is the time used in the copy
from the decoded buffer to the shadow buffer using STREAMING textures).
This is with a SDL_TEXTUREACCESS_STATIC texture, I’ve tried it also with
SDL_TEXTUREACCESS_STREAMING, but there is no performance difference and
there is an increased memory use.

So it seems that the best way to “stream” a texture is to update a static
texture after all :)–
Bye,
Gabry

Gabriele_Greco · October 23, 2013, 4:23pm

Android:
IMPORTANT: You MUST get the updated SDLActivity.java to match C code

Moved EGL initialization to native code

D/libEGL ( 704): Emulator without GPU support detected. Fallback to
software renderer.
D/libEGL ( 704): loaded /system/lib/egl/libGLES_android.so
I/ETW ( 704): Display size in inches: 3.33333x2, software destination
size: 532x320
E/libEGL ( 704): called unimplemented OpenGL ES API
W/libEGL ( 704): eglTerminate() called w/ 2 objects remaining
I/ETW ( 704): Error creating SDL renderer: Couldn’t find matching
render driver

It’s possible that the new native EGL code breaks the support of android
emulator (the stock android linux SDK one), I get this error on:

if (!(renderer = SDL_CreateRenderer(screen, -1, 0)))
D(bug(“Error creating SDL renderer: %s\n”, SDL_GetError()));

… I’ll try at home on OSX, where I remember the emulator used to run with
HW accel.–
Bye,
Gabry