SDL Digest, Vol 85, Issue 80

agoume_koufana_steph · January 25, 2014, 5:12pm

Mon niveau est bas en SDL
S’il vous plait
passez moi les documents qui pourront m’aider
Le 23 janv. 2014 18:35, a ?crit :> Send SDL mailing list submissions to

    sdl at lists.libsdl.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
or, via email, send a message with subject or body ‘help’ to
sdl-request at lists.libsdl.org

You can reach the person managing the list at
sdl-owner at lists.libsdl.org

When replying, please edit your Subject line so it is more specific
than “Re: Contents of SDL digest…”

Today’s Topics:

Re: Feasibility/correctness of calling GL in another thread
(slimshader)

Re: Feasibility/correctness of calling GL in another thread
(Stefanos A.)

Re: Feasibility/correctness of calling GL in another thread
(slimshader)

Re: OpenGL ES2 support on Windows (slimshader)

Message: 1
Date: Thu, 23 Jan 2014 12:46:46 +0000
From: “slimshader” <szymon.gatner at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Feasibility/correctness of calling GL in another
thread
Message-ID: <1390481206.m2f.41627 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Stefanos A. wrote:

After trying several threading strategies, my current preference is to
keep rendering and window management to the main thread, but handle input
on a secondary thread. So far, this has proven the best method to maintain
responsiveness without impacting compatibility.

But how that does help? If main thread is blocked, then you don’t refresh
your screen to show the impact of processed events. In my experience event
handling is tiny fraction of a frame. Do you mean that with 2nd thread
event handling you avoid “busy” system cursor / window appearing to hang?

Regarding D3D… I prefer to use ANGLE to get OpenGL ES 2.0 on systems
without proper OpenGL support. This way, I only need to maintain two
renderers: OpenGL everywhere and OpenGL ES for smartphones and (Windows &
~(Nvidia | AMD)).

This way, I can also use shaders across the board. ANGLE works all the
way down to GMA 950 (and probably GMA 500/Poulsbo, although I haven’t
tested that), so there’s very little reason to use the fixed-function
pipeline. Microsoft recently announced they will be working with Google to
port ANGLE on WinPhones and Metro, so D3D will be strictly unnecessary
going forward - as an indie developer, this suits me perfectly.
?

I had ANGLE on my radar but now you really got me interesting in this. I
am only really interested in 2 platforms: Win and iOS, this means I would
only need to maintain GL ES renderer. That would be great. Definitely going
to look into it.

-------------- next part --------------
An HTML attachment was scrubbed…
URL: <
http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140123/ec3f90f8/attachment-0001.htm

Message: 2
Date: Thu, 23 Jan 2014 15:27:08 +0100
From: “Stefanos A.”
To: SDL Development List
Subject: Re: [SDL] Feasibility/correctness of calling GL in another
thread
Message-ID:
<
CAJysdvoigr5NAKHp_mbm2PyU9QUwk4MXSnx4gS6xTarR5MqkMQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

2014/1/23 slimshader <szymon.gatner at gmail.com>

Stefanos A. wrote:

After trying several threading strategies, my current preference is to
keep rendering and window management to the main thread, but handle input
on a secondary thread. So far, this has proven the best method to
maintain
responsiveness without impacting compatibility.

But how that does help? If main thread is blocked, then you don’t refresh
your screen to show the impact of processed events. In my experience
event
handling is tiny fraction of a frame. Do you mean that with 2nd thread
event handling you avoid “busy” system cursor / window appearing to hang?

The point is not to improve performance but to minimize latency between the
user pressing a button and the world reacting to that button press.

If you handle input in your rendering thread, then any dip in the framerate
will increase input latency, which can be jarring (esp. on slower systems
that cannot maintain a stable framerate.) By spawning a separate thread for
input, the OS scheduler will “smoothen out” input latency even when your
framerate dips below 10 fps.

Of course, this only helps if your world update rate is decoupled from your
framerate. In my case, I will skip up to 12 frames in order to guarantee a
pseudo-fixed update rate. In other words, I prioritize world updates (60
updates/sec no matter what) and only render frames as a best-effort.

This way, if the player presses the “fire” trigger then she will shoot the
enemy immediately even if she is running at 5 fps.

If the input was handled in the same thread, then the “fire” button would
take up to 200ms to register - or it would be skipped completely, if the
player lifted her finger before the 200ms mark. This would place the player
at a severe disadvantage (hi, Diablo 3!)
-------------- next part --------------
An HTML attachment was scrubbed…
URL: <
http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140123/185bf98c/attachment-0001.htm

Message: 3
Date: Thu, 23 Jan 2014 17:31:25 +0000
From: “slimshader” <szymon.gatner at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Feasibility/correctness of calling GL in another
thread
Message-ID: <1390498285.m2f.41629 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Stefanos A. wrote:
2014/1/23 slimshader <szymon.gatner at gmail.com (szymon.gatner at gmail.com)>
Stefanos A. wrote:
After trying several threading strategies, my current preference is to
keep rendering and window management to the main thread, but handle input
on a secondary thread. So far, this has proven the best method to maintain
responsiveness without impacting compatibility.
But how that does help? If main thread is blocked, then you don’t
refresh your screen to show the impact of processed events. In my
experience event handling is tiny fraction of a frame. Do you mean that
with 2nd thread event handling you avoid “busy” system cursor / window
appearing to hang?

The point is not to improve performance but to minimize latency between
the user pressing a button and the world reacting to that button press.

If you handle input in your rendering thread, then any dip in the
framerate will increase input latency, which can be jarring (esp. on slower
systems that cannot maintain a stable framerate.) By spawning a separate
thread for input, the OS scheduler will “smoothen out” input latency even
when your framerate dips below 10 fps.

Of course, this only helps if your world update rate is decoupled from
your framerate. In my case, I will skip up to 12 frames in order to
guarantee a pseudo-fixed update rate. In other words, I prioritize world
updates (60 updates/sec no matter what) and only render frames as a
best-effort.

This way, if the player presses the “fire” trigger then she will shoot
the enemy immediately even if she is running at 5 fps.

If the input was handled in the same thread, then the “fire” button
would take up to 200ms to register - or it would be skipped completely, if
the player lifted her finger before the 200ms mark. This would place the
player at a severe disadvantage (hi, Diablo 3!)
Clean now

A question: I just tried to build minimal GL ES2 app under Win but I am
getting unresolved externals for glClear, glClearColor and 2 more in
sdl_main function. So it clearly wants to use full GL. I assume you use
SDL2 with ANGLE?

-------------- next part --------------
An HTML attachment was scrubbed…
URL: <
http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140123/8473452b/attachment-0001.htm

Message: 4
Date: Thu, 23 Jan 2014 17:35:19 +0000
From: “slimshader” <szymon.gatner at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] OpenGL ES2 support on Windows
Message-ID: <1390498519.m2f.41630 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

gabomdq wrote:

2013/11/23 Norfanin <norfanin at gmail.com (norfanin at gmail.com)>

Gabriel Jacobo wrote:

Enjoy!

Excellent!

I don’t have NVIDIA, Intel or ANGLE so I went with the AMD OpenGL ES
SDK. Worked beautifully.

The ANGLE workaround for WIN_GLES_SetSwapInterval gets in the way
though. Does ANGLE have some unique vendor string that could be used
to enable the workaround?

Thanks for your work on this.

?
Yeah, it might be worth looking into a way to detect if we are dealing
with ANGLE or a real EGL implementation, or at least have a hint to disable
the workaround.

–
Gabriel.

Could you please provide minimal GL ES2 code for Windows? I am getting
unresolved externals to glClear, glClearColor, glGetString and glViewport
from SDL_main. Does SDL have to be compiled in different way to add ES
support? I am trying to make it work with ANGLE

-------------- next part --------------
An HTML attachment was scrubbed…
URL: <
http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140123/d799c592/attachment.htm

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

End of SDL Digest, Vol 85, Issue 80