[gameprogrammer] Re: SDL 2.0

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

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

>>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 :)

Anyway, I really think this last one is too far fetched for SDL.

Stephane




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

Other related posts: