SDL_VideoInfo in 1.3 missing elements

In SVN 1.3 in SDL_compat.h:

typedef struct SDL_VideoInfo
{
Uint32 hw_available:1;
Uint32 wm_available:1;
Uint32 UnusedBits1:6;
Uint32 UnusedBits2:1;
Uint32 blit_hw:1;
Uint32 blit_hw_CC:1;
Uint32 blit_hw_A:1;
Uint32 blit_sw:1;
Uint32 blit_sw_CC:1;
Uint32 blit_sw_A:1;
Uint32 blit_fill:1;
Uint32 UnusedBits3:16;
Uint32 video_mem;

SDL_PixelFormat *vfmt;

} SDL_VideoInfo;

In 1.2.13 SDL_Video:
/* Useful for determining the video hardware capabilities /
typedef struct SDL_VideoInfo {
Uint32 hw_available :1; /
Flag: Can you create hardware surfaces? /
Uint32 wm_available :1; /
Flag: Can you talk to a window manager? /
Uint32 UnusedBits1 :6;
Uint32 UnusedBits2 :1;
Uint32 blit_hw :1; /
Flag: Accelerated blits HW --> HW /
Uint32 blit_hw_CC :1; /
Flag: Accelerated blits with Colorkey /
Uint32 blit_hw_A :1; /
Flag: Accelerated blits with Alpha /
Uint32 blit_sw :1; /
Flag: Accelerated blits SW --> HW /
Uint32 blit_sw_CC :1; /
Flag: Accelerated blits with Colorkey /
Uint32 blit_sw_A :1; /
Flag: Accelerated blits with Alpha /
Uint32 blit_fill :1; /
Flag: Accelerated color fill /
Uint32 UnusedBits3 :16;
Uint32 video_mem; /
The total amount of video memory (in K) */
SDL_PixelFormat vfmt; / Value: The format of the video surface /
int current_w; /
Value: The current video mode width /
int current_h; /
Value: The current video mode height */
} SDL_VideoInfo;

Its missing current_w/current_h.

But more pressing – there seems to be “radical” changes in a number of places –
is there anything which explains the changes (besdies examining the source?)

marty

I don’t think SDL 1.3 is meant to be in any way compatible with 1.2, this is why it is a different major version (1.2.x vs 1.3.x).

1.2 will continue to be maintained in terms of bugfixes, and existing SDL 1.2 apps can continue using SDL 1.2.

But I do not know - maybe it is meant to be compatible?

Marty Leisner wrote:> In SVN 1.3 in SDL_compat.h:

typedef struct SDL_VideoInfo
{
Uint32 hw_available:1;
Uint32 wm_available:1;
Uint32 UnusedBits1:6;
Uint32 UnusedBits2:1;
Uint32 blit_hw:1;
Uint32 blit_hw_CC:1;
Uint32 blit_hw_A:1;
Uint32 blit_sw:1;
Uint32 blit_sw_CC:1;
Uint32 blit_sw_A:1;
Uint32 blit_fill:1;
Uint32 UnusedBits3:16;
Uint32 video_mem;

SDL_PixelFormat *vfmt;

} SDL_VideoInfo;

In 1.2.13 SDL_Video:
/* Useful for determining the video hardware capabilities /
typedef struct SDL_VideoInfo {
Uint32 hw_available :1; /
Flag: Can you create hardware surfaces? /
Uint32 wm_available :1; /
Flag: Can you talk to a window manager? /
Uint32 UnusedBits1 :6;
Uint32 UnusedBits2 :1;
Uint32 blit_hw :1; /
Flag: Accelerated blits HW --> HW /
Uint32 blit_hw_CC :1; /
Flag: Accelerated blits with Colorkey /
Uint32 blit_hw_A :1; /
Flag: Accelerated blits with Alpha /
Uint32 blit_sw :1; /
Flag: Accelerated blits SW --> HW /
Uint32 blit_sw_CC :1; /
Flag: Accelerated blits with Colorkey /
Uint32 blit_sw_A :1; /
Flag: Accelerated blits with Alpha /
Uint32 blit_fill :1; /
Flag: Accelerated color fill /
Uint32 UnusedBits3 :16;
Uint32 video_mem; /
The total amount of video memory (in K) */
SDL_PixelFormat vfmt; / Value: The format of the video surface /
int current_w; /
Value: The current video mode width /
int current_h; /
Value: The current video mode height */
} SDL_VideoInfo;

Its missing current_w/current_h.

But more pressing – there seems to be “radical” changes in a number of places –
is there anything which explains the changes (besdies examining the source?)

marty


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Forest ‘LordHavoc’ Hale
Author of DarkPlaces Quake1 engine and mod
http://icculus.org/twilight/darkplaces/
Address: 94340 Horton Road Blachly OR 97412
Phone/Fax: 541-925-4130

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

What he’s pointing out is that it’s missing the current_w and current_h,
which regardless of compatibility is a pretty nice feature to have.
It’s always good to know their native resolution when going fullscreen.

Edgar

Forest Hale wrote:

I don’t think SDL 1.3 is meant to be in any way compatible with 1.2, this is why it is a different major version (1.2.x vs 1.3.x).

1.2 will continue to be maintained in terms of bugfixes, and existing SDL 1.2 apps can continue using SDL 1.2.

But I do not know - maybe it is meant to be compatible?

Marty Leisner wrote:

In SVN 1.3 in SDL_compat.h:

typedef struct SDL_VideoInfo
{
Uint32 hw_available:1;
Uint32 wm_available:1;
Uint32 UnusedBits1:6;
Uint32 UnusedBits2:1;
Uint32 blit_hw:1;
Uint32 blit_hw_CC:1;
Uint32 blit_hw_A:1;
Uint32 blit_sw:1;
Uint32 blit_sw_CC:1;
Uint32 blit_sw_A:1;
Uint32 blit_fill:1;
Uint32 UnusedBits3:16;
Uint32 video_mem;

SDL_PixelFormat *vfmt;

} SDL_VideoInfo;

In 1.2.13 SDL_Video:
/* Useful for determining the video hardware capabilities /
typedef struct SDL_VideoInfo {
Uint32 hw_available :1; /
Flag: Can you create hardware surfaces? /
Uint32 wm_available :1; /
Flag: Can you talk to a window manager? /
Uint32 UnusedBits1 :6;
Uint32 UnusedBits2 :1;
Uint32 blit_hw :1; /
Flag: Accelerated blits HW --> HW /
Uint32 blit_hw_CC :1; /
Flag: Accelerated blits with Colorkey /
Uint32 blit_hw_A :1; /
Flag: Accelerated blits with Alpha /
Uint32 blit_sw :1; /
Flag: Accelerated blits SW --> HW /
Uint32 blit_sw_CC :1; /
Flag: Accelerated blits with Colorkey /
Uint32 blit_sw_A :1; /
Flag: Accelerated blits with Alpha /
Uint32 blit_fill :1; /
Flag: Accelerated color fill /
Uint32 UnusedBits3 :16;
Uint32 video_mem; /
The total amount of video memory (in K) */
SDL_PixelFormat vfmt; / Value: The format of the video surface /
int current_w; /
Value: The current video mode width /
int current_h; /
Value: The current video mode height */
} SDL_VideoInfo;

Its missing current_w/current_h.

But more pressing – there seems to be “radical” changes in a number of places –
is there anything which explains the changes (besdies examining the source?)

marty


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkgSf8ACgkQolm4VNX3QTwEdACgyeqUEUVFyfFy7Jd5OKnpc0NQ
+0YAnAhSZSlUqRtbNuigjckvxE9wbejP
=DPd5
-----END PGP SIGNATURE-----

  1. if we’re compatible, we definitely should compile without changing
    old code (at a minimum)
  2. semantic comptability is nice, how do I find out the current screen
    resolution
    for going full screen?
  3. if someone “changes” the screen resolution, how can I find out (is there
    a way to asychronously notify me?)

marty

Edgar Simo writes on Sun, 16 Nov 2008 17:27:43 +0100
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
>
> What he’s pointing out is that it’s missing the current_w and current_h,
> which regardless of compatibility is a pretty nice feature to have.
> It’s always good to know their native resolution when going fullscreen.
>
>
> Edgar
>
> Forest Hale wrote:
> > I don’t think SDL 1.3 is meant to be in any way compatible with 1.2,
this is why it is a different major versi
>on (1.2.x vs 1.3.x).
> >
> > 1.2 will continue to be maintained in terms of bugfixes, and existing
SDL 1.2 apps can continue using SDL 1.2.
> >
> > But I do not know - maybe it is meant to be compatible?
> >
> > Marty Leisner wrote:
> >> In SVN 1.3 in SDL_compat.h:
> >>
> >> typedef struct SDL_VideoInfo
> >> {
> >> Uint32 hw_available:1;
> >> Uint32 wm_available:1;
> >> Uint32 UnusedBits1:6;
> >> Uint32 UnusedBits2:1;
> >> Uint32 blit_hw:1;
> >> Uint32 blit_hw_CC:1;
> >> Uint32 blit_hw_A:1;
> >> Uint32 blit_sw:1;
> >> Uint32 blit_sw_CC:1;
> >> Uint32 blit_sw_A:1;
> >> Uint32 blit_fill:1;
> >> Uint32 UnusedBits3:16;
> >> Uint32 video_mem;
> >>
> >> SDL_PixelFormat vfmt;
> >> } SDL_VideoInfo;
> >>
> >> In 1.2.13 SDL_Video:
> >> /
Useful for determining the video hardware capabilities /
> >> typedef struct SDL_VideoInfo {
> >> Uint32 hw_available :1; /
Flag: Can you create hardware
surfaces? /
> >> Uint32 wm_available :1; /
Flag: Can you talk to a window
manager? /
> >> Uint32 UnusedBits1 :6;
> >> Uint32 UnusedBits2 :1;
> >> Uint32 blit_hw :1; /
Flag: Accelerated blits HW --> HW
/
> >> Uint32 blit_hw_CC :1; /
Flag: Accelerated blits with
Colorkey /
> >> Uint32 blit_hw_A :1; /
Flag: Accelerated blits with
Alpha /
> >> Uint32 blit_sw :1; /
Flag: Accelerated blits SW --> HW
/
> >> Uint32 blit_sw_CC :1; /
Flag: Accelerated blits with
Colorkey /
> >> Uint32 blit_sw_A :1; /
Flag: Accelerated blits with
Alpha /
> >> Uint32 blit_fill :1; /
Flag: Accelerated color fill /
> >> Uint32 UnusedBits3 :16;
> >> Uint32 video_mem; /
The total amount of video memory
(in K) */
> >> SDL_PixelFormat vfmt; / Value: The format of the video
surface /
> >> int current_w; /
Value: The current video mode
width /
> >> int current_h; /
Value: The current video mode
height */
> >> } SDL_VideoInfo;
> >>
> >>
> >> Its missing current_w/current_h.
> >>
> >> But more pressing – there seems to be “radical” changes in a number
of places –
> >> is there anything which explains the changes (besdies examining the
source?)> >>
> >> marty
> >> _______________________________________________
> >> SDL mailing list
> >> SDL at lists.libsdl.org
> >> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> >>
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkkgSf8ACgkQolm4VNX3QTwEdACgyeqUEUVFyfFy7Jd5OKnpc0NQ
> +0YAnAhSZSlUqRtbNuigjckvxE9wbejP
> =DPd5
> -----END PGP SIGNATURE-----
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

  1. if we’re compatible, we definitely should compile without changing
    old code (at a minimum)

SDL 1.3 is “mostly compatible”, meaning unless there’s a good reason,
we’re not changing the API. However where there’s a good reason, we’re
updating and improving things. The keyboard input API is an example of
this.

  1. semantic comptability is nice, how do I find out the current screen
    resolution
    for going full screen?

SDL_GetDesktopDisplayMode()

There’s no reason why current_w and current_h couldn’t have that data though,
I’ll make a note to implement it.

  1. if someone “changes” the screen resolution, how can I find out (is there
    a way to asychronously notify me?)

Not that the moment, although it could be added. Why do you need to know
the current desktop mode while your application is running?

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Hello !

  1. if someone “changes” the screen resolution, how can I find out (is there
    a way to asychronously notify me?)

Not that the moment, although it could be added. Why do you need to know
the current desktop mode while your application is running?

It maybe usefull when coding special apps,
like a paint programm or a sample editor
with SDL.

Also when SDL 1.3 is stabilized, many
people will think about porting GUI toolkits
to SDL and may need such functionality.

Personally i would love to see FLTK running under SDL 1.3.

CU

Sam Lantinga writes on Mon, 17 Nov 2008 10:50:02 PST
>
> > 1) if we’re compatible, we definitely should compile without changing
> > old code (at a minimum)
>
> SDL 1.3 is “mostly compatible”, meaning unless there’s a good reason,
> we’re not changing the API. However where there’s a good reason, we’re
> updating and improving things. The keyboard input API is an example of
> this.
>

its may be better to compile and limp than "not compile"
Don’t see why current_x/current_y are left out (or what the value
would be for “unknown” (0? -1?)

 > > 2) semantic comptability is nice, how do I find out the current screen 
 > > resolution
 > > for going full screen?
 > 
 > SDL_GetDesktopDisplayMode()
 > 
 > There's no reason why current_w and current_h couldn't have that data though,
 > I'll make a note to implement it.
 > 
 > > 3) if someone "changes" the screen resolution, how can I find out (is there
 > > a way to asychronously notify me?)
 > 
 > Not that the moment, although it could be added.  Why do you need to know
 > the current desktop mode while your application is running?
 > 

If I want to have widgets with a “percentage” of the screen size, instead of
constructing each widget at each blit, construct them when the screen size
changes (when the user changes the screen size in the SDL application I know,
when he “changes” the size with the frame buffer, I really wouldn’t know).

It may be easier to construct the object each blit…

marty> See ya!
> -Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org