CVS and windx5 questions

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

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

  • Ben

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.
    Well, there’s the online CVS browser if that’s what you mean:
    http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/ It can give you changelogs for
    specific files. If you’re looking for a global changelog, I don’t know.
  • 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.
    SDL 1.3 includes some experimental features not ready for release, but as far
    as I know SDL 1.2 is pretty much the standard everywhere.
  • 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.
    'cause the code isn’t perfect yet. Send in the patch! :DOn May 22, 2005 01:31 am, Ben Shadwick wrote: