[gameprogrammer] Re: SDL 2.0

On Fri, 2004-11-05 at 11:32, Stephane Marchesin wrote:
> Bob Pendleton wrote:
> 
> >>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).
> >
> You seem to be joking about this, but I really think that rotation 
> support would be a neat thing to have.

I was not joking.

> The problem is really that if it's done by an external library, it can't 
> be hardware accelerated, unless (and that could be another idea) SDL 
> exposes an API to plug in your own platform-dependent accelerated 
> extensions.

I understand your point, read what I said above as being serious and you
will see we are in complete agreement.

> OTOH if you implement rotating blits inside SDL you get the chance of 
> being able to use HW acceleration for these features.
> 
> >>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.
> >
> I was thinking about 2D X11 Vsync. OpenGL vsync is trivially achieved 
> using platform-dependent extensions.

Yeah, that is a problem. Take a look at the X11 double buffer extension.
A good server will implement that using vsync. That means you get good
animation without having to worry about vsync in your own code.

And, of course, that is my point, the lower level code will use vsync if
it can *and* if the customer wants it to. 

> >
> >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?
> >
> With todays hardware, the problem is to be sure stencil buffers are 
> accelerated.
> But newer video drivers for example introduce floating point visuals, 
> which are only accelerated with the newest cards (Geforce 6800 and ATI 
> equivalent).
> We are interested in knowing whether these visuals are accelerated or 
> not. And such an API extension solves this problem once again.
> 
> Well, my point is : in the future, other visual features will surely 
> appear. But the problem of whether they are accelerated still remains.

Yeah, I see your point. I would ask Sam, privately, about the idea and
then submit a proposed API. If he likes it he will include your patches
when the code is ready.

> 
> >>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? 
> >
> Heh. I want the best thing that's available, hw acceleration first, and 
> sw fallback else.
> Btw, I have a hacked mesa solo implementation which does offscreen 
> rendering :)

And by "off screen" you mean? Please, in my world "off screen" rendering
has a specific technical meaning. What does it mean in yours and what
are you asking to be added to SDL to support it?

                Bob Pendleton

> 
> Anyway, I really think this last one is too far fetched for SDL.
> 
> 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: