Hello everyone. I’ve been compiling CVS versions of libsdl for a few months
using MinGW32/MSYS so that I may use them with CVS versions of DOSBox. I have a
few questions for anyone that might know the answers:
-
Is an automatically-updated CVS changelog for SDL available somewhere? I can’t
seem to find one, but I’d like to keep up with the changes.
-
Which is currently being more actively developed: the 1.3.x branch or the 1.2
tree? Some people compile from one and some the other, so I am confused as to
which should have the latest development changes.
-
Why are hardware directdraw surfaces and hardware overlays disabled by default
in the windx5 code to the point that they require code modifications to be
enabled? If I enable hardware directdraw surfaces, directdraw seems to be a lot
faster in DOSBox.
-
Enabling hardware overlays does seem to be slower in DOSBox. Regardless of
whether SDL is set to use hardware or software overlays, DOSBox doesn’t seem to
actually be using the same type of hardware overlay that, say, Media Player
Classic and Winamp use when playing video files - why is this? I’d guess it’s a
DOSBox issue, except that I notice a difference in performance when I enable
hardware overlays in the SDL source, so I know DOSBox is actually using SDL
overlays and not something else when I expect it to.
-
Is there a configure parameter that I can specify to have the SDL.dll get
stripped automatically so that I don’t have to run strip on it afterwards?
That’s all I can think of for now. Thanks!
Ben Shadwick a ?crit :
Hello everyone. I’ve been compiling CVS versions of libsdl for a few
months using MinGW32/MSYS so that I may use them with CVS versions of
DOSBox. I have a few questions for anyone that might know the answers:
- Is an automatically-updated CVS changelog for SDL available
somewhere? I can’t seem to find one, but I’d like to keep up with the
changes.
You may want to try the cvs2cl tool, which generates a changelog from
cvs history.
- Which is currently being more actively developed: the 1.3.x branch
or the 1.2 tree? Some people compile from one and some the other, so I
am confused as to which should have the latest development changes.
I think 1.2 still has the fastest updates. Not that there are a lot of
updates but well…
- Why are hardware directdraw surfaces and hardware overlays disabled
by default in the windx5 code to the point that they require code
modifications to be enabled? If I enable hardware directdraw surfaces,
directdraw seems to be a lot faster in DOSBox.
What portions of code are you talking about ?
-
Enabling hardware overlays does seem to be slower in DOSBox.
Regardless of whether SDL is set to use hardware or software overlays,
DOSBox doesn’t seem to actually be using the same type of hardware
overlay that, say, Media Player Classic and Winamp use when playing
video files - why is this? I’d guess it’s a DOSBox issue, except that
I notice a difference in performance when I enable hardware overlays
in the SDL source, so I know DOSBox is actually using SDL overlays and
not something else when I expect it to.
-
Is there a configure parameter that I can specify to have the
SDL.dll get stripped automatically so that I don’t have to run strip
on it afterwards?
It gets stripped on make install
Stephane
Stephane Marchesin wrote:
Ben Shadwick a ?crit :
- Is an automatically-updated CVS changelog for SDL available
somewhere? I can’t seem to find one, but I’d like to keep up with the
changes.
You may want to try the cvs2cl tool, which generates a changelog from
cvs history.
I looked at it one and couldn’t figure it out, but I just tried again and got it
working.
- Which is currently being more actively developed: the 1.3.x branch
or the 1.2 tree? Some people compile from one and some the other, so I
am confused as to which should have the latest development changes.
I think 1.2 still has the fastest updates. Not that there are a lot of
updates but well…
Thanks.
- Why are hardware directdraw surfaces and hardware overlays disabled
by default in the windx5 code to the point that they require code
modifications to be enabled? If I enable hardware directdraw surfaces,
directdraw seems to be a lot faster in DOSBox.
What portions of code are you talking about ?
In the latest 1.2.x CVS version of src/video/windx5/SDL_dx5video.c on line 1464:
#if 0 /* FIXME: enable this when SDL consistently reports lost surfaces */
if ( (flags & SDL_HWSURFACE) == SDL_HWSURFACE ) {
video->flags |= SDL_HWSURFACE;
} else {
video->flags |= SDL_SWSURFACE;
}
#else
video->flags |= SDL_SWSURFACE;
#endif
And in the same directory in SDL_dx5yuv.c on line 38:
//#define USE_DIRECTX_OVERLAY
- Enabling hardware overlays does seem to be slower in DOSBox.
Regardless of whether SDL is set to use hardware or software overlays,
DOSBox doesn’t seem to actually be using the same type of hardware
overlay that, say, Media Player Classic and Winamp use when playing
video files - why is this? I’d guess it’s a DOSBox issue, except that
I notice a difference in performance when I enable hardware overlays
in the SDL source, so I know DOSBox is actually using SDL overlays and
not something else when I expect it to.
I’d just like to add that running the animated moose overlay test doesn’t result
in the acutal use of hardware overlays on my system, regardless of whether
USE_DIRECTX_OVERLAY is enabled or not. I can tell because I have two monitors
and when an overlay spans both monitors, the portion on the second monitor is
black (a limitation of ATI’s drivers). With SDL programs that think they’re
using overlays, on the other hand, I can see the proper image on both halves of
the window.
- Is there a configure parameter that I can specify to have the
SDL.dll get stripped automatically so that I don’t have to run strip
on it afterwards?
It gets stripped on make install
Ah, thanks.
Ben Shadwick a ?crit :
In the latest 1.2.x CVS version of src/video/windx5/SDL_dx5video.c on
line 1464:
#if 0 /* FIXME: enable this when SDL consistently reports lost
surfaces */
if ( (flags & SDL_HWSURFACE) == SDL_HWSURFACE ) {
video->flags |= SDL_HWSURFACE;
} else {
video->flags |= SDL_SWSURFACE;
}
#else
video->flags |= SDL_SWSURFACE;
#endif
Yes, that’s the case when you’re windowed. There’s not much to do about
this, since directx can lose your surface “from time to time” if you use
a hardware surface, which is against the SDL spec.
Note that if you’re fullscreen you can get a hardware surface.
And in the same directory in SDL_dx5yuv.c on line 38:
//#define USE_DIRECTX_OVERLAY
That’s right. Well I don’t know about that one (I don’t know much about
overlays under windows, to be honest).
- Enabling hardware overlays does seem to be slower in DOSBox.
Regardless of whether SDL is set to use hardware or software
overlays, DOSBox doesn’t seem to actually be using the same type of
hardware overlay that, say, Media Player Classic and Winamp use when
playing video files - why is this? I’d guess it’s a DOSBox issue,
except that I notice a difference in performance when I enable
hardware overlays in the SDL source, so I know DOSBox is actually
using SDL overlays and not something else when I expect it to.
I’d just like to add that running the animated moose overlay test
doesn’t result in the acutal use of hardware overlays on my system,
regardless of whether USE_DIRECTX_OVERLAY is enabled or not. I can
tell because I have two monitors and when an overlay spans both
monitors, the portion on the second monitor is black (a limitation of
ATI’s drivers). With SDL programs that think they’re using overlays,
on the other hand, I can see the proper image on both halves of the
window.
Yes, you’re right. I’m not sure the speed difference is big, though.
Stephane
Stephane Marchesin wrote:
Ben Shadwick a ?crit :
I’d just like to add that running the animated moose overlay test
doesn’t result in the acutal use of hardware overlays on my system,
regardless of whether USE_DIRECTX_OVERLAY is enabled or not. I can
tell because I have two monitors and when an overlay spans both
monitors, the portion on the second monitor is black (a limitation of
ATI’s drivers). With SDL programs that think they’re using overlays,
on the other hand, I can see the proper image on both halves of the
window.
Yes, you’re right. I’m not sure the speed difference is big, though.
Thanks for the replies. While I’m of course not able to test using true hardware
overlays, I find SDL’s (software?) overlay mode to be much slower in DOSBox than
using its other SDL output methods. The reason I’m mostly interested in hardware
overlays, though, is that 1) they automatically scale and filter (smooth) the
output in hardware and 2) their brightness, contrast, color balance, etc. can be
adjusted by the video card drivers.
I’m also not sure what it even means to have a non-hardware overlay. I have a
feeling that maybe SDL’s concept of overlays might be totally different from
graphics card manufacturers’ and multimedia player applications’ concept of
them, and that this is confusing me.
Anyways, it’s good to know that there was a reason for these things in SDL and
not that they were forgotten