I have been developing an application that uses overlay surfaces under
SDL with MSVC 6 using the DirectX 5.0 target. My application only uses
overlay surfaces if it can get hardware acceleration. I have encountered
several problems with overlay surfaces as accessed through SDL in a
windowed application, namely:
- seemingly no SDL way to ‘hide’ overlay surfaces (i.e. access to
DDOVER_HIDE for my target), so no way to write an application that can
be minimised - overlay surfaces are not obscured by overlapping windows (seems that
destination colour keying is not in use?) - if the SDL window is dragged even slightly off the edge of the screen,
the overlay simply fails to move at all from the position of the window
pre-dragging (it seems SDL is quite thick about source rectangles?)
Also, I am unhappy with the way that it seems there is no way to
discover what overlay surfaces will be hardware accelerated without
creating them and checking.
But besides all this, I was essentially happy, having restricted my
application to only considering overlay surfaces if in full screen mode.
This was under SDL 1.2.5. As I considered the latter two of my bullet
pointed remarks might well be bugs I upgraded to SDL 1.2.7.
Under 1.2.7 I have a much greater problem - the same code on the same
hardware and operating system now fails at SDL_DisplayYUVOverlay every
time, returning -1. Also, as of 1.2.7, SDL seems to have discovered some
way to use accelerated overlay surfaces on my hardware where it could
not before - namely in high resolution and high colour depth displays
where video memory is very tight.
Having glanced into the sources, this seems to be because at some stage
the define at line 38 of SDL_dx5yuv.c has been commented out so that
hardware overlay surfaces are never attempted under DirectX. Other than
that there haven’t been any functional changes.
As there is nothing whatsoever in the change log related to YUV overlays
under DirectX, can I assume this was a simple oversight? If not, can I
instead assume that in future the DirectX driver will not claim to have
a hardware overlay surface when it hasn’t (as presently at line 185)?
Also, is there likely to be any change to any of the other issues I have
faced in the near future?
Also, as I notice from reading the code that only 1x blitting and 2x
blitting are supported for software overlay surfaces, perhaps the
sentence in the doc project “If the dstrect is a larger or smaller than
the overlay then the overlay will be scaled, this is optimized for 2x
scaling.” should be adjusted?
On a tangential note, I consider it unsatisfactory if I have to enable
hardware overlays for myself and therefore build an sdl.dll which is
different to everyone else’s - to save myself a few minutes does anybody
have a workspace that produces a statically linking version of SDL?
-Thomas
