[gameprogrammer] Re: SDL 2.0

On Thu, 2004-11-04 at 13:19, Stephane Marchesin wrote:
> 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

Thank you kind sir! That is where I would have looked, but it is so much
easier to ask someone who already knows the answer!

> 
> >
> >
> >>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.

Ok, I'll grant you that. I would like a blit with both an scaling and
rotation in SDL without OpenGL. I would also like to have a choice of
several different ways of doing the scaling, pixel replication, bilinear
interpretation, and biquadratic interpolation. Those would give you the
choice between speed (for games) and quality (for image processing).

> 
> >
> >>- 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.

Yes, and that is pretty much the way it has to be. I don't see the value
adding a feature like that, but I'm not going to tell you not to work on
it. :-)

> Now AFAIK, standard X11 can't do vsync. Maybe there's an extension out 
> there for that, though...

Standard X11 can't do 3D, unless you are into PEX... There is nothing
about X11 that stops a 3D driver from using vsync. 3D acceleration works
"around" the X server. It coordinates with the X server for screen
space, but then pretty much punches a hole through the server and can do
what ever it wants. In fact, if the X server is implemented using
multiple buffers the server may well use vsync to coordinate swapping
the desktop. I implemented an X server that worked that way 15 years
ago.

> 
> >
> >>- 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.

Oh! Yes, of course. I see why you want that feature. But, I have to
wonder how long this will be a problem. I see very nice video cards
selling for less that $20 dollars all the time. What is the expected
useful life time of this feature?

> 
> >
> >>- 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...

I find this answer to be confusing. To me off screen buffers reside in
the video system where the rendering hardware can access them, but are
not the current video buffer. In one case you are using off screen
buffers (pbuffers), in another you are using the frame buffer but not
off screen memory, and in another you are using system memory. Which do
you really want? 

                Bob Pendleton 

> 
> Stephane
> 
> 
> 
> 
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
> 
-- 
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx             +
+ blog:  www.Stonewolf.net             +
+ web:   www.GameProgrammer.com        +
+--------------------------------------+



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

Other related posts: