SDL_Surface hardware info?

Hi,

Does anyone have any information on the ‘private_hwdata’ structure in
SDL_Surface, which is not described in the documentation?
I’m looking for a way to determine if a stencil buffer is supported by
hardware, or if it would be emulated, if I requested one when initialising my
surface.

If this private_hwdata structure doesn’t reveal that sort of information, is
there any other way to query SDL about it? Or OpenGL?

Thanks,
Damian

Damian wrote:

Hi,

Does anyone have any information on the ‘private_hwdata’ structure in
SDL_Surface, which is not described in the documentation?
I’m looking for a way to determine if a stencil buffer is supported by
hardware, or if it would be emulated, if I requested one when initialising my
surface.

There’s nothing you can do with private_hwdata, really. It’s a pointer
to platform-dependent surface properties.
And no, it doesn’t contain stencil properties on any platform.

If this private_hwdata structure doesn’t reveal that sort of information, is
there any other way to query SDL about it? Or OpenGL?

Using SDL ? No. Neither using OpenGL. It’s platform-dependent.

Under windows you have to read the context bits in a struct whose name I
don’t remember (that’s a faq on c.g.a.opengl)
Under linux you have to query the glx visual caveats.

It’s true that this could be a nice addition to SDL.

Stephane

Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:

If this private_hwdata structure doesn’t reveal that sort of information, is
there any other way to query SDL about it? Or OpenGL?

Using SDL ? No. Neither using OpenGL. It’s platform-dependent.

Under windows you have to read the context bits in a struct whose name I
don’t remember (that’s a faq on c.g.a.opengl)
Under linux you have to query the glx visual caveats.

It’s true that this could be a nice addition to SDL.

Well, thanks anyway.

Guess I’ll have to find platform-specific calls to test for it, and use
#ifdef… etc to include each platform’s specific code.
That’s not too bad, if it works. And maybe Sam will throw it in, in a future
version of SDL. :wink:

Thanks for the help.

Damian

Damian wrote:

Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:

If this private_hwdata structure doesn’t reveal that sort of information, is
there any other way to query SDL about it? Or OpenGL?

Using SDL ? No. Neither using OpenGL. It’s platform-dependent.

Under windows you have to read the context bits in a struct whose name I
don’t remember (that’s a faq on c.g.a.opengl)
Under linux you have to query the glx visual caveats.

It’s true that this could be a nice addition to SDL.

Well, thanks anyway.

Guess I’ll have to find platform-specific calls to test for it, and use
#ifdef… etc to include each platform’s specific code.
That’s not too bad, if it works. And maybe Sam will throw it in, in a future
version of SDL. :wink:

If you want, we can tackle it now. I’m very intersted in having that
feature too.

Stephane

Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:

Guess I’ll have to find platform-specific calls to test for it, and use
#ifdef… etc to include each platform’s specific code.

If you want, we can tackle it now. I’m very intersted in having that
feature too.

Thanks for the offer.
I’ve looked into the Windows side of it (knowing nothing about Linux), and it
seems that Direct3D has the means to test for hardware stencil as follows:

(DX9 example, but DX7/8 would probably be similar)

// Reject devices that cannot perform 8-bit stencil buffering. 
// The following example assumes that pCaps is a valid pointer 
// to an initialized D3DCAPS9 structure. 

if( FAILED( m_pD3D->CheckDeviceFormat( pCaps->AdapterOrdinal,
                                       pCaps->DeviceType,  
                                       Format,  
                                       D3DUSAGE_DEPTHSTENCIL, 
                                       D3DRTYPE_SURFACE,
                                       D3DFMT_D24S8 ) ) ) return E_FAIL;

If SDL uses Direct3D on Windows (which I assume it does) the CheckDeviceFormat
function might already be used for other things, and it might be simple to add
an extra check for the stencil.

Where would you put it though? As an extra attribute on SDL_Surface? What about
some sort of flag (hw_flags?) so that any other hardware things can be added in
the future without changing the structure again?
It might be stating the obvious, but Sam should probably be consultated to make
sure it fits into his long-term vision of SDL.

I don’t know anything about the SDL source, and (to be frank) i find the whole
CVS thing very confusing. Since i moved to SDL i’ve been content to treat it as
a black box and concentrate on my own apps.
In other words, the above code is probably the most help i can offer in this.

Regards,
Damian

Damian <damian_rajkowski technologyonecorp.com> writes:

If SDL uses Direct3D on Windows (which I assume it does) the
CheckDeviceFormat
function might already be used for other things, and it might be simple to
add
an extra check for the stencil.

I shouldn’t have said that. What I meant was:

If SDL uses Direct3D on Windows the enhancement might be trivial.

But, having noticed the front SDL page again, I realise that SDL probably
uses only OpenGL to remain portable, which is good.
So the addition of Direct-X check above might involve adding various Direct-X
libraries to the build, which would blow out dll sizes with little added
benefit.

Damian

Damian wrote:

If SDL uses Direct3D on Windows (which I assume it does)

SDL uses DirectDraw on Windows, and GDI if DirectDraw isn’t available. No
Direct3D, no OpenGL (unless you specifically request OpenGL, in which case
you need to make direct OpenGL calls, because the 2D graphics API no longer
works).

–?
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

Hi Rainer,

If SDL uses Direct3D on Windows (which I assume it does)

SDL uses DirectDraw on Windows, and GDI if DirectDraw isn’t available. No
Direct3D, no OpenGL (unless you specifically request OpenGL, in which case
you need to make direct OpenGL calls, because the 2D graphics API no longer
works).

Ah, of course. Disregard my previous post, i’m not with it today.

I think i was thinking that D3D was somehow used underneath to initialise
surfaces, but actually DirectDraw/GDI would take care of that, wouldn’t it?
(Of course OpenGL isn’t used to initialise surfaces - what was i thinking?!)

So, the CheckDeviceFormat() function, which seems to be a method of D3D, would
required D3D to be included and initialised, and would incur extra cost in dll
size and loading time just to test one feature - not be a trivial addition.

Thanks for the help,

Damian

Damian wrote:

But, having noticed the front SDL page again, I realise that SDL probably
uses only OpenGL to remain portable, which is good.
So the addition of Direct-X check above might involve adding various Direct-X
libraries to the build, which would blow out dll sizes with little added
benefit.

Yup, SDL uses OpenGL for 3D (or rather, it lets you use OpenGL yourself).

I’ve started investigating the detection of slow OpenGL visuals. Under
windows, you seem to have to use WGL_ARB_pixel_format and under X you
want to use GLX_EXT_visual_rating.

What do people think of extending SDL_GL_GetAttribute with a new
read-only attribute, for example SDL_GL_SLOW_VISUAL ?
For example we could return 1 when the visual is slow, 0 when it isn’t,
and -1 when we don’t know.

Also, does anyone know how to get this information on other platforms ?

Stephane