[PATCH] Function to get desktop resolution

I’ve added a new SDL function that will get the user’s current
resolution. This won’t have meaning for some drivers, but the function
just returns failure if it’s not implemented for the driver in use.

The rationale for the function is that I want a way of picking a
reasonable default fullscreen resolution without having to ask the user.
Using SDL_ListModes() and picking the highest resolution isn’t
appropriate because, for example, LCD users will presumably prefer the
native resolution of the monitor.

Attached is a patch against CVS (at 2005-01-24 14:45:00 GMT) that
includes implementations for X11 and Windows.

Problems:

  • This is my first attempt at hacking on SDL. If I’ve done something
    silly like broken binary compatability, I wouldn’t be suprised.
  • video/wincommon/SDL_syswm.c doesn’t seem like a particularly good
    home for WIN_GetDesktopMode, but I couldn’t face adding a new source
    file to the various build systems.
  • Only implemented on X11 and Windows. Do I have to set
    device->GetDesktopMode = NULL for all the other video drivers manually?
    It seems that I do, but I wanted to check before doing it, in case it’s
    a waste of time.
  • GetDesktopMode isn’t a great name. I’m open to suggestions.

Thanks.–
Jon

-------------- next part --------------
A non-text attachment was scrubbed…
Name: dm-cvs-20050124144500.diff
Type: text/x-patch
Size: 6971 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050124/350bf9f7/attachment.bin

Jon Colverson wrote:

I’ve added a new SDL function that will get the user’s current
resolution. This won’t have meaning for some drivers, but the function
just returns failure if it’s not implemented for the driver in use.

The rationale for the function is that I want a way of picking a
reasonable default fullscreen resolution without having to ask the
user. Using SDL_ListModes() and picking the highest resolution isn’t
appropriate because, for example, LCD users will presumably prefer the
native resolution of the monitor.

Attached is a patch against CVS (at 2005-01-24 14:45:00 GMT) that
includes implementations for X11 and Windows.

Problems:

  • This is my first attempt at hacking on SDL. If I’ve done something
    silly like broken binary compatability, I wouldn’t be suprised.
  • video/wincommon/SDL_syswm.c doesn’t seem like a particularly good
    home for WIN_GetDesktopMode, but I couldn’t face adding a new source
    file to the various build systems.
  • Only implemented on X11 and Windows. Do I have to set
    device->GetDesktopMode = NULL for all the other video drivers
    manually? It seems that I do, but I wanted to check before doing it,
    in case it’s a waste of time.
  • GetDesktopMode isn’t a great name. I’m open to suggestions.

If I was to implement this, I’d extend the existing SDL_GetVideoInfo
stuff. This function returns a pointer to a video info structure, which
could very well contain the width and height of the current desktop
(unusedbits3 can be used to hold that while keeping backwards
compatibility).

Just my 2 eurocents

Stephane

Stephane Marchesin wrote:

Jon Colverson wrote:

I’ve added a new SDL function that will get the user’s current
resolution. This won’t have meaning for some drivers, but the
function just returns failure if it’s not implemented for the driver
in use.

The rationale for the function is that I want a way of picking a
reasonable default fullscreen resolution without having to ask the
user. Using SDL_ListModes() and picking the highest resolution isn’t
appropriate because, for example, LCD users will presumably prefer
the native resolution of the monitor.

Attached is a patch against CVS (at 2005-01-24 14:45:00 GMT) that
includes implementations for X11 and Windows.

Problems:

  • This is my first attempt at hacking on SDL. If I’ve done something
    silly like broken binary compatability, I wouldn’t be suprised.
  • video/wincommon/SDL_syswm.c doesn’t seem like a particularly good
    home for WIN_GetDesktopMode, but I couldn’t face adding a new source
    file to the various build systems.
  • Only implemented on X11 and Windows. Do I have to set
    device->GetDesktopMode = NULL for all the other video drivers
    manually? It seems that I do, but I wanted to check before doing it,
    in case it’s a waste of time.
  • GetDesktopMode isn’t a great name. I’m open to suggestions.

If I was to implement this, I’d extend the existing SDL_GetVideoInfo
stuff. This function returns a pointer to a video info structure,
which could very well contain the width and height of the current
desktop (unusedbits3 can be used to hold that while keeping backwards
compatibility).

Hmm, there isn’t enough room with these 16 bits. So you’ll break binary
compat if you add it.
Well, maybe that is SDL 1.3 material…

Stephane

Jon Colverson wrote:

I’ve added a new SDL function that will get the user’s current
resolution. This won’t have meaning for some drivers, but the
function just returns failure if it’s not implemented for the driver
in use.

Stephane Marchesin wrote:

If I was to implement this, I’d extend the existing SDL_GetVideoInfo
stuff. This function returns a pointer to a video info structure,
which could very well contain the width and height of the current
desktop (unusedbits3 can be used to hold that while keeping backwards
compatibility).

Hmm, there isn’t enough room with these 16 bits. So you’ll break binary
compat if you add it.
Well, maybe that is SDL 1.3 material…

I didn’t receive much response to my patch that I sent a few days ago
(http://twomix.devolution.com/pipermail/sdl/2005-January/067010.html).
I’d like to see it commited if possible. I don’t know enough about the
SDL development process to know what to do next. Have I just not waited
long enough for a response? Or are Stephane’s comments authoritative and
my patch has been rejected?

Thanks.–
Jon

Jon Colverson wrote:

I’ve added a new SDL function that will get the user’s current
resolution. This won’t have meaning for some drivers, but the
function just returns failure if it’s not implemented for the driver
in use.

Stephane Marchesin wrote:

If I was to implement this, I’d extend the existing SDL_GetVideoInfo
stuff. This function returns a pointer to a video info structure,
which could very well contain the width and height of the current
desktop (unusedbits3 can be used to hold that while keeping backwards
compatibility).

Hmm, there isn’t enough room with these 16 bits. So you’ll break binary
compat if you add it.
Well, maybe that is SDL 1.3 material…

I didn’t receive much response to my patch that I sent a few days ago
(http://twomix.devolution.com/pipermail/sdl/2005-January/067010.html).
I’d like to see it commited if possible. I don’t know enough about the
SDL development process to know what to do next. Have I just not waited
long enough for a response? Or are Stephane’s comments authoritative and
my patch has been rejected?

Stephane’s comments are relevant and just might describe what will
happen to your patch, but Stephane does not decide what goes in SDL, Sam
does. Sam has not yet answered and this subject. Most likely Sam is busy
with other things right now. I sent him a personal email a couple of
days ago and haven’t received a reply, so I suspect he is busy (did I
hear something about server down time in WoW? The could be why he isn’t
responding).

What tends to happen is that Sam will eventually read your message and
reply. Your patch may go in to 1.2.8 or it may go into 1.3. Or the idea
may get batted around for a while and some other version may go in at
some time in the future. Or, it may be decided that it should not ever
go into SDL and it won’t go into SDL. No way to know really. Though, the
more platforms the patch supports the better chance it has of going in.

At least that is what I have seen in the several years I’ve been on the
list :slight_smile: I’m not Sam.

OTOH, you are free to add the feature to your copy of SDL. It is after
all, open source software. So long as you comply with the lgpl then you
can change the source anyway you want.

	Bob PendletonOn Fri, 2005-01-28 at 19:22 +0000, Jon Colverson wrote:

Thanks.

Thanks a lot for the info. Just what I needed to know.–
Jon

Jon Colverson wrote:

I’ve added a new SDL function that will get the user’s current
resolution. This won’t have meaning for some drivers, but the
function just returns failure if it’s not implemented for the driver
in use.

BTW, what are you using this feature for? I assume you mentioned the
reason for it earlier but I missed it. I’m just asking because between
SDL_GetVideoInfo(), SDL_ListModes(), and SDL_VideoModeOK(), I’ve been
able to get the information about video modes that I need. Just curious
always looking for a chance to learn.

	Bob Pendleton> On Fri, 2005-01-28 at 19:22 +0000, Jon Colverson wrote:

Bob Pendleton wrote:

BTW, what are you using this feature for? I assume you mentioned the
reason for it earlier but I missed it. I’m just asking because between
SDL_GetVideoInfo(), SDL_ListModes(), and SDL_VideoModeOK(), I’ve been
able to get the information about video modes that I need. Just curious
always looking for a chance to learn.

This was in my first mail:

The rationale for the function is that I want a way of picking a
reasonable default fullscreen resolution without having to ask the user.
Using SDL_ListModes() and picking the highest resolution isn’t
appropriate because, for example, LCD users will presumably prefer the
native resolution of the monitor.–
Jon

IMHO it would be better to add support in SDL_SetVideoMode() to select
the current desktop resolution by specifying zero in the first and
second arguments. That solution would be logical since you can achieve
the same with the bpp (ie. setting it to zero selects the current
desktop depth), and it would avoid polluting the API with a new
function.

My 2 cents…On Fri, 28 Jan 2005 21:11:36 +0000, Jon Colverson wrote:

The rationale for the function is that I want a way of picking a
reasonable default fullscreen resolution without having to ask the user.
Using SDL_ListModes() and picking the highest resolution isn’t
appropriate because, for example, LCD users will presumably prefer the
native resolution of the monitor.

IMHO it would be better to add support in SDL_SetVideoMode() to select
the current desktop resolution by specifying zero in the first and
second arguments. That solution would be logical since you can achieve
the same with the bpp (ie. setting it to zero selects the current
desktop depth), and it would avoid polluting the API with a new
function.

My 2 cents…

I’ll second that. It makes sense. I would also like to see the video
info struct extended to include the information.

	Bob PendletonOn Fri, 2005-01-28 at 16:33 -0500, Simon Roby wrote:

On Fri, 28 Jan 2005 21:11:36 +0000, Jon Colverson wrote:

The rationale for the function is that I want a way of picking a
reasonable default fullscreen resolution without having to ask the user.
Using SDL_ListModes() and picking the highest resolution isn’t
appropriate because, for example, LCD users will presumably prefer the
native resolution of the monitor.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

IMHO it would be better to add support in SDL_SetVideoMode() to
select

the current desktop resolution by specifying zero in the first and
second arguments. That solution would be logical since you can
achieve

the same with the bpp (ie. setting it to zero selects the current
desktop depth), and it would avoid polluting the API with a new
function.

My 2 cents…

I’ll second that. It makes sense. I would also like to see the video
info struct extended to include the information.

As we say around Linux-Audio-Dev:

++votes;

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Friday 28 January 2005 23.18, Bob Pendleton wrote:

On Fri, 2005-01-28 at 16:33 -0500, Simon Roby wrote:

Simon Roby wrote:

IMHO it would be better to add support in SDL_SetVideoMode() to select
the current desktop resolution by specifying zero in the first and
second arguments. That solution would be logical since you can achieve
the same with the bpp (ie. setting it to zero selects the current
desktop depth), and it would avoid polluting the API with a new
function.

I like the symmetry with the bitsperpixel argument, but it makes things
rather messy if getting the current resolution fails. Right now I’m doing:----
// hard-coded defaults if we can’t do any better
int width = 1024;
int height = 768;
SDL_GetDesktopMode(&width, &height);
SDL_Surface* screen = SDL_SetVideoMode(
width, height, bpp, flags);
if (!screen) { /* fail */ }

If it worked like you propose I’d have to do something like:

SDL_Surface* screen = SDL_SetVideoMode(0, 0, bpp, flags);
if (!screen) {
screen = SDL_SetVideoMode(1024, 768, bpp, flags);
if (!screen) { /* something really wrong, fail */ }
}

Alternatively, we could say that 0 for width and height means “use
user’s current resolution if possible, otherwise use highest available
resolution”. I don’t like that much either, because it would make is
impossible to do something like:

int width, height;
if (!SDL_GetDesktopMode(&width, &height)) {
/* yuck, ask the user, hope they forgive me later */
}


Jon

Simon Roby wrote:

IMHO it would be better to add support in SDL_SetVideoMode() to
select

the current desktop resolution by specifying zero in the first and
second arguments. That solution would be logical since you can
achieve

the same with the bpp (ie. setting it to zero selects the current
desktop depth), and it would avoid polluting the API with a new
function.

I like the symmetry with the bitsperpixel argument, but it makes
things
rather messy if getting the current resolution fails. Right now I’m
doing:

// hard-coded defaults if we can’t do any better
int width = 1024;
int height = 768;
SDL_GetDesktopMode(&width, &height);
SDL_Surface* screen = SDL_SetVideoMode(
width, height, bpp, flags);
if (!screen) { /* fail */ }

If it worked like you propose I’d have to do something like:

SDL_Surface* screen = SDL_SetVideoMode(0, 0, bpp, flags);
if (!screen) {
screen = SDL_SetVideoMode(1024, 768, bpp, flags);
if (!screen) { /* something really wrong, fail */ }
}

How about this:On Friday 28 January 2005 23.59, Jon Colverson wrote:

SDL_Surface* screen = SDL_SetVideoMode(-1024, -768, bpp, flags);

where the negative arguments mean “use the desktop resolution if
possible, otherwise use labs(width), labs(height)?”

That said, I like plain 0, 0 much better for some reason. I can live
with 0 and some #defined (negative) values having special meanings,
but negative sizes…? Eww…! :slight_smile:

Alternatively, we could say that 0 for width and height means “use
user’s current resolution if possible, otherwise use highest
available
resolution”. I don’t like that much either, because it would make is
impossible to do something like:

int width, height;
if (!SDL_GetDesktopMode(&width, &height)) {
/* yuck, ask the user, hope they forgive me later */
}

Right; I think that’s a different feature and should have a different
interface. (Can’t you just use SDL_ListModes() to get the highest
available resolution? If that doesn’t work on some system, I guess
the information just isn’t available, and then you can’t do it
anyway.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se

David Olofson wrote:

How about this:

SDL_Surface* screen = SDL_SetVideoMode(-1024, -768, bpp, flags);

where the negative arguments mean “use the desktop resolution if
possible, otherwise use labs(width), labs(height)?”

That said, I like plain 0, 0 much better for some reason. I can live
with 0 and some #defined (negative) values having special meanings,
but negative sizes…? Eww…! :slight_smile:

Yeah, it’s a neat idea, but I don’t think negative sizes are very intuitive.–
Jon

David Olofson wrote:

How about this:

SDL_Surface* screen = SDL_SetVideoMode(-1024, -768, bpp, flags);

where the negative arguments mean “use the desktop resolution if
possible, otherwise use labs(width), labs(height)?”

That said, I like plain 0, 0 much better for some reason. I can
live

with 0 and some #defined (negative) values having special
meanings,

but negative sizes…? Eww…! :slight_smile:

Yeah, it’s a neat idea, but I don’t think negative sizes are very
intuitive.

Nor do I, but #defined “magic” values are not negative sizes. They’re
special codes, just like the value 0 - and with the #defines, you
wouldn’t see the actual values in the source either way.

Something like:On Saturday 29 January 2005 00.56, Jon Colverson wrote:

#define SDL_MAX_SIZE -1
#define SDL_DESKTOP_SIZE -2

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se

Bob Pendleton <bob pendleton.com> writes:

IMHO it would be better to add support in SDL_SetVideoMode() to select
the current desktop resolution by specifying zero in the first and
second arguments. That solution would be logical since you can achieve
the same with the bpp (ie. setting it to zero selects the current
desktop depth), and it would avoid polluting the API with a new
function.

My 2 cents…

I’ll second that. It makes sense. I would also like to see the video
info struct extended to include the information.

  Bob Pendleton

Even if the ability to pass width,height as 0,0 is implemented, I agree with
Bob that it’d be useful to have the actual screen resolution added to the video
info struct. In my case, I want to create a window whose size is proportional
to, but smaller than, the screen. So I need to know the real screen resolution.

Jon’s post was timely- I was just looking for a way to get the screen
resolution in the SDL docs today, before finding this thread. Thanks Jon.

Troy Hanson> On Fri, 2005-01-28 at 16:33 -0500, Simon Roby wrote:

Alternatively, we could say that 0 for width and height means “use
user’s current resolution if possible, otherwise use highest available
resolution”. I don’t like that much either, because it would make is
impossible to do something like:

Never use highest available resolution…some platforms (or
misconfigured hardware on any platform) will report a higher resolution
than the monitor can support. When this happens, you end up with a
scrambled screen, or a blurry display, or a monitor inexplicably in standby.

Plus, there’s my crazy parents who are running an Apple 20" flat panel
at 800x600 since they think it looks “better” that way. The hardware can
do a better resolution, but now the font and icons are too small. Yeah,
yeah, take it up with them.

I would say never trust the OS to tell you the maximum screen
resolution, because it might have a rough idea, but it doesn’t
specifically know. SDL_ListModes() was, I think, always meant as an
interface so you can present sane defaults to the user or definitely
rule out a given resolution.

Being able to ask the OS "what resolution is the desktop in RIGHT NOW"
is more useful, especially if you can make an intelligent decision about
multi-display setups.

I was actually wishing for this function the other day; I had an OpenGL
project that would have been nice to scale to my LCD’s native
resolution, but picking the biggest fullscreen value in SDL_ListModes()
can’t really be trusted.

Above rant aside, I like the idea about SDL_SetVideoMode() with a size
of 0x0, too, at least at first glance.

–ryan.

No matter how much lipstick you put on that pig, it is still a pig.
Negative number are an error, not a way to specify an option.

	Bob PendletonOn Fri, 2005-01-28 at 23:56 +0000, Jon Colverson wrote:

David Olofson wrote:

How about this:

SDL_Surface* screen = SDL_SetVideoMode(-1024, -768, bpp, flags);

where the negative arguments mean “use the desktop resolution if
possible, otherwise use labs(width), labs(height)?”

That said, I like plain 0, 0 much better for some reason. I can live
with 0 and some #defined (negative) values having special meanings,
but negative sizes…? Eww…! :slight_smile:

Yeah, it’s a neat idea, but I don’t think negative sizes are very intuitive.

I didn’t receive much response to my patch that I sent a few days ago
(http://twomix.devolution.com/pipermail/sdl/2005-January/067010.html).
I’d like to see it commited if possible.

You did exactly the right thing in the patch, that’s exactly how you would
extend the video driver with a new function. This would be a candidate for
the SDL 1.3 branch.

However, I like the idea of using 0 to denote “current desktop” in the
width and height, and I also like the idea of including that information
in the video info structure.

We can add the “0” concept to SDL 1.2, without breaking binary compatibility.

How do people feel about adding the desktop resolution to the video info
as opposed to having a separate explicit function to get it? A separate
function might be more intuitive for the developer.

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

Sam Lantinga wrote:

I didn’t receive much response to my patch that I sent a few days ago
(http://twomix.devolution.com/pipermail/sdl/2005-January/067010.html).
I’d like to see it commited if possible.

You did exactly the right thing in the patch, that’s exactly how you would
extend the video driver with a new function. This would be a candidate for
the SDL 1.3 branch.

However, I like the idea of using 0 to denote “current desktop” in the
width and height, and I also like the idea of including that information
in the video info structure.

We can add the “0” concept to SDL 1.2, without breaking binary compatibility.

Is it correct to perform the same thing differently on two SDL versions ?
Do we want source compatilibity for new SDL versions ?
I think the answers to these questions might help decide what to do.

Stephane