Donny Viszneki wrote:
By which I mean: how can this be done? It seems not possible to me. If
the monitor + driver + OS / X are not giving the information to SDL,
what recourse does SDL have?At the minimum, SDL could allow you to specify logical resolution and
physical resolution separately.
…which was all I originally asked for before this got completely derailed
into a discussion about LCD monitors. :P>----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] SDL_Window suggestion
Den Fri, 1 May 2009 02:44:53 -0400
skrev Donny Viszneki <@Donny_Viszneki>:Ah, well this is where we diverge.
By which I mean: how can this be done? It seems not possible to me. If
the monitor + driver + OS / X are not giving the information to SDL,
what recourse does SDL have?That, my friend, is where native resolution comes in. A monitor’s
native resolution is by definiton the perfect display mode for that
monitor, so it’s pretty much guaranteed to not be distorted in any way,
But that’s insane. I would vastly favor any other option to solve this
problem over this one. It should definitely not be the default
behavior to use the “native resolution” and scale the picture
in-process. On performance- and/or power-constrained systems, this
sort of explosion of resources (for most video back-ends) is
ridiculous! To fix the problems of some users, SDL apps should not
use more resources for everyone.
SDL could perhaps find the native resolution by querying EDID, or
simpler, just assume that the desktop resolution is the native one,
which is usually the case. The latter would also automatically work
with CRT monitors.
That is something I hadn’t considered. To me it seems very hackish. At
the very least, if you’re going to “just assume that the desktop
resolution is the native one” you had better provide an ENVIRONMENT
VARIABLE to override this behavior!!! Some people change their display
resolution frequently. Some even use those scrolling desktop modes
that uses a framebuffer larger than the display, and the video signal
output is assembled from a variable position in the framebuffer. On X
it’s a simple keyboard shortcut: CTRL+ALT+NPMINUS or CTRL+ALT+NPPLUS.
On that note: does anyone know how these modes interact with what
modes show up when querying available display modes?
assuming the monitor uses square pixels (a few don’t, but I don’t think
there’s any way to find out this, so let’s just ignore that).
You can query for the resolution tuple (MSWindows was once
particularly fond of 72x72 DPI for some reason) and get the info from
there.
What does 1.3 have to do with environment variables?
1.2 API is frozen, 1.3 API isn’t.
There is not a lot of development work happening for 1.2, but I
believe an API freeze implies one must retain backward compatibility
with any program using the old API. I do not suppose this includes
adding new API functions or environment variables. If Sam did
intend to freeze adding new API functions, I would not assume this
means environment variables are allowed.
(I don’t meant to contradict every individual thing you say!)On Fri, May 1, 2009 at 8:06 AM, Gerry JJ wrote:
On Fri, May 1, 2009 at 3:42 PM, Rainer Deyke wrote:
Donny Viszneki wrote:
By which I mean: how can this be done? It seems not possible to me. If
the monitor + driver + OS / X are not giving the information to SDL,
what recourse does SDL have?At the minimum, SDL could allow you to specify logical resolution and
physical resolution separately.
Well, unless you only want boxing used, you will also need to specify
scaling options.
Den Fri, 1 May 2009 17:15:18 -0400
skrev Donny Viszneki <donny.viszneki at gmail.com>:
That, my friend, is where native resolution comes in. A monitor’s
native resolution is by definiton the perfect display mode for that
monitor, so it’s pretty much guaranteed to not be distorted in any
way,But that’s insane. I would vastly favor any other option to solve this
problem over this one. It should definitely not be the default
behavior to use the “native resolution” and scale the picture
in-process. On performance- and/or power-constrained systems, this
sort of explosion of resources (for most video back-ends) is
ridiculous! To fix the problems of some users, SDL apps should not
use more resources for everyone.
But that’s the thing, there really aren’t any other options besides
telling users to constantly fix their broken systems, which may sound
fine to you, but really isn’t an option, specially since that may
involve buying new monitors and graphics cards, or installing alternate
operating systems. They don’t want that, they just want to play the
game.
Anyway, this is a very common problem, so it’s worth fixing imo. As for
performance, as we went over before, this should probably only be done
if hardware scaling is available.
In any case, I don’t think any developer should be FORCED to use this.
SDL could perhaps find the native resolution by querying EDID, or
simpler, just assume that the desktop resolution is the native one,
which is usually the case. The latter would also automatically work
with CRT monitors.That is something I hadn’t considered. To me it seems very hackish. At
the very least, if you’re going to “just assume that the desktop
resolution is the native one” you had better provide an ENVIRONMENT
VARIABLE to override this behavior!!! Some people change their display
resolution frequently. Some even use those scrolling desktop modes
that uses a framebuffer larger than the display, and the video signal
output is assembled from a variable position in the framebuffer. On X
it’s a simple keyboard shortcut: CTRL+ALT+NPMINUS or CTRL+ALT+NPPLUS.
That’s virtual resolution. I’m talking about the true resolution.
Anyway, I’m not against having the ability to override with environment
variables, options are nice. It just REALLY shouldn’t be REQUIRED.
On that note: does anyone know how these modes interact with what
modes show up when querying available display modes?assuming the monitor uses square pixels (a few don’t, but I don’t
think there’s any way to find out this, so let’s just ignore that).You can query for the resolution tuple (MSWindows was once
particularly fond of 72x72 DPI for some reason) and get the info from
there.
Yes, but this info is frequently wrong.
What does 1.3 have to do with environment variables?
1.2 API is frozen, 1.3 API isn’t.
There is not a lot of development work happening for 1.2, but I
believe an API freeze implies one must retain backward compatibility
with any program using the old API. I do not suppose this includes
adding new API functions or environment variables. If Sam did
intend to freeze adding new API functions, I would not assume this
means environment variables are allowed.
I guess that depends on if you consider environment variables part of
the API. I don’t. If a game has to set environment variables to
configure SDL, a real API would be better. As I see it, environment
variables are for the users’ convenince, so they can override default
behaviour if something goes wrong in SDL. Not for developers.
(I don’t meant to contradict every individual thing you say!)
Ditto =)
At the minimum, SDL could allow you to specify logical resolution
and physical resolution separately.Well, unless you only want boxing used, you will also need to specify
scaling options.
But hey, what’s this? We agree on something? =)
Den Fri, 1 May 2009 12:45:44 -0700 (PDT)
skrev Mason Wheeler :
At the minimum, SDL could allow you to specify logical resolution and
physical resolution separately.
And what scaling to use for the logical one, if any. I guess there’d
actually be three resolutions, in a way.
…which was all I originally asked for before this got completely
derailed into a discussion about LCD monitors.
Sorry about this; I didn’t mean to derail your thread. [In my defense
though, at least I got you some attention? =)]
From: Rainer Deyke
Subject: Re: [SDL] SDL_Window suggestion
…which was all I originally asked for before this got completely
derailed into a discussion about LCD monitors.Sorry about this; I didn’t mean to derail your thread. [In my defense
though, at least I got you some attention? =)]
Fair enough. :P>----- Original Message ----
From: Gerry JJ
Subject: Re: [SDL] SDL_Window suggestion
SDL could perhaps find the native resolution by querying EDID, or
simpler, just assume that the desktop resolution is the native one,
which is usually the case. ?The latter would also automatically work
with CRT monitors.
That’d be quite tricky to do on many of the backends SDL uses. I don’t
think X11 has a way to let you access EDID data, for example.
I’m pretty sure I could set up a 1280x720 mode on a 4:3 CRT monitor,
and it’d be pretty wrong. Like I said earlier, on a CRT monitor, using
the desktop resolution aspect ratio is not necessarily correct, just
more likely to be a good guess than on an LCD (which might be
sufficient for our purpose, of course).On Fri, May 1, 2009 at 8:06 AM, Gerry JJ wrote:
What does 1.3 have to do with environment variables?
1.2 API is frozen, 1.3 API isn’t.
There is not a lot of development work happening for 1.2, but I
believe an API freeze implies one must retain backward compatibility
with any program using the old API. I do not suppose this includes
adding new API functions or environment variables. If Sam did
intend to freeze adding new API functions, I would not assume this
means environment variables are allowed.
I think what he means by that is that the 1.3 API is not frozen, so
while adding this to 1.3, it could be done in a nicer way than using
wacky environment variables (much like there’s now a more direct
control to pick the video driver, so this is clearly where it’s
going).On Fri, May 1, 2009 at 5:15 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
Since SDL now has built-in support for scaling, it would be nice if we could set up a way to do it automatically. ?Another framework I’ve worked with in the past had a concept of separate physical and logical dimensions, and it was very useful. ?It let you define a constant resolution for your game engine to draw to and preserved that independent of changes to your window size.
Any way we could get this added to SDL 1.3?
Well, here I go jumping in and ignoring 12 days of cranking and semiflaming…
What you are asking for something that is already in OpenGL. And, the
framework you used before probable did it the same way you should do
it in SDL. Set up a full screen window using the current video
resolution. Paint it black. Set up a viewport transform to map your
resolution to the largest box of the correct aspect ratio that will
fit on the current screen and map it to the center of the existing
screen. Do your work in your resolution and just let the transform map
it to the screen you have.
If you are realy clever you can find a screen resolution that the
system supports that is as close to the resolution you want as you can
get and set the screen to that resolution before you set up your
transform.
It is really simple, costs nothing, adds nothing to any existing API,
and works everywhere that OpenGL is available.
Bob PendletonOn Mon, Apr 20, 2009 at 8:11 AM, Mason Wheeler wrote:
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
What you are asking for something that is already in OpenGL. And, the
framework you used before probable did it the same way you should do
it in SDL. Set up a full screen window using the current video
resolution.
That’s an OpenGL only solution, and if it only works in fullscreen mode it’s not too useful for what I’m trying to do. Is there a more general solution?>----- Original Message ----
From: Bob Pendleton
Subject: Re: [SDL] SDL_Window suggestion
Den Fri, 1 May 2009 21:26:40 -0400
skrev Pierre Phaneuf :
SDL could perhaps find the native resolution by querying EDID, or
simpler, just assume that the desktop resolution is the native one,
which is usually the case. ?The latter would also automatically work
with CRT monitors.That’d be quite tricky to do on many of the backends SDL uses. I don’t
think X11 has a way to let you access EDID data, for example.
Yeah, we can probably just forget about EDID … thought I’d at least
mention it though.
I’m pretty sure I could set up a 1280x720 mode on a 4:3 CRT monitor,
and it’d be pretty wrong. Like I said earlier, on a CRT monitor, using
the desktop resolution aspect ratio is not necessarily correct, just
more likely to be a good guess than on an LCD (which might be
sufficient for our purpose, of course).
True. You wouldn’t use that mode for your regular desktop mode though,
would you? I mean, since the desktop resolution is the most used mode, I
don’t think it’s too far fetched to think that most people will have at
least that one properly configured on CRTs, and as for LCDs, does anyone
really use non-native mode for their desktop? (Well, okay, yes, it
happens … it’s definitely the exception though.)
But yeah, it’s not infallible, just the best guess we’ve got that I can
think of (and getting better as CRTs become increasingly rare). In any
case, as David mentioned, some in-game advanced video settings for
people to override the defaults if things turns out looking horrible
would probably be a good idea.
Den Sat, 2 May 2009 09:46:40 -0700 (PDT)
skrev Mason Wheeler :
What you are asking for something that is already in OpenGL. And, the
framework you used before probable did it the same way you should do
it in SDL. Set up a full screen window using the current video
resolution.That’s an OpenGL only solution, and if it only works in fullscreen
mode it’s not too useful for what I’m trying to do. Is there a more
general solution?
You can do this in windowed mode too, but yes, it’s OpenGL only, unless
you add platform-specific code to do the same in other APIs you want
to support. SDL could abstract this so that the same code would work
with OpenGL, DirectX, or whatever else is available.
Subject: Re: [SDL] SDL_Window suggestion
We’re pretty much limited to doing this on the OpenGL and D3D
back-ends because those are the only routes for accessing
hardware-accelerated scaling. It ain’t happening any other way,
really.On Sat, May 2, 2009 at 3:06 PM, Gerry JJ wrote:
Den Sat, 2 May 2009 09:46:40 -0700 (PDT)
skrev Mason Wheeler :
You can do this in windowed mode too, but yes, it’s OpenGL only, unless
you add platform-specific code to do the same in other APIs you want
to support. ?SDL could abstract this so that the same code would work
with OpenGL, DirectX, or whatever else is available.
What you are asking for something that is already in OpenGL. And, the
framework you used before probable did it the same way you should do
it in SDL. Set up a full screen window using the current video
resolution.That’s an OpenGL only solution, and if it only works in fullscreen mode it’s not too useful for what I’m trying to do. ?Is there a more general solution?
Sure, the view port transformation works fine in a window too. You can
transform any range of coordinates to any other range of coordinates.
You can let the player change the size of the window and all you have
to do is change the transform to match the “logical” window to the
"physical" window.
The viewing transform is built into OpenGL, DirectX, and any other 3D
graphics pipeline ever written. You will also find similar things in
2D APIs such as scaled vector graphics. You can find out details of
the transforms in any computer graphics text. 2D and 3D transforms
have been used, for oh, I don’t know, at least 40 years. They were
well established techniques when I started college back in '71. So
they are well understood.
Since I do not know what you are doing I really can’t tell you what to
do… My experience is that making my project fit well established
techniques works a lot better than trying to change things to match my
project. I have several times built 2D transformations into a project.
Transforming the coordinates is not a performance problem on anything
I’ve worked on since the m68000. But, building texture rotation and
scaling code, even 2D code, is a bit of work. OTOH, in 1.3 you might
get a renderer that supports those functions if you are lucky.
SDL contains complete 3D APIs in the form of OpenGL and OpenGLES. It
does not, and never has, contained a complete 2D API. Instead it has a
simple blitter based API that supports the kind of graphics used in
most 2D games. In 1.3 SDL has added the possibility that you will get
a built in blitter that can scale textures for you. That means that
unless you also need texture rotation, you can build scaling into your
code with minimal effort.
Bob PendletonOn Sat, May 2, 2009 at 11:46 AM, Mason Wheeler wrote:
----- Original Message ----
From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] SDL_Window suggestion
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Donny Viszneki wrote:
We’re pretty much limited to doing this on the OpenGL and D3D
back-ends because those are the only routes for accessing
hardware-accelerated scaling. It ain’t happening any other way,
really.
I don’t want scaling. I want to be able to specify logical and physical
resolution separately so that I can avoid scaling. I want black bars.–
Rainer Deyke - rainerd at eldwood.com
Donny Viszneki wrote:
We’re pretty much limited to doing this on the OpenGL and D3D
back-ends because those are the only routes for accessing
hardware-accelerated scaling. It ain’t happening any other way,
really.I don’t want scaling. ?I want to be able to specify logical and physical
resolution separately so that I can avoid scaling. ?I want black bars.
What you want implies scaling. It can only be done using a
transform that scales and translates to make the logical match the
physical.
Bob PendletonOn Sat, May 2, 2009 at 6:17 PM, Rainer Deyke wrote:
–
Rainer Deyke - rainerd at eldwood.com
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
I don’t want scaling. I want to be able to specify logical and physical
resolution separately so that I can avoid scaling. I want black bars.What you want implies scaling. It can only be done using a
transform that scales and translates to make the logical match the
physical.Bob Pendleton
I think what he means is that he wants an API that standardizes and abstracts scaling so we don’t have to come up with a backend-specific way of doing it for every different renderer. (I’d enjoy one of those too!) It’s a pretty reasonable request; that’s the way SDL does most things, afterall…>----- Original Message ----
From: Bob Pendleton
Subject: Re: [SDL] SDL_Window suggestion
Bob Pendleton wrote:> On Sat, May 2, 2009 at 6:17 PM, Rainer Deyke wrote:
I don’t want scaling. I want to be able to specify logical and physical
resolution separately so that I can avoid scaling. I want black bars.What you want implies scaling. It can only be done using a
transform that scales and translates to make the logical match the
physical.
I DO NOT WANT THE LOGICAL RESOLUTION TO MATCH THE PHYSICAL RESOLUTION!!!
Suppose I have a 640x480 game running on a 1024x768 LCD. What I want is
to is this:
Now, I could do all of that on top of SDL. However, there are some
significant advantage to letting SDL handle of this:
–
Rainer Deyke - rainerd at eldwood.com
Den Sat, 2 May 2009 17:59:20 -0400
skrev Donny Viszneki <donny.viszneki at gmail.com>:
We’re pretty much limited to doing this on the OpenGL and D3D
back-ends because those are the only routes for accessing
hardware-accelerated scaling. It ain’t happening any other way,
really.
Right. Still worthwhile though!
(There’s also stuff like OpenGL ES, though this kind of thing is
probably less useful on embedded platforms.)
Den Sat, 02 May 2009 20:29:43 -0600
skrev Rainer Deyke :
I DO NOT WANT THE LOGICAL RESOLUTION TO MATCH THE PHYSICAL
RESOLUTION!!!Suppose I have a 640x480 game running on a 1024x768 LCD. What I want
is to is this:
- Set the screen resolution to 1024x768 to prevent hardware scaling.
- Run the game in a 640x480 portion of the screen.
- Put a black border around the 640x480 portion of the screen that I
am using.
Sure, but what if it’s a 1280x960 LCD? You can do a 2x nearest
neighbour scale, and there’ll be no blurring, and no need for black
bars either. It’d be just like a 640x480 LCD. Better than wasting
75% of the screen, no?
Gerry JJ wrote:
Den Sat, 02 May 2009 20:29:43 -0600
skrev Rainer Deyke :I DO NOT WANT THE LOGICAL RESOLUTION TO MATCH THE PHYSICAL
RESOLUTION!!!Suppose I have a 640x480 game running on a 1024x768 LCD. What I want
is to is this:
- Set the screen resolution to 1024x768 to prevent hardware scaling.
- Run the game in a 640x480 portion of the screen.
- Put a black border around the 640x480 portion of the screen that I
am using.Sure, but what if it’s a 1280x960 LCD? You can do a 2x nearest
neighbour scale, and there’ll be no blurring, and no need for black
bars either. It’d be just like a 640x480 LCD. Better than wasting
75% of the screen, no?
To clarify: I do think that automatic scaling is a useful option, if and
when SDL can perform it efficiently. However, I’m willing to perform
any scaling in client code if doing so yields better performance and/or
better results. For example, I may prefer the scale2x algorithm over
nearest neighbor.
The basic letterbox functionality is much more fundamental and unlikely
to vary between different programs, and is therefore a better candidate
for inclusion in SDL. However, I am not opposed to adding both
features. This means SDL would deal with three different screen
resolutions:
