[gameprogrammer] Re: SDL 2.0

Bob Pendleton wrote:

>On Wed, 2004-11-03 at 19:07, Stephane Marchesin wrote:
>
>>Well, I'm a linux user so I'm mostly working on linux/x11. However I can 
>>stand a little windows from time to time (and I have a cross compiling 
>>environment with wine just in case :).
>>
>
>Can you point me at a tutorial for setting up a cross development
>environment like you have set up? I was thinking I was going to need
>that just yesterday.
>
Guess what - there are ready to use scripts at libsdl.org :
http://www.libsdl.org/extras/win32/cross/README.txt

>
>
>>Now for the features, what about asking on the SDL mailing list ? Here 
>>are my ideas :
>>- multi window is asked for a lot, but it's not the easiest of the pack
>>
>
>I'm working on that for X11. It is not easy. The SDL code base has
>*many* places where a single window assumption is made by the code. I've
>been working on this for 3 weeks and I'm not sure I even know how to
>start. I'm doing some experiments to find out if what I think is true,
>is true :-)
>
>>- a stable blit scaling interface
>>
>
>Isn't that what OpenGL is for?
>
Well, if you don't have OpenGL, or don't want to depend on it, you're 
happy to find a reasonable performance sw scaler.
In fact, there is currently an undocumented function in SDL - 
SDL_SoftStretch.
Some programs already use it even if it isn't documented. The idea is to 
find and implement a clean scaled blit interface for this before eveyone 
uses it.

>
>>- vsync support
>>
>
>I'm not sure that is technically possible. Anyway, SDL is designed to
>work with vsync when it is there and to work without it when it isn't
>there. I had a long discussion with Sam on that subject. The result of
>the discussion is written up in one of my articles. 
>
I think vsync support should be optional. Like SDL_EnableVsync or such.
The current situation is really a compromise on what most platforms 
can('t) do.
Now AFAIK, standard X11 can't do vsync. Maybe there's an extension out 
there for that, though...

>
>>- something I have working on linux & windows already to detect whether 
>>the current OpenGL visual has performance caveats. More generally, since 
>>an increasing number of apps will make use of OpenGL in the future, I 
>>think it would be nice if we can help these by supporting this kind of 
>>small low level things (OpenGL vsync falls in the same category).
>>
>
>I've never run into a case where I the visual caused problems. Can you
>give me an example? 
>
Ok. Let's say you want to use "special" OepnGL features that might or 
might not be accelerated (namely : stencil buffers, accumulation buffers).
Some card/drivers/bpp combinations switch to software emulation mode 
when you ask for a stencil buffer. This usually results in unbearable 
slowdowns. So if the program is aware of that, he'd better not ask for 
these visuals and disable the feature(s) that uses the stencil buffer. 
For example, switch stencil shadows for another type of shadows.

>
>>- OpenGL-es integration (maybe make it more or less transparent ?)
>>
>
>I don't know enough to understand what you mean here. Do you mean that
>you want the same level of support for OpenGL ES as we currently have
>for OpenGL? I would think it could be done by writing the platform
>specific code to use OpenGL ES instead of OpenGL. 
>
Yes, that's what I meant. It doesn't seem trivial, though, since 
OpenGL-es covers more than standard OpenGL.

>
>If the difference runs deeper then that you could build a parallel set
>of software to support OpenGL ES on platforms that support it. It would
>just get built in the way OpenGL is now built in. Sounds like a lot of
>tedious coding but not a serious technical problem. 
>
>>- I would be very interested in a generic offscreen buffer support (not 
>>a render to texture thing like in SDL 1.3, but really offscreen 
>>buffers). 
>>
>
>Why? What is the application? Can't you get what you want just by using
>Mesa as your OpenGL implementation?
>
Hmm. I work on parallel visualization systems. On such systems, you 
usually render to offscreen buffers on multiple machines, and the 
composite the buffers from each node to one master node for compositing. 
Now getting such code portable while trying to use hardware acceleration 
is a headache. I currently use different solutions :
- pbuffers as provided by nvidia/ati linux drivers
- the free dri drivers for radeon with mesa solo, an implementation of 
OpenGL over the framebuffer
- MesaOS, a special version of Mesa that renders everything offscreen 
but using software emulation, and thus is slow.
A neat thing would be to unify ways to access offscreen buffers on these...

Stephane




---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: