[SDL] Re: VC7, and 2D+3D, and blit performance

[Timo K Suoranta]

I'm replying to a digest to excuse me for sillyness in this mail..

> > The first thing I did was rebuild the libs/dlls with VC7. Before I did a
> > clean, it said "SDL - up-to-date" which means it doesn't look like there is

There could be a problem with structure alignment. Try to modify the SDL
and SDLmain project settings so that they do have the 4 byte alignment
which SDL wants. I once had weird crashes when the byte alignment was not
set correctly from the project settings.

BTW., why does SDL want 4 byte alignment for structures? And why is this
not set in project settings for SDL, even thought that has been asked a
several time. Another change to VC project settings would be to rename the
debug DLL to SDLD.DLL, or SDL_g.DLL.

Also try deleting all .ncb files (while not running VC).

> Well I downloaded the Visual Studio .NET SDK (the free version of VC7 from
> Microsoft) and here is what I came up with.

What things does the SDK contain and what limitations does it have?

> First of all I used libs compiled by VC6, because I could not find a makefile
> interpreter for VC7.

No support for project files in the SDK?

> > is there a way to check whether the SDL-surface actually uses hardware
> > acceleration or not?
>
> Yes - this is in the documentation. Search in the 'video' section and
> read the various function docs until you see what you need. I think it's
> to do with the pixel format of the screen surface, but you can easily
> find this out.

This might not work for OPENGL surfaces I think?

> ...and 800x600 @ 32-bit is going to be slow on hardware accelerated
> surfaces, too. If you need this, use OpenGL, but more likely, you don't
> need it.

This certainly makes me think that there should be more opengl baseness in
SDL in the future. But 16-bit should do most of the time though.

> So perhaps gluLookAt may be a bit faster. I doubt it is easier for most
> though. Also, you can increase the glOrtho performance if you build the
> ortho view once and keep it stored in memory. For gluLookAt you'd have to
> calculate it at least each time the camera changes position / angle.

FYI, both gluLookAt() and glOrtho() do some calculaons and then set up a
view matrix. Both are quite short and need only a few dozen mathemathical
operations. Neither of them are implemented in hardware AFAIK even on
hardware accelerated cards for PC. The maths are more complex for
gluLookAt(), but if you switch from 3D to 2D only once per frame, it
certainly makes no difference in fps at all.

> So when an OpenGL display mode gets initialized, all SDL hardware surfaces
> should be created as 2D textures and blits would be done with textured
> quads. Software surfaces should stay in system memory and be copyed into
> textures when blitting.
...
> That's what I have in mind too. Making OpenGL a backend (or target) just
> like X11, svgalib or fbcon.

Actually I think there should be some changes, maybe a whole different
library, for SDLonOpenGL. A lot of SDL is not needed when using SDL for
OpenGL only, and some other things are. IMHO the whole philosophy for
hardware accelerated 2D through OpenGL is quite different from current SDL
philosphy.


-- Timo Suoranta -- tksuoran at cc.helsinki.fi --