What is the reason why the inner wait-for-everything-function
(SDL_WaitEvent) uses polling and not select or equivalent
(MsgWaitForMultipleObjects for windows)? The decision to not use
select creates some shortcomings:
polling in the inner wait function
no real support for network sockets
limitations of the timers: only one timer is supported or threads
has to be used (which create a whole bunch of other problems)
Not using select has IMHO some drawback and it would be nice if
someone can explain to me what are the benefits of not using it.
Raimar--
email: @Raimar_Falke
"I was dead … but I’m better now."
– Capitain Sheridan in Babylon 5
What is the reason why the inner wait-for-everything-function
(SDL_WaitEvent) uses polling and not select or equivalent
(MsgWaitForMultipleObjects for windows)? The decision to not use
select creates some shortcomings:
polling in the inner wait function
no real support for network sockets
limitations of the timers: only one timer is supported or threads
has to be used (which create a whole bunch of other problems)
Not using select has IMHO some drawback and it would be nice if
someone can explain to me what are the benefits of not using it.
Portability. Basically UNIX is the only platform with a fully functioning
file descriptor model, and no windowing system besides X11 uses sockets for
message transport.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
That may be true but I think the wrong abstraction was choosen
here. If select or equivalent function is available and the windowing
system can be used together with it select or equivalent function
should be used. This will cover at least X11 and win32. In the other
cases you can fall back to polling.
RaimarOn Fri, Mar 14, 2003 at 01:10:41AM -0800, Sam Lantinga wrote:
What is the reason why the inner wait-for-everything-function
(SDL_WaitEvent) uses polling and not select or equivalent
(MsgWaitForMultipleObjects for windows)? The decision to not use
select creates some shortcomings:
polling in the inner wait function
no real support for network sockets
limitations of the timers: only one timer is supported or threads
has to be used (which create a whole bunch of other problems)
Not using select has IMHO some drawback and it would be nice if
someone can explain to me what are the benefits of not using it.
Portability. Basically UNIX is the only platform with a fully functioning
file descriptor model, and no windowing system besides X11 uses sockets for
message transport.
Someone ported an OpenGL driver to fbdev, but it’s still highly
experimental stuff, AFAIK.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 14 March 2003 15.32, Adilson Oliveira wrote:
Hi there.
Is there anyway to run OpenGL over, say, framebuffer?
That may be true but I think the wrong abstraction was choosen
here. If select or equivalent function is available and the windowing
system can be used together with it select or equivalent function
should be used. This will cover at least X11 and win32. In the other
cases you can fall back to polling.
We’re considering something like that for SDL 2.0, but we have to consider
input coming from many different sources, including user messages posted
directly from the application.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
That may be true but I think the wrong abstraction was choosen
here. If select or equivalent function is available and the windowing
system can be used together with it select or equivalent function
should be used. This will cover at least X11 and win32. In the other
cases you can fall back to polling.
We’re considering something like that for SDL 2.0,
So SDL 1.2 won’t be changed?! When will SDL 2.0 be published?
but we have to consider input coming from many different sources,
including user messages posted directly from the application.
Yes you have to add a “loopback” socket/pipe which is used to notify
the select about new “internal” events. Not hard to code and
transparent for the user code.
RaimarOn Sat, Mar 15, 2003 at 07:33:02PM -0800, Sam Lantinga wrote:
–
email: @Raimar_Falke
"This is Linux Country. On a quiet night, you can hear Windows reboot."
SDL 2.0’s release date is unknown as sam just announced yesterday, gotta
remember he has a job and that his work on SDL is voluntary, and besides
that i bet he has a life too (wow! how dare he!!), so try not to be too hard
on him > ----- Original Message -----
From: rf13@inf.tu-dresden.de (Raimar Falke)
To:
Sent: Sunday, March 16, 2003 6:34 AM
Subject: Re: [SDL] Why not use select?
On Sat, Mar 15, 2003 at 07:33:02PM -0800, Sam Lantinga wrote:
That may be true but I think the wrong abstraction was choosen
here. If select or equivalent function is available and the windowing
system can be used together with it select or equivalent function
should be used. This will cover at least X11 and win32. In the other
cases you can fall back to polling.
We’re considering something like that for SDL 2.0,
So SDL 1.2 won’t be changed?! When will SDL 2.0 be published?
but we have to consider input coming from many different sources,
including user messages posted directly from the application.
Yes you have to add a “loopback” socket/pipe which is used to notify
the select about new “internal” events. Not hard to code and
transparent for the user code.
Raimar
–
email: rf13 at inf.tu-dresden.de
"This is Linux Country. On a quiet night, you can hear Windows reboot."
SDL 1.2 is API frozen, but I’m happy to accept patches that don’t
affect binary compatibility.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Sat, Mar 15, 2003 at 07:33:02PM -0800, Sam Lantinga wrote:
That may be true but I think the wrong abstraction was choosen
here. If select or equivalent function is available and the windowing
system can be used together with it select or equivalent function
should be used. This will cover at least X11 and win32. In the other
cases you can fall back to polling.
We’re considering something like that for SDL 2.0,
So SDL 1.2 won’t be changed?! When will SDL 2.0 be published?
To get access to a key advantage of select (the native network
support) the API needs to be extended. The SDL equivalent of
gdk_input_add / XtAppAddInput needs to be added. And also the
corresponding remove function.
Is this possible?
RaimarOn Sun, Mar 16, 2003 at 03:21:17PM -0800, Sam Lantinga wrote:
On Sat, Mar 15, 2003 at 07:33:02PM -0800, Sam Lantinga wrote:
That may be true but I think the wrong abstraction was choosen
here. If select or equivalent function is available and the windowing
system can be used together with it select or equivalent function
should be used. This will cover at least X11 and win32. In the other
cases you can fall back to polling.
We’re considering something like that for SDL 2.0,
So SDL 1.2 won’t be changed?! When will SDL 2.0 be published?
SDL 1.2 is API frozen, but I’m happy to accept patches that don’t
affect binary compatibility.
–
email: @Raimar_Falke
"Sit, disk, sit. Good boy. Now spin up. Very good. Here’s a netscape
cookie for you. Fetch me some data. Come on, you can do it. No, not that
data. Bad disk. Bad."
– Calle Dybedahl, alt.sysadmin.recovery
Hmmm… interesting… it says there’s no hardware acceleration for
OpenGL but it does for framebuffer with direct binding on SDL.
So I can have a accelerated framebuffer on selected cards. It that
right? Does anyone here tried to execute a SDL application on
framebuffer using veasfb and then directfb and can tell anything about
performance? I’ll try later, of course but the more opinions, the better
[]s and thank you.
Adilson.–
Existem 10 tipos de pessoas no mundo: as que entendem numera??o bin?ria
e as que n?o.
I think everyone is missing the point that dri can be used by anything.
DRI isnt apart of X, at all. Except no one has written non-X bindings
for DRI, which means until someone does, you cant use it outside of X.
Berlin most likely will end up with DRI bindings, however.On 17-Mar-2003, Adilson Oliveira wrote:
Hmmm… interesting… it says there’s no hardware acceleration for
OpenGL but it does for framebuffer with direct binding on SDL.
So I can have a accelerated framebuffer on selected cards. It that
right? Does anyone here tried to execute a SDL application on
framebuffer using veasfb and then directfb and can tell anything about
performance? I’ll try later, of course but the more opinions, the better
–
Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
In fact there is “embedded”-branch in the DRI cvs, and you can find hardware
accelerated OpenGL drivers for Radeon 8500 (r200-chipset) from there… I
think they are using framebuffer (or directfb)…
So there are non-X bindings available
– Pasi K?rkk?inen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.On Mon, Mar 17, 2003 at 09:20:33PM -0500, Patrick McFarland wrote:
Hmmm… interesting… it says there’s no hardware acceleration for
OpenGL but it does for framebuffer with direct binding on SDL.
So I can have a accelerated framebuffer on selected cards. It that
right? Does anyone here tried to execute a SDL application on
framebuffer using veasfb and then directfb and can tell anything about
performance? I’ll try later, of course but the more opinions, the better
I think everyone is missing the point that dri can be used by anything.
DRI isnt apart of X, at all. Except no one has written non-X bindings
for DRI, which means until someone does, you cant use it outside of X.
Berlin most likely will end up with DRI bindings, however.
