The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
ArtemMetra


Joined: 23 Oct 2013
Posts: 16
Hi, I have a question about how to use SDL_CreateWindow with SDL_WINDOW_FULLSCREEN_DESKTOP flag set. My game has a resulution of 800x600 and i want to stretch it over the whole screen (Android / Linux). I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 0, 0, SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear"); SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards, Artem
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
neoaggelos


Joined: 02 Jan 2013
Posts: 138
I think that's the expected behavior. Try the same code under Windows or Mac OS X, or even using different render drivers.

Sent from my iPod

On 23 Οκτ 2013, at 5:24 μ.μ., "Artem Metra" wrote:



Quote:
Hi,
I have a question about how to use SDL_CreateWindow with SDL_WINDOW_FULLSCREEN_DESKTOP flag set.
My game has a resulution of 800x600 and i want to stretch it over the whole screen (Android / Linux).
I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
0, 0,
SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards,
Artem



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Jonny D


Joined: 12 Sep 2009
Posts: 932
HOW ABOUT THIS FOR UNEXPECTED BEHAVIOR?

GRRAAAHH!!!


(╯°□°)╯︵ ┻━┻






On Wed, Oct 23, 2013 at 2:19 PM, Sik the hedgehog wrote:
Quote:
I doubt that's the expected behavior...

2013/10/23,:
Quote:
I think that's the expected behavior. Try the same code under Windows or Mac
OS X, or even using different render drivers.

Sent from my iPod

On 23 Οκτ 2013, at 5:24 μ.μ., "Artem Metra" wrote:

Quote:
Hi,
I have a question about how to use SDL_CreateWindow with
SDL_WINDOW_FULLSCREEN_DESKTOP flag set.
My game has a resulution of 800x600 and i want to stretch it over the
whole screen (Android / Linux).
I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
0, 0,
SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and
android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards,
Artem
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Sik


Joined: 26 Nov 2011
Posts: 905
I doubt that's the expected behavior...

2013/10/23,:
Quote:
I think that's the expected behavior. Try the same code under Windows or Mac
OS X, or even using different render drivers.

Sent from my iPod

On 23 Οκτ 2013, at 5:24 μ.μ., "Artem Metra" wrote:

Quote:
Hi,
I have a question about how to use SDL_CreateWindow with
SDL_WINDOW_FULLSCREEN_DESKTOP flag set.
My game has a resulution of 800x600 and i want to stretch it over the
whole screen (Android / Linux).
I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
0, 0,
SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and
android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards,
Artem
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Jonny D


Joined: 12 Sep 2009
Posts: 932
So, does the logical resolution setting stretch to fit the window or does it scale while maintaining aspect ratio?

Jonny D



On Wed, Oct 23, 2013 at 2:29 PM, Jonathan Dearborn wrote:
Quote:
HOW ABOUT THIS FOR UNEXPECTED BEHAVIOR?

GRRAAAHH!!!


(╯°□°)╯︵ ┻━┻






On Wed, Oct 23, 2013 at 2:19 PM, Sik the hedgehog wrote:
Quote:
I doubt that's the expected behavior...

2013/10/23,:
Quote:
I think that's the expected behavior. Try the same code under Windows or Mac
OS X, or even using different render drivers.

Sent from my iPod

On 23 Οκτ 2013, at 5:24 μ.μ., "Artem Metra" wrote:

Quote:
Hi,
I have a question about how to use SDL_CreateWindow with
SDL_WINDOW_FULLSCREEN_DESKTOP flag set.
My game has a resulution of 800x600 and i want to stretch it over the
whole screen (Android / Linux).
I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
0, 0,
SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and
android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards,
Artem
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org







Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

There are a couple bugs in SDL_RenderSetLogicalSize:
- it always attempts to preserve the aspect ratio of the underlying window, whether or not your specified logical size matches this aspect ratio, enforcing this with letterboxing if necessary
- it adds a scaling constant to internal calculations, meaning that SDL render operations now use a different coordinate system than raw API operations. (Trying to render to a location such as (25,40) will give very different results with SDL_RenderCopy or OpenGL draw calls.)

Neither of these are correct behavior. As the person who invented SDL_RenderSetLogicalSize in the first place, I can say that with authority. Both of these behaviors are neither correct, desired, intended, or appreciated. It's been implemented very badly, and needs to be fixed.


Mason



From: Artem Metra
To:
Sent: Wednesday, October 23, 2013 7:24 AM
Subject: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)


Hi,
I have a question about how to use SDL_CreateWindow with SDL_WINDOW_FULLSCREEN_DESKTOP flag set.
My game has a resulution of 800x600 and i want to stretch it over the whole screen (Android / Linux).
I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
0, 0,
SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards,
Artem





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

Submitted as https://bugzilla.libsdl.org/show_bug.cgi?id=2179

I'm *really* not happy about this. Can we have someone take a look at it please?


Mason



From: Mason Wheeler
To: SDL Development List
Sent: Wednesday, October 23, 2013 12:05 PM
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)


There are a couple bugs in SDL_RenderSetLogicalSize: - it always attempts to preserve the aspect ratio of the underlying window, whether or not your specified logical size matches this aspect ratio, enforcing this with letterboxing if necessary - it adds a scaling constant to internal calculations, meaning that SDL render operations now use a different coordinate system than raw API operations. (Trying to render to a location such as (25,40) will give very different results with SDL_RenderCopy or OpenGL draw calls.)Neither of these are correct behavior. As the person who invented SDL_RenderSetLogicalSize in the first place, I can say that with authority. Both of these behaviors are neither correct, desired, intended, or appreciated. It's been implemented very badly, and needs to be fixed.
Mason

From: Artem Metra To: Sent: Wednesday, October 23, 2013 7:24 AM Subject: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Hi, I have a question about how to use SDL_CreateWindow with SDL_WINDOW_FULLSCREEN_DESKTOP flag set. My game has a resulution of 800x600 and i want to stretch it over the whole screen (Android / Linux). I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 0, 0, SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear"); SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards, Artem




_______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org







_______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Re: Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
defchild


Joined: 04 Nov 2013
Posts: 2
Location: Saint Francis
Hi all,
so is the solution to avoid using SDL_RenderSetLogicalSize() until this is fixed?
Any proposed workarounds?

cheers,
rr



Mason Wheeler wrote:
Submitted as https://bugzilla.libsdl.org/show_bug.cgi?id=2179

I'm *really* not happy about this. Can we have someone take a look at it please?


Mason



From: Mason Wheeler
To: SDL Development List
Sent: Wednesday, October 23, 2013 12:05 PM
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)


There are a couple bugs in SDL_RenderSetLogicalSize: - it always attempts to preserve the aspect ratio of the underlying window, whether or not your specified logical size matches this aspect ratio, enforcing this with letterboxing if necessary - it adds a scaling constant to internal calculations, meaning that SDL render operations now use a different coordinate system than raw API operations. (Trying to render to a location such as (25,40) will give very different results with SDL_RenderCopy or OpenGL draw calls.)Neither of these are correct behavior. As the person who invented SDL_RenderSetLogicalSize in the first place, I can say that with authority. Both of these behaviors are neither correct, desired, intended, or appreciated. It's been implemented very badly, and needs to be fixed.
Mason

From: Artem Metra To: Sent: Wednesday, October 23, 2013 7:24 AM Subject: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Hi, I have a question about how to use SDL_CreateWindow with SDL_WINDOW_FULLSCREEN_DESKTOP flag set. My game has a resulution of 800x600 and i want to stretch it over the whole screen (Android / Linux). I think i did something wrong. What I did is the following:
mWindow = SDL_CreateWindow("", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 0, 0, SDL_WINDOW_FULLSCREEN_DESKTOP);
mRenderer = SDL_CreateRenderer(mWindow, -1, 0);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear"); SDL_RenderSetLogicalSize(mRenderer, 800, 600);
This results in a unstretched result under linux (black borders) and android (blink borders). I have a FULL-HD 16:9 Display.
Have I missunderstand the SDL API or is it a bug?
Best regards, Artem




_______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org







_______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Ryan C. Gordon
Guest

Quote:
so is the solution to avoid using SDL_RenderSetLogicalSize() until this
is fixed?

The letterboxing is not a bug, it's intentional behavior.

Quote:
Any proposed workarounds?

If the letterboxing is a problem, use a logical size with the same
aspect ratio as SDL_GetWindowSize() reports, or don't hardcode your game
to 800x600.

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

Letterboxing in SDL_SetRenderLogicalSize is not intentional behavior; it is a bug. The same goes for the hidden, magical scaling factor it introduces.

I created the API; I know what it's supposed to do, and that's not it. If the behavior was intended by the person who implemented the API in its current form, that person did not understand the API.

Mason On Friday, November 8, 2013 9:06 PM, Ryan C. Gordon wrote:
Quote:
so is the solution to avoid using SDL_RenderSetLogicalSize() until this> is fixed?The letterboxing is not a bug, it's intentional behavior.> Any proposed workarounds?If the letterboxing is a problem, use a logical size with the same aspect ratio as SDL_GetWindowSize() reports, or don't hardcode your game to 800x600.--ryan._______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Pallav Nawani


Joined: 19 May 2011
Posts: 122
Location: Dehradun, India
Why is this a bug?
Letterboxing seems to be a reasonable behaviour if the aspect ratios of
the game and the window are different.

On 11/9/2013 5:21 PM, Mason Wheeler wrote:
Quote:
Letterboxing in SDL_SetRenderLogicalSize is not intentional behavior;
it is a bug. The same goes for the hidden, magical scaling factor it
introduces.

I created the API; I know what it's supposed to do, and that's not
it. If the behavior was intended by the person who implemented the
API in its current form, that person did not understand the API.

Mason


On Friday, November 8, 2013 9:06 PM, Ryan C. Gordon
wrote:

Quote:
so is the solution to avoid using SDL_RenderSetLogicalSize() until this
is fixed?

The letterboxing is not a bug, it's intentional behavior.

Quote:
Any proposed workarounds?

If the letterboxing is a problem, use a logical size with the same
aspect ratio as SDL_GetWindowSize() reports, or don't hardcode your game
to 800x600.

--ryan.



_______________________________________________
SDL mailing list
<mailto:
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

For a very simple reason: If you want letterboxing and the API does not magically provide it, it's not difficult to implement it yourself. But if you don't want letterboxing and the API tries to force it on you, it's a lot more work for you to get it right.

Mason




On Saturday, November 9, 2013 4:36 AM, Pallav Nawani wrote:

Why is this a bug?Letterboxing seems to be a reasonable behaviour if the aspect ratios of the game and the window are different.On 11/9/2013 5:21 PM, Mason Wheeler wrote:> Letterboxing in SDL_SetRenderLogicalSize is not intentional behavior; > it is a bug. The same goes for the hidden, magical scaling factor it > introduces.>> I created the API; I know what it's supposed to do, and that's not > it. If the behavior was intended by the person who implemented the > API in its current form, that person did not understand the API.>> Mason>>> On Friday, November 8, 2013 9:06 PM, Ryan C. Gordon > wrote:>> > so is the solution to avoid using SDL_RenderSetLogicalSize() until this> > is fixed?>> The letterboxing is not a bug, it's intentional behavior.>> > Any proposed workarounds?>> If the letterboxing is a problem, use a logical size with the same> aspect ratio as SDL_GetWindowSize() reports, or don't hardcode your game> to 800x600.>> --ryan.>>>> _______________________________________________> SDL mailing list> <mailto:>http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Ryan C. Gordon
Guest

Quote:
If the behavior was intended by the person who implemented the API in
its current form, that person did not understand the API.

I understand that you don't like how the API evolved from your original
intention, but the thing that makes that function awesome is not that
you can scale drawing operations with it, but that you can call one
function and magically your old game works well on modern hardware: a
320x240 DOS game doesn't have to run in a window that looks like a
postage stamp on a modern display.

Standard monitors have changed from a 4:3 aspect ratio in modern times,
and when you add FULLSCREEN_DESKTOP into the mix, making this work right
for apps that weren't prepared for modern systems, with no fuss, is
insanely powerful stuff.

It might not be specifically what you envisioned, but it's one of the
best new things in SDL2.

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

On Saturday, November 9, 2013 1:45 PM, Ryan C. Gordon wrote:
Quote:
If the behavior was intended by the person who implemented the API in> its current form, that person did not understand the API.>>I understand that you don't like how the API evolved from your original >intention, but the thing that makes that function awesome is not that >you can scale drawing operations with it, but that you can call one >function and magically your old game works well on modern hardware: a >320x240 DOS game doesn't have to run in a window that looks like a >postage stamp on a modern display.
Nothing in the way I designed the API conflicts with this goal, but that is still not the point of the API. The point of it is one very specific piece of functionality that has nothing whatsoever to do with fullscreen: to map a set of pixels with one size onto a window with a different size in pixels. I created this to make it easier to implement zooming in my game editor, and when someone else re-implements it in a way that breaks the intended use case, it is buggy.
Quote:
Standard monitors have changed from a 4:3 aspect ratio in modern times, >and when you add FULLSCREEN_DESKTOP into the mix, making this work right >for apps that weren't prepared for modern systems, with no fuss, is >insanely powerful stuff.

Then there should be a function for that. This is not that function. As it is, the current system violates the First Law of Abstractions: any abstraction that you cannot get underneath when necessary is evil.

As I already pointed out earlier, it's much, much easier to implement letterboxing on top of no letterboxing than it is to implement not-letterboxing on top of forced letterboxing. This alone should prove to any reasonable programmer that this is implemented wrong. As-is, the design essentially says "there is no valid non-letterboxing use case for this functionality," which is just flat-out wrong.>It might not be specifically what you envisioned, but it's one of the >best new things in SDL2.

Not if it's broken for its intended use case, it's not.
Fwd: Re: Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Jorhlok


Joined: 11 May 2013
Posts: 6
whoops gmail app sent this to a personal email rather than the list ---------- Forwarded message ----------
From: "Joshua Brown"
Date: Nov 9, 2013 4:36 PM
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
To: "Mason Wheeler"
Cc:

It might not appeal to a minimalist, but here's how I've been doing it.
I've got my sprites in tile sets. So I have a class where you select which tile and position and transformation. The class uses SDL_RenderCopyEx. I've got a graphics engine class that makes sdl calls including initializing sdl. So I tell it the window resolution and virtual resolution. It divides the window res by the virtual one so get the scaling factor and automatically apply it to position and scaling. So I can have my 16x16 sprite be at 120,112 on a 256x240 "screen" on any window resolution and it will be in the middle.
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Sik


Joined: 26 Nov 2011
Posts: 905
2013/11/9, Ryan C. Gordon:
Quote:

Quote:
If the behavior was intended by the person who implemented the API in
its current form, that person did not understand the API.

I understand that you don't like how the API evolved from your original
intention, but the thing that makes that function awesome is not that
you can scale drawing operations with it, but that you can call one
function and magically your old game works well on modern hardware: a
320x240 DOS game doesn't have to run in a window that looks like a
postage stamp on a modern display.

Standard monitors have changed from a 4:3 aspect ratio in modern times,
and when you add FULLSCREEN_DESKTOP into the mix, making this work right
for apps that weren't prepared for modern systems, with no fuss, is
insanely powerful stuff.

It might not be specifically what you envisioned, but it's one of the
best new things in SDL2.

Huh, that sounds more like it should belong as part of
SDL_WINDOW_FULLSCREEN_DESKTOP itself (especially since it already does
scaling on its own anyway, may as well do the letterboxing in that
stage).

It doesn't help that the name SDL_RenderSetLogicalSize sounds like it
will remap the resolution to the chosen one no matter what, leading to
all these confusions. Even worse, it's perfectly possible to call this
several times in a single frame, allowing for multiple logical
resolutions - what happens if you mix logical resolutions with
different aspect ratios?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Sik


Joined: 26 Nov 2011
Posts: 905
Oh, also: it's perfectly possible for somebody to want a not 1:1 pixel
proportion, especially if it's something emulating old systems (which
more often than not had rectangular pixels instead of square ones,
often in order to save memory). SDL_RenderSetLogicalSize would be
ideal for that except you'd need to get rid of letterboxing. The end
result is that you'll have to use a combination of that and
SDL_RenderSetScale to work around it.

Actually even that doesn't account for other issues... it's a lot
harder than it sounds -_-'
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

On Saturday, November 9, 2013 3:35 PM, Sik the hedgehog wrote:

Quote:
Huh, that sounds more like it should belong as part of>SDL_WINDOW_FULLSCREEN_DESKTOP itself (especially since it already does>scaling on its own anyway, may as well do the letterboxing in that>stage).
Yes, exactly. As far as I can see, Fullscreen is actually the *only* legitimate use case for letterboxing, while it is certainly not the only legitimate use case for logical sizes.
Quote:
It doesn't help that the name SDL_RenderSetLogicalSize sounds like it>will remap the resolution to the chosen one no matter what, leading to>all these confusions.

That's because that's what it was designed to do. Smile
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
All of this is moot, as the functionality has shipped as-is in 2.0 and there are games depending on it.  If you're frustrated with the way it behaves, that's fine, and as discussed previously you're welcome to make a hint to disable letterboxing or create a separate function for what you want.







On Sat, Nov 9, 2013 at 3:39 PM, Mason Wheeler wrote:
Quote:




On Saturday, November 9, 2013 3:35 PM, Sik the hedgehog wrote:


Quote:
Huh, that sounds more like it should belong as part of>SDL_WINDOW_FULLSCREEN_DESKTOP itself (especially since it already does>scaling on its own anyway, may as well do the letterboxing in that >stage).

Yes, exactly.  As far as I can see, Fullscreen is actually the *only* legitimate use case for letterboxing, while it is certainly not the only legitimate use case for logical sizes.
Quote:
It doesn't help that the name SDL_RenderSetLogicalSize sounds like it>will remap the resolution to the chosen one no matter what, leading to>all these confusions.


That's because that's what it was designed to do. Smile








_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

On Saturday, November 9, 2013 4:40 PM, Sam Lantinga wrote:


All of this is moot, as the functionality has shipped as-is in 2.0 and there are games depending on it. If you're frustrated with the way it behaves, that's fine, and as discussed previously you're welcome to make a hint to disable letterboxing or create a separate function for what you want.


You can't be serious. I know the ABI is frozen, but no one ever said that functionality is as well and bug-for-bug compatibility must be maintained from now on forever.

A parable, to put this in perspective:


Once upon a time, an engineer at SDL Motors, Inc came up with a new power steering system. He showed it to the manager, who took a look at it and said "yeah, that looks like a good idea. I'll make sure it ends up in the next model."


When the next model came out, the engineer took the car for a test drive and was horrified by the steering. He went back to the manager and said "this is not the system I designed at all, and it doesn't even work! What have you *done*?!? The wheels won't turn to the right!"


"I improved on your design," the manager said. "It makes closed-loop driving much, much simpler."


"But you broke the basic steering. The wheels won't turn to the right!" he repeated.


"Our NASCAR customers love it!" the manager replied. "What's the problem?"




Moral of the story: I don't care about the NASCAR use case if basic functionality does not work. One ridiculously specific edge case should not and can not be allowed to take priority over general functionality. I don't care about software that depends on a bug, especially in a brand-new system that doesn't have all that much software built against it yet. That's the perfect time to fix it, before it gets a lot of inertia and becomes painful!


If someone built against a version of SDL with the broken API, then if they ever update to a newer SDL build, they'll have to fix it. (And if they don't, they won't have any problems.) It's not like the difference won't show up right away in testing. Everyone (except for Ryan) who is looking at this is saying it's working wrong, and that's because it is. It needs to be fixed. It does not need to have excuses made for not fixing it.


Mason
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Sik


Joined: 26 Nov 2011
Posts: 905
2013/11/10, Mason Wheeler:
Quote:
If someone built against a version of SDL with the broken API, then if they
ever update to a newer SDL build, they'll have to fix it. (And if they
don't, they won't have any problems.)

Actually, I can see this being an issue if SDL is linked dynamically
(the usual case) and not provided directly by the program (e.g. as a
separate package, which is how library are usually installed on
Linux). Then you risk breaking programs by merely changing the
library, as they'll expect different versions of the library.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Jared Maddox
Guest

Quote:
Date: Sat, 9 Nov 2013 18:55:27 -0800 (PST)
From: Mason Wheeler
To: Sam Lantinga, SDL Development List

Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

On Saturday, November 9, 2013 4:40 PM, Sam Lantinga
wrote:

Quote:
All of this is moot, as the functionality has shipped as-is in 2.0 and
there are games depending on it. ?If you're frustrated with the way it
behaves, that's fine, and as discussed previously you're welcome to make
a hint to disable letterboxing or create a separate function for what
you want.

You can't be serious.? I know the ABI is frozen, but no one ever said that
functionality is as well and bug-for-bug compatibility must be maintained
from now on forever.


And how, pray tell, CAN an ABI be frozen if it's functionality is NOT?
I don't know exactly how Pascal (or was it Delphi?) works, but I am
under the impression that it is a static imperative language where you
compile once, not a scripting language where you reinterpret
constantly. How, exactly, did you spend all of this time without being
aware that ABI freezes require STANDARDIZING THE REACTION OF SOMETHING
IN REGARDS TO SPECIFIC STIMULI? An API freeze would be similar:
freezing the functions, structures, and other input values. I can
think of no reasonable way to describe an ABI or API freeze that does
not lock-in intended functionality.

And in this case, Sam and Ryan have stated that this IS the intended
functionality. If you wanted it to behave differently, then you should
have stayed on the subject until ABI freeze.


Personally, I consider the existence of both the *LogicalSize and the
*Scale functions at the same time to be dubious. I do agree that both
behaviors need to be present: we need a way to "trim some off the
sides", and it makes things EASIER if you can set the effective size
of the resulting area, but the names are too similar. Of the two, the
*LogicalSize functions have the worse names. They're either
letter-boxing functions, via the official API, or scaling functions
via your spec; and both meanings can be shoehorned into the name,
because honestly, SDL_RenderSetLogicalSize() only tells you what it
ACTUALLY does if you already know HOW it does that. It does NOT say
that you get letterboxing, neither does it say that you get scaling,
it only says that you're working with such-and-such size of a valid
target. The *Scale functions are much better, as they say right in
their names what they are all about: producing a virtual resolution
from an actual one.

If you want to complain about something, complain about the fact that
the functions are named *LogicalSize instead of *ActiveSize (or
something similar). That is valid, and fixable by adding better-named
versions. I am tempted to say that the correct thing to do with the
*LogicalSize functions is to have them always fail, and create
*ActiveSize versions without the scaling, but that wouldn't be
compliant with the current API.


Quote:
A parable, to put this in perspective:


Once upon a time, an engineer at SDL Motors, Inc came up with a new power
steering system.? He showed it to the manager, who took a look at it and
said "yeah, that looks like a good idea.? I'll make sure it ends up in the
next model."

When the next model came out, the engineer took the car for a test drive and
was horrified by the steering.? He went back to the manager and said "this
is not the system I designed at all, and it doesn't even work!? What have
you *done*?!?? The wheels won't turn to the right!"

"I improved on your design," the manager said.? "It makes closed-loop
driving much, much simpler."

"But you broke the basic steering.? The wheels won't turn to the right!" he
repeated.

"Our NASCAR customers love it!" the manager replied.? "What's the problem?"



A parable, to put this in perspective:

Once upon a time, a technician at Mason Electronics came up with a new
high-voltage high-amperage power supply design. He described it to an
engineer, who thought about it and said "Yeah, that sounds like a good
idea, I'll work out the details and get it produced."

When he needed a power supply for another project he requisitioned one
of the ones that he had designed, and was shocked to see that it used
a different connector than the lower-voltage power supply designs. He
went back to the engineer and said "This is not the power supply I
described! What have you done?!? You have to get some random obscure
connector to work with it that you can't even crimp on!"

"I improved on your idea," the engineer said. "It guarantees that you
won't accidentally fry equipment that uses the connector you suggested
according to the connector's specs."

"But you ruined a basic tenet. You can't use it with common
connectors!" he repeated.

"It follows the already established uses of that connector, thereby
preventing severe damage to equipment." the engineer replied. "What's
the problem?"


The moral of my story: It doesn't matter how you intended for an API
to be used, once it's been specified to act in a way, then you can
only extend that behavior, not break it. We don't care if you consider
it a bug. The amount of software written against SDL2 doesn't matter,
the fact that it has already been officially released with this
behavior does.


Quote:
Moral of the story: I don't care about the NASCAR use case if basic
functionality does not work.? One ridiculously specific edge case should not
and can not be allowed to take priority over general functionality.? I don't
care about software that depends on a bug, especially in a brand-new system
that doesn't have all that much software built against it yet.? That's the
perfect time to fix it, before it gets a lot of inertia and becomes
painful!


A strong desire to avoid calculating real size / desired size is not a
good reason to break existing behavior. Going back to last month, and
the bug ticket, it sounds like you just want scaling. Use
SDL_RenderSetScale(), this is what it exists for. If it doesn't work
quite right, then either you need the current behavior of the
*LogicalSize() functions, or it's a bug. Your proposed behavior is
nothing more than a paper-thin wrapper around the *Scale functions.


Quote:
If someone built against a version of SDL with the broken API, then if they
ever update to a newer SDL build, they'll have to fix it.? (And if they
don't, they won't have any problems.)? It's not like the difference won't
show up right away in testing.? Everyone (except for Ryan) who is looking at
this is saying it's working wrong, and that's because it is.? It needs to be
fixed.? It does not need to have excuses made for not fixing it.


Hahaha, no. If someone built against a version of SDL2 with the
current behavior, then the next time ONE OF THEIR USERS updated the
DYNAMIC LIBRARY, they would have to fix it. SDL isn't really intended
for static-library use, it's intended for dynamic-library use. I have
no idea how YOU use SDL, but the expected use-case is that any user or
application can replace an old version with a new version. As it is, I
think that the current behavior came about when someone was trying to
fix some quirk when dealing with X11 back around the summer, but that
doesn't really matter, because your behavior sounds this simple:

int ScaleToSize( SDL_Window *win, int w, int h )
{
int rw, rh, res;

if( w <= 0 || h <= 0 )
{
SDL_SetError( "SetEffectiveSize() was given null-dimensions." );

return( -1 );
}

SDL_GetWindowSize( win, &rw, &rw );
res = SDL_RenderSetLogicalSize( SDL_GetRenderer( win ), rw, rh );
return( res == 0 ? SDL_RenderSetScale( SDL_GetRenderer( win ), rw /
w, rh / h ) : res );
}

If it isn't so simple, then please, clarify.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

Quote:
On Saturday, November 9, 2013 9:20 PM, Jared Maddox wrote:
Quote:
Date: Sat, 9 Nov 2013 18:55:27 -0800 (PST)
From: Mason Wheeler
To: Sam Lantinga, SDL Development List

Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

You can't be serious.? I know the ABI is frozen, but no one ever said that
functionality is as well and bug-for-bug compatibility must be maintained
from now on forever.

And how, pray tell, CAN an ABI be frozen if it's functionality is NOT?
I don't know exactly how Pascal (or was it Delphi?) works, but I am
under the impression that it is a static imperative language where you
compile once, not a scripting language where you reinterpret
constantly.

That's correct.

Quote:
How, exactly, did you spend all of this time without being
aware that ABI freezes require STANDARDIZING THE REACTION OF SOMETHING
IN REGARDS TO SPECIFIC STIMULI?

Because that's not what it means. It means the Application Binary Interface--the specification by which the program communicates with the DLL--is frozen. It means you don't rename existing functions or change their parameter lists. It doesn't say you don't change their implementation.

And even if it did, that doesn't mean you don't fix bugs. Yes, there are some extreme cases where widely-used bugs end up grandfathered in as features because users depend on them. Microsoft Windows is one such case, where they have some engineers who go to extreme lengths to maintain bug-for-bug compatibility that stretches back for decades, because it has literally millions of pieces of software written for it, many of which won't ever be updated.

SDL, as popular as it is, is not adopted on that scale.

Quote:
An API freeze would be similar: freezing the functions, structures, and other input values. I
can think of no reasonable way to describe an ABI or API freeze that does not lock-in
intended functionality.

The intended functionality has nothing whatsoever to do with fullscreen or letterboxing. This is an incorrect reimplementation of the specified behavior that cripples the functionality by promoting one ridiculously specific edge case to supremacy at the cost of ruining all other functionality.

Quote:
And in this case, Sam and Ryan have stated that this IS the intended
functionality.

Sam and Ryan didn't design it. I did.

Quote:
If you wanted it to behave differently, then you should
have stayed on the subject until ABI freeze.

I was working on another project at the time the ABI was frozen, or I would have noticed this sooner.

Quote:
Personally, I consider the existence of both the *LogicalSize and the
*Scale functions at the same time to be dubious.

As do I. LogicalSize works much better; the Scale code is poorly thought out and poorly implemented, and breaks a lot of other code--as I've already pointed out earlier in this discussion--and IMO it should never have been put in. LogicalSize rendered it obsolete before it was ever invented.

Quote:
I do agree that both
behaviors need to be present: we need a way to "trim some off the
sides", and it makes things EASIER if you can set the effective size
of the resulting area, but the names are too similar. Of the two, the
*LogicalSize functions have the worse names. They're either
letter-boxing functions, via the official API, or scaling functions
via your spec; and both meanings can be shoehorned into the name,
because honestly, SDL_RenderSetLogicalSize() only tells you what it
ACTUALLY does if you already know HOW it does that.

It tells me exactly what it does, because I got the name and the concept from the Asphyre library, and it's supposed to do exactly what it does on Asphyre. Razz

Quote:
It does NOT say
that you get letterboxing, neither does it say that you get scaling,
it only says that you're working with such-and-such size of a valid
target. The *Scale functions are much better, as they say right in
their names what they are all about: producing a virtual resolution
from an actual one.

Scale says nothing about letterboxing either, and it doesn't even say anything about size. All it says is that your drawing gets scaled. One really important thing that it doesn't say is that the scaling isn't actually applied by setting a logical size, but by adding an automagical scaling constant under the hood, which means SDL's virtual resolution is now out of sync with raw API drawing commands and if you are trying to use both in the same program, it will screw up all your graphics. That one really came as a shock to me, because I need both because I'm doing things that SDL has no APIs for!

Quote:
Quote:
Moral of the story: I don't care about the NASCAR use case if basic
functionality does not work.? One ridiculously specific edge case should not
and can not be allowed to take priority over general functionality.? I don't
care about software that depends on a bug, especially in a brand-new system
that doesn't have all that much software built against it yet.? That's the
perfect time to fix it, before it gets a lot of inertia and becomes
painful!

A strong desire to avoid calculating real size / desired size is not a
good reason to break existing behavior.

Why are you putting words in my mouth?

This implementation does break existing behavior. Specifically, it broke mine. It breaks anyone's who is using this and trying to use raw OpenGL in their program. That's why I'm trying to get it fixed, and I find this fetishistic clinging to one narrow edge case, which has nothing whatsoever to do with the intended use in the first place, as justification for not fixing it absurd!

Quote:
Going back to last month, and
the bug ticket, it sounds like you just want scaling. Use
SDL_RenderSetScale(), this is what it exists for.

Again, SDL_RenderSetScale is fundamentally broken. The only way to make it not be fundamentally broken would be to re-implement it in terms of SDL_SetLogicalSize (the version I implemented.) Instead, we have a FrankenAPI in which SDL_SetLogicalSize is implemented in terms of SDL_RenderSetScale.

Quote:
If it doesn't work
quite right, then either you need the current behavior of the
*LogicalSize() functions, or it's a bug.

What I need is exactly what I implemented when I created the function. Otherwise, I'd have created it differently.

Quote:
Your proposed behavior is
nothing more than a paper-thin wrapper around the *Scale functions.

The Scale functions didn't exist when I wrote this, and if I'd have written Scale functions instead, I'd have implemented them under the hood in the same way I implemented LogicalSize, because the current implementation is broken. But the Scale functions are just fundamentally a worse idea, because now you have to worry about rounding errors. With LogicalSize, you specify exactly how many pixels you want your logical canvas to contain, and that's exactly what you get.

Quote:
Quote:
If someone built against a version of SDL with the broken API, then if they
ever update to a newer SDL build, they'll have to fix it.? (And if they
don't, they won't have any problems.)? It's not like the difference won't
show up right away in testing.? Everyone (except for Ryan) who is looking at
this is saying it's working wrong, and that's because it is.? It needs to be
fixed.? It does not need to have excuses made for not fixing it.

Hahaha, no. If someone built against a version of SDL2 with the
current behavior, then the next time ONE OF THEIR USERS updated the
DYNAMIC LIBRARY, they would have to fix it. SDL isn't really intended
for static-library use, it's intended for dynamic-library use. I have
no idea how YOU use SDL, but the expected use-case is that any user or
application can replace an old version with a new version.

*blink*

Are you trolling me or something? What is this, the 1990s? Are you installing the DLL to \windows\system32 and expecting to be able to leave it there and have everything magically work? Did you learn nothing from the horrors that thousands of clueless Visual Basic developers unleashed upon millions of computers worldwide by doing exactly that? We've known for decades that that's exactly the wrong way to deploy a DLL. Even if you don't bake SDL into your binary as a static library, you still drop the DLL in the same folder that you install the EXE to so that other programs can't screw it up. Are you seriously advocating deploying SDL the 1990s way? No wonder you're worried about this! o_0

Quote:
As it is, I
think that the current behavior came about when someone was trying to
fix some quirk when dealing with X11 back around the summer, but that
doesn't really matter, because your behavior sounds this simple:

int ScaleToSize( SDL_Window *win, int w, int h )
{
int rw, rh, res;

if( w <= 0 || h <= 0 )
{
SDL_SetError( "SetEffectiveSize() was given null-dimensions." );

return( -1 );
}

SDL_GetWindowSize( win, &rw, &rw );
res = SDL_RenderSetLogicalSize( SDL_GetRenderer( win ), rw, rh );
return( res == 0 ? SDL_RenderSetScale( SDL_GetRenderer( win ), rw /
w, rh / h ) : res );
}

If it isn't so simple, then please, clarify.

See above, re: Scale is fundamentally broken.

Mason
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
gabomdq


Joined: 28 Jul 2011
Posts: 495
Location: Argentina
2013/11/9 Mason Wheeler
Quote:
On Saturday, November 9, 2013 4:40 PM, Sam Lantinga wrote:


All of this is moot, as the functionality has shipped as-is in 2.0 and there are games depending on it.  If you're frustrated with the way it behaves, that's fine, and as discussed previously you're welcome to make a hint to disable letterboxing or create a separate function for what you want.


You can't be serious.  I know the ABI is frozen, but no one ever said that functionality is as well and bug-for-bug compatibility must be maintained from now on forever.





FWIW, I do think you have a valid point on this, specifically that the letterboxing stuff should be opt in rather than default. I also think that the abrassive attitude with which you state these points has more chances of starting a flame war than driving your arguments across, but that's just my personal point of view. SDL is quite an open project and both Sam and Ryan are receptive to almost anything you throw at them, but in the end they have the final say, thankfully. Also, keep in mind that given the license and easy fork process you can always get your SDL2+ version out in the open in no time.


If it were up to me, I'd take what Sam suggested, add a hint to disable letterboxing. When 2.1 comes, we can probably discuss if it makes sense to redefine that function with an extra parameter to add or not letterboxing, and deprecate the hint. 
 

--
Gabriel.
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

*sigh* I'm sorry. I don't mean to be abrasive. It just always comes as a bit of a shock to me when I say something that should be obvious and people who really ought to understand it don't. It gets in the way of effective communication, and I don't always react well to that. I'll try to tone it down in the future.Mason


On Sunday, November 10, 2013 4:53 AM, Gabriel Jacobo wrote:

2013/11/9 Mason Wheeler
Quote:
On Saturday, November 9, 2013 4:40 PM, Sam Lantinga wrote:

All of this is moot, as the functionality has shipped as-is in 2.0 and there are games depending on it. If you're frustrated with the way it behaves, that's fine, and as discussed previously you're welcome to make a hint to disable letterboxing or create a separate function for what you want.
You can't be serious. I know the ABI is frozen, but no one ever said that functionality is as well and bug-for-bug compatibility must be maintained from now on forever.


FWIW, I do think you have a valid point on this, specifically that the letterboxing stuff should be opt in rather than default. I also think that the abrassive attitude with which you state these points has more chances of starting a flame war than driving your arguments across, but that's just my personal point of view. SDL is quite an open project and both Sam and Ryan are receptive to almost anything you throw at them, but in the end they have the final say, thankfully. Also, keep in mind that given the license and easy fork process you can always get your SDL2+ version out in the open in no time.

If it were up to me, I'd take what Sam suggested, add a hint to disable letterboxing. When 2.1 comes, we can probably discuss if it makes sense to redefine that function with an extra parameter to add or not letterboxing, and deprecate the hint.



-- Gabriel.
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Sik


Joined: 26 Nov 2011
Posts: 905
2013/11/10, Mason Wheeler:
Quote:
Because that's not what it means. It means the Application Binary
Interface--the specification by which the program communicates with the
DLL--is frozen. It means you don't rename existing functions or change
their parameter lists. It doesn't say you don't change their
implementation.

An ABI freeze implies an API freeze.

Quote:
And even if it did, that doesn't mean you don't fix bugs.

That's the problem, it's not a bug, it's the decided intended behavior
for SDL 2.0, and as such it can't be changed without breaking any
program built against it. It's not like the prerelease versions where
programs could break at any moment since the API wasn't finished yet.

Quote:
Sam and Ryan didn't design it. I did.

And? They're the ones that call the shots (in particular Sam). If Sam
decides that there should be a new function with that name that does
something completely different, you can do nothing about it, except
forking SDL and renaming the library to something else.

Quote:
Scale says nothing about letterboxing either, and it doesn't even say
anything about size. All it says is that your drawing gets scaled. One
really important thing that it doesn't say is that the scaling isn't
actually applied by setting a logical size, but by adding an automagical
scaling constant under the hood, which means SDL's virtual resolution is now
out of sync with raw API drawing commands and if you are trying to use both
in the same program, it will screw up all your graphics. That one really
came as a shock to me, because I need both because I'm doing things that SDL
has no APIs for!

Huh... I'm trying to understand what's the issue here. I could argue
SetLogicalSize makes the virtual resolution out of sync with the real
resolution which will bring problems as well. It's pretty much
expected with any sort of scaling.

Quote:
Why are you putting words in my mouth?

This implementation does break existing behavior. Specifically, it broke
mine. It breaks anyone's who is using this and trying to use raw OpenGL in
their program. That's why I'm trying to get it fixed, and I find this
fetishistic clinging to one narrow edge case, which has nothing whatsoever
to do with the intended use in the first place, as justification for not
fixing it absurd!

Was your program coded against the release SDL 2.0 or against the
versions before that? Because you can't complain about your program
breaking if you knowingly made it for an API that wasn't stable yet.
You knew perfectly well things could change at any moment and you had
to be ready to account for that.

The "don't break existing behavior" rule is against the release 2.0,
not against any programs made before that.

Quote:
Are you trolling me or something? What is this, the 1990s? Are you
installing the DLL to \windows\system32 and expecting to be able to leave it
there and have everything magically work? Did you learn nothing from the
horrors that thousands of clueless Visual Basic developers unleashed upon
millions of computers worldwide by doing exactly that? We've known for
decades that that's exactly the wrong wayto deploy a DLL. Even if you don't
bake SDL into your binary as a static library, you still drop the DLL in the
same folder that you install the EXE to so that other programs can't screw
it up. Are you seriously advocating deploying SDL the 1990s way? No wonder
you're worried about this! o_0

Huh, have you ever deployed a program on Linux at all? On Linux it's
indeed that way, shared libraries are installed separately as their
own packages, and they're global to the entire system. The problem is
very much alive in the case of Linux.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Mason Wheeler
Guest

Quote:
On Sunday, November 10, 2013 11:09 AM, Sik the hedgehog wrote:
An ABI freeze implies an API freeze.
Neither of which implies a freeze on functionality or bug fixing.
Quote:
That's the problem, it's not a bug, it's the decided intended behavior>for SDL 2.0, and as such it can't be changed without breaking any>program built against it.

Why do people keep bringing up things I've already explained? Fixing this bug won't break any released software, unless they update their software to use an updated version of SDL2, in which case the new behavior will certainly be caught in testing, and the software updated to match. This is a non-issue.
Quote:
Huh... I'm trying to understand what's the issue here. I could argue>SetLogicalSize makes the virtual resolution out of sync with the real>resolution which will bring problems as well. It's pretty much>expected with any sort of scaling.
I know I said I'd try to stop being inflammatory, but... are you being deliberately obtuse here, or do you just not understand the implications of the magical scaling constant inside of SDL?

OK, actual example. Maybe this will make more sense:

Like most games, one of the things my game engine needs to be able to do is draw text. Part of the requirements is that the text gets drawn in colored gradients defined by an image that gets shipped with the game. This means that the text-drawing routine needs to draw the shape of the letters, with the colors taken from the image, and that requires multisampling. (And the actual requirements are a bit more complex still, requiring specialized shaders, but going into too many details would confuse things.)

There is nothing in SDL, or any addon library, that can do that, therefore I have to handle it in raw OpenGL. The game runs at 320x240 resolution, in a window 960x720 pixels in size. (3:1 in both dimensions.) I set this up with SDL_RenderSetLogicalSize.

In my original implementation of SDL_RenderSetLogicalSize, this was implemented by using glViewport, so that the renderer only had 320x240 pixels worth of space to draw to. All scaling was handled by the GL.

In the new, broken implementation, this is handed by keeping a viewport size of 960x720 and setting a magical 3:1 scaling constant in the SDL renderer, so that everything that gets drawn with an SDL call has all of its coordinates multiplied by 3.0 to make it look like it's being drawn onto a smaller viewport.

But then I try to render some text, and the Law of Leaky Abstractions rears its ugly head. If I try to render a letter at (20, 180), that's supposed to be towards the top of the lower 1/3 of the screen. But instead, it shows up *tiny* in the upper-left corner, because I can't render this through SDL and my OpenGL code doesn't know about the magical scaling constant being applied internally by the SDL library.

I hope that makes sense, because I'm not sure I can explain any more clearly than that why the current implementation of scaling is fundamentally broken.

Quote:
Quote:
Are you trolling me or something? What is this, the 1990s? Are you>> installing the DLL to \windows\system32 and expecting to be able to leave it>> there and have everything magically work? Did you learn nothing from the>> horrors that thousands of clueless Visual Basic developers unleashed upon>> millions of computers worldwide by doing exactly that? We've known for>> decades that that's exactly the wrong wayto deploy a DLL. Even if you don't>> bake SDL into your binary as a static library, you still drop the DLL in the>> same folder that you install the EXE to so that other programs can't screw>> it up. Are you seriously advocating deploying SDL the 1990s way? No wonder>> you're worried about this! o_0
Huh, have you ever deployed a program on Linux at all? On Linux it's>indeed that way, shared libraries are installed separately as their>own packages, and they're global to the entire system. The problem is>very much alive in the case of Linux.
*sigh* You're *really* not making this "non-inflammatory* thing easy. I could make a very long and involved rant on the subject. Instead, I will courteously condense it down to a much shorter rant that covers only the most relevant points.

That right there is a perfect example of why desktop Linux never took off and never will. The *nix culture is not, as I intimated above, still stuck in the 1990s; they're still stuck in the 1970s, refusing to acknowledge the simple fact that, ever since the release of the original Apple Macintosh, the art of computer system design has evolved and left them far behind. They may occasionally pay lip service to modern reality--and the ones that do the best job of it (Ubuntu comes to mind immediately) are the ones that have come the closest to actually gaining some semblance of mainstream acceptance--but at its core are a bunch of philosophical principles that are completely out of line with everything we've learned about building good, solid systems since the year 1984!

Perhaps the best expression of the problem comes from Eric Raymond himself, when he published on his blog this rather frank email he received (excerpted):

Quote:
What I realized is that Linux is not a
code base. Or a distro. Or a kernel. It's an attitude. And it's
not about Open Source. It's about a bunch of people who still think
vi is a good config UI.

Also, it's worth noting that, in the case of the only two *nix systems to gain widespread adoption by end users--namely iOS and Android--this problem does not exist. In iOS, there are no dynamic libraries aside from the ones provided by the OS, and in Android dynamic libraries are allowed, but they're kept as part of the app bundle and not shared between programs.
</rant>

But anyway, that's getting way off-topic. The point is, any well-designed project (even for Linux) is going to manage its own dependencies.

Mason
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Jared Maddox
Guest

Quote:
Date: Sun, 10 Nov 2013 04:34:19 -0800 (PST)
From: Mason Wheeler
To: SDL Development List
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Quote:
On Saturday, November 9, 2013 9:20 PM, Jared Maddox
wrote:

Quote:
Quote:
Date: Sat, 9 Nov 2013 18:55:27 -0800 (PST)
From: Mason Wheeler
To: Sam Lantinga,??? SDL Development List
???
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:
???
Content-Type: text/plain; charset="iso-8859-1"

You can't be serious.? I know the ABI is frozen, but no one ever said
that
functionality is as well and bug-for-bug compatibility must be
maintained
from now on forever.

And how, pray tell, CAN an ABI be frozen if it's functionality is NOT?
I don't know exactly how Pascal (or was it Delphi?) works, but I am
under the impression that it is a static imperative language where you
compile once, not a scripting language where you reinterpret
constantly.

That's correct.


Actually, now that I've gotten a chance to sleep, this wouldn't even
be acceptable behavior for a scripting language after an ABI or API
freeze unless the language included a REALLY good implementation of
those Concepts that some people have suggested for C++, and even then
it would depend on how those were used. This is a change to behavior,
and a change to STATED behavior on an API level is ALWAYS a change to
stated behavior on an ABI level. If the particular inputs to whatever
functions were previously not defined to have ANY behavior then you
can get away with it because you haven't broken any ABI behavior, but
what you are suggesting IS a change to the stated results of an
already-specified input.


Quote:
Quote:
How, exactly, did you spend all of this time without being
aware that ABI freezes require STANDARDIZING THE REACTION OF SOMETHING
IN REGARDS TO SPECIFIC STIMULI?

Because that's not what it means.? It means the Application Binary
Interface--the specification by which the program communicates with the
DLL--is frozen.? It means you don't rename existing functions or change
their parameter lists.? It doesn't say you don't change their
implementation.


Hahahahaha, how do you even manage to use .dlls, and why do you even
trust them enough to try? The only way for your description to make
any sense is if you're talking about the way that a compiler compiles
down functions and data to object files, it has absolutely no relation
to the ABIs exposed by programs (and even in the case of languages,
it's just because they define that ABI so that programs can rely on a
predictable API-to-ABI translation, without this there would be NO
dynamic library support by ANY operating system, and you couldn't EVER
safely use the object files produced by another compiler, whether
static libraries, dynamic, or just plain object files). Program ABIs
freeze when a specific set of machine-level inputs always provide a
defined set of machine-level responses; in a pure-functional language
this would be even stricter, as there would only get to be ONE
acceptable response to any particular input.

To put it anther way: implementation doesn't matter, whether the
implementation follows the stated behaviors of the ABI (and thus, the
API) does matter.


Quote:
And even if it did, that doesn't mean you don't fix bugs.? Yes, there are
some extreme cases where widely-used bugs end up grandfathered in as
features because users depend on them.? Microsoft Windows is one such case,
where they have some engineers who go to extreme lengths to maintain
bug-for-bug compatibility that stretches back for decades, because it has
literally millions of pieces of software written for it, many of which won't
ever be updated.


Inconsequential. Those behaviors were not part of the spec, the
behaviors that you are arguing against ARE part of the spec. And guess
what? You DON'T get to define the spec, because you're no more part of
the project than Sik or me. Sam & Ryan are the ultimate authorities in
this, the rest of us are just trying to explain to you WHAT the
situation is, because you are demonstrating a clear lack of
understanding on THAT (as demonstrated by your misunderstanding of
what an ABI freeze is).


Quote:
SDL, as popular as it is, is not adopted on that scale.


Doesn't matter. If you aren't going to stick to an ABI freeze then you
shouldn't announce it. If you announce it, then you cannot justify
reversing your position.


Quote:
Quote:
An API freeze would be similar: freezing the functions, structures, and
other input values. I
can think of no reasonable way to describe an ABI or API freeze that does
not lock-in
intended functionality.

The intended functionality has nothing whatsoever to do with fullscreen or
letterboxing.? This is an incorrect reimplementation of the specified
behavior that cripples the functionality by promoting one ridiculously
specific edge case to supremacy at the cost of ruining all other
functionality.


The intended functionality is whatever Sam & Ryan declare it to be. If
I donate a software triangle renderer to SDL and Sam & Ryan change
it's API before release then their version is the official version.
Period.


Quote:
Quote:
And in this case, Sam and Ryan have stated that this IS the intended
functionality.

Sam and Ryan didn't design it.? I did.


If it was a function in an extension library that you were at the head
of then this would matter. It is NOT part of such an extension
library, and therefor this is inconsequential, much like the color of
the sky when you're stuck in a bunker half a mile underground.


Quote:
Quote:
If you wanted it to behave differently, then you should
have stayed on the subject until ABI freeze.

I was working on another project at the time the ABI was frozen, or I would
have noticed this sooner.


I half-recall discussions about the change sometime back around the
winter, I think some time after all the talk about the new submission
for an X11 fullscreen spec. I wasn't especially interested in it. If
you were actually interested, then I would expect you to have actually
perked up your ears a bit. You ARE on the mailinglist instead of the
forums, right? Considering the question marks inserted after every
sentence that I see from you, I doubt that you're using the forum
interface.


Quote:
Quote:
Personally, I consider the existence of both the *LogicalSize and the
*Scale functions at the same time to be dubious.

As do I.? LogicalSize works much better; the Scale code is poorly thought
out and poorly implemented, and breaks a lot of other code--as I've already
pointed out earlier in this discussion--and IMO it should never have been
put in.? LogicalSize rendered it obsolete before it was ever invented.


Scale performs the mathematical operation in question: it modifies
coordinates to reflect a conversion in unit size. It is perfectly
justified and should always be reliable for those who have a reason to
use it, that being those who use the render API. The only thing
missing at that point is clipping and mathematical translation, and
what do you know, both should be provided by the viewport functions
(and I know this from just looking at the code).


Quote:
Quote:
I do agree that both
behaviors need to be present: we need a way to "trim some off the
sides", and it makes things EASIER if you can set the effective size
of the resulting area, but the names are too similar. Of the two, the
*LogicalSize functions have the worse names. They're either
letter-boxing functions, via the official API, or scaling functions
via your spec; and both meanings can be shoehorned into the name,
because honestly, SDL_RenderSetLogicalSize() only tells you what it
ACTUALLY does if you already know HOW it does that.

It tells me exactly what it does, because I got the name and the concept
from the Asphyre library, and it's supposed to do exactly what it does on
Asphyre. Razz


Then Asphyre should have used the word "Scale" in the name, because
your proposal is to scale the screen coordinates. This is a standard
part of mathematics in coordinate spaces.

I hate to suggest other libraries, but if Ashpyre does what you need,
why aren't you using it? It quick Google search suggests that it's
even designed for the language you actually code in.


Quote:
Quote:
It does NOT say
that you get letterboxing, neither does it say that you get scaling,
it only says that you're working with such-and-such size of a valid
target. The *Scale functions are much better, as they say right in
their names what they are all about: producing a virtual resolution
from an actual one.

Scale says nothing about letterboxing either, and it doesn't even say
anything about size.?

Scale doesn't say anything about letterboxing because scaling has
nothing to do with letterboxing. Scaling is the conversion of one
unit-size to another unit-size. Scaling something by 0.5 scales it to
half of it's former length on each size (for a square, scaling it to
one fourth of it's previous area, for a cube scaling it to one eighth
it's previous volume). It's a well-defined operation, and the
underlying concept behind such things as converting from inches to
centimeters. It also works regardless of letterboxing, as it acts as a
conversion ratio and nothing else.

Letterboxing is mathematical Translation + a clipping region.


Quote:
All it says is that your drawing gets scaled.? One
really important thing that it doesn't say is that the scaling isn't
actually applied by setting a logical size, but by adding an automagical
scaling constant under the hood, which means SDL's virtual resolution is now
out of sync with raw API drawing commands and if you are trying to use both
in the same program, it will screw up all your graphics.? That one really
came as a shock to me, because I need both because I'm doing things that SDL
has no APIs for!


Because it's part of the rendering API, and should be easy enough for
anyone to hook into if they need to operate alongside said API.


Quote:
Quote:
Quote:
Moral of the story: I don't care about the NASCAR use case if basic
functionality does not work.? One ridiculously specific edge case should
not
and can not be allowed to take priority over general functionality.? I
don't
care about software that depends on a bug, especially in a brand-new
system
that doesn't have all that much software built against it yet.? That's
the
perfect time to fix it, before it gets a lot of inertia and becomes
painful!

A strong desire to avoid calculating real size / desired size is not a
good reason to break existing behavior.

Why are you putting words in my mouth?

This implementation does break existing behavior.? Specifically, it broke
mine.? It breaks anyone's who is using this and trying to use raw OpenGL in
their program.? That's why I'm trying to get it fixed, and I find this
fetishistic clinging to one narrow edge case, which has nothing whatsoever
to do with the intended use in the first place, as justification for not
fixing it absurd!


"Existing behavior" in this case was me referring to the SDL2
behavior. Until the official release of SDL2, there was not properly
such a thing as SDL2 + OpenGL behavior, because there was no official
SDL2 to exist in that equation. Existing behavior is NOT defined
solely in terms on OpenGL, nor is it defined in terms of DESIRED
behavior, it is defined in terms of what exists. Existing behavior
that Sam and Ryan declare a bug can be removed with a patch, all other
forms of existing behavior can only be eliminated by the addition of
an API that explicitly triggers such a thing:

Which, if you can be bothered to remember, Sam has already said that
he's OK with. Your arguments for changing the behavior in the way that
you want are a non-starter. No matter how much you argue you won't get
your way on it. You CAN get your way with a hint, but the longer that
you argue the longer you'll have to wait before it happens, because
noone will be bothering with it, since it isn't their pet feature.


Quote:
Quote:
If it doesn't work
quite right, then either you need the current behavior of the
*LogicalSize() functions, or it's a bug.

What I need is exactly what I implemented when I created the function.?
Otherwise, I'd have created it differently.


Then you should have gotten an extensions API in, and written it up as
an extension. An extensions API can consist of as little as:

unsigned SDL_GetExtensionAPIMajorVersion();

If you get back 0 or 1 (1 to prevent peop[le from asking if it's 0
indexed or 1 indexed) then you know the extension api isn't supported.
Anything higher and you know that you can call other Extension API
functions. Which is important, because you can use the major version
to introduce incompatible API changes without worrying about anything
else, thereby divorcing Extension API compatibility and SDL2 internals
compatibility from the rest of SDL2's compatibility.


Quote:
Quote:
Your proposed behavior is
nothing more than a paper-thin wrapper around the *Scale functions.

The Scale functions didn't exist when I wrote this, and if I'd have written
Scale functions instead, I'd have implemented them under the hood in the
same way I implemented LogicalSize, because the current implementation is
broken.?

You haven't explained why the Scale functions are broken, only that
they don't work transparently for people using the Render API in
conjunction with the APIs that SDL2 is built on top of. This is not a
good definition of "broken", only of "useless for my use-case". A
usecase that can apparently be met via a very small piece of OpenGL
code.


Quote:
But the Scale functions are just fundamentally a worse idea,
because now you have to worry about rounding errors.? With LogicalSize, you
specify exactly how many pixels you want your logical canvas to contain, and
that's exactly what you get.


Ah, finally you get to something that can be taken seriously, instead
of coming across as differences of opinion in regards to an actual
implementation. But it doesn't really matter, since you can always
change the hidden structures to use a double or long double, and add a
function that accepts the same. Since accuracy won't be lost with the
change, the original Scale functions retain their behavior, and ABI
compatibility is preserved.


Quote:
Quote:
Quote:
If someone built against a version of SDL with the broken API, then if
they
ever update to a newer SDL build, they'll have to fix it.? (And if they
don't, they won't have any problems.)? It's not like the difference
won't
show up right away in testing.? Everyone (except for Ryan) who is looking
at
this is saying it's working wrong, and that's because it is.? It needs to
be
fixed.? It does not need to have excuses made for not fixing it.

Hahaha, no. If someone built against a version of SDL2 with the
current behavior, then the next time ONE OF THEIR USERS updated the
DYNAMIC LIBRARY, they would have to fix it. SDL isn't really intended
for static-library use, it's intended for dynamic-library use. I have
no idea how YOU use SDL, but the expected use-case is that any user or
application can replace an old version with a new version.

*blink*

Are you trolling me or something?? What is this, the 1990s?? Are you
installing the DLL to \windows\system32 and expecting to be able to leave it
there and have everything magically work?? Did you learn nothing from the
horrors that thousands of clueless Visual Basic developers unleashed upon
millions of computers worldwide by doing exactly that?? We've known for
decades that that's exactly the wrong wayto deploy a DLL.? Even if you don't
bake SDL into your binary as a static library, you still drop the DLL in the
same folder that you install the EXE to so that other programs can't screw
it up.? Are you seriously advocating deploying SDL the 1990s way?? No wonder
you're worried about this! o_0


Are you seriously unaware that SDL 1 & 2 are BOTH designed to be
compatible with this? If thy were not then they would not HAVE dynamic
library versions, because forcing developers to expose the behaviors
that they wanted would formalize the intended use of the library. The
use of dynamic libraries meant to be used by other projects carries
with it the requirement that any time that you break compatibility you
also increment the file name, as anyone who has any business writing a
dynamic library can tell you. You've already gotten a response
pointing out that this is how it works in the *nix world, and most
other places that use dynamic libraries as well, it's only in the
Microsoft environment that anyone thinks that doing otherwise is
acceptable.

And even if that weren't the case, it wouldn't matter, because the
user is supposed to be able to take the SDL2 dynamic library from the
website and use it as a replacement for the one that the app they're
using ships. What you're suggesting: failing to maintain the behavior
already present - would violate this intention.

Now, on Windows I understand it to be a little more complex due to
versioning info inside the .dlls that the Windows dynamic library
loader apparently pays attention to, but that just means that you need
to be careful not to fiddle around with version numbers.

Personally, I would have preferred that all of the SDL2 functions and
datatypes have SDL2 stuck on the front instead of SDL, but not my
choice to make. For that matter, I probably would have written up the
actual SDL2 official functions to always use function pointers so that
static versions could have the ability to auto-load a dynamic library
if they detected one, but maybe in the future...



Quote:
Date: Sun, 10 Nov 2013 05:08:35 -0800 (PST)
From: Mason Wheeler
To: SDL Development List
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

*sigh* I'm sorry.? I don't mean to be abrasive.? It just always comes as a
bit of a shock to me when I say something that should be obvious and
people who really ought to understand it don't.? It gets in the way of
effective communication, and I don't always react well to that.? I'll
try to tone it down in the future.


I think that all of us understand, I've suggested deprecating a few
functions before (I forget which) so that we can hopefully finagle Sam
& Ryan into killing them off a few years down the road (or at least
remove them from the API headers), but there are limits to everything.
Regardless of what the fast-development world thinks of strict ABI
preservation, it is the requirement for something intended to be
publicly consumable to maintain ABI compatibility. What you're
suggesting would never be tolerated in the Microsoft COM world, nor
outside the boundaries of MSWindows, nor in any development
environment that dealt with industry, or experienced external software
development, or any of a number of other fields. What you're
suggesting is a fast-and-loose take on API guarantees that has no
place in code that intends to be externally consumed. It causes as
much trouble with static libraries and simple object files as with
dynamic libraries.

Use the hinting API, and maybe get Sam & Ryan to agree to deprecate it
in return for an easy to use extension library. It's the correct
choice. There is no other way that SDL2 can be allowed to go. The
presence of an API defect is enough to deprecate and eventually hide
an API in favor of another one without the defect, but it is not
sufficient reason to change the already described portions of the
behavior.



Quote:
Date: Sun, 10 Nov 2013 17:09:55 -0200
From: Sik the hedgehog
To: Mason Wheeler, SDL Development List

Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:
<CAEyBR+Vx38McCGr1dXm6=
Content-Type: text/plain; charset=UTF-8

2013/11/10, Mason Wheeler:

Quote:
Quote:
Scale says nothing about letterboxing either, and it doesn't even say
anything about size. All it says is that your drawing gets scaled. One
really important thing that it doesn't say is that the scaling isn't
actually applied by setting a logical size, but by adding an automagical
scaling constant under the hood, which means SDL's virtual resolution is
now
out of sync with raw API drawing commands and if you are trying to use
both
in the same program, it will screw up all your graphics. That one really
came as a shock to me, because I need both because I'm doing things that
SDL
has no APIs for!

Huh... I'm trying to understand what's the issue here. I could argue
SetLogicalSize makes the virtual resolution out of sync with the real
resolution which will bring problems as well. It's pretty much
expected with any sort of scaling.


The issue is that he expects the Render APIs to work seamlessly with
the underlying APIs, and in this case they don't. To those of us in
the C/C++ world this doesn't come as a surprise, because we're quite
aware that e.g. C's file API is nothing more than an opaque wrapper
around native primitives which might or might not not play nicely with
whatever else we want to do, but Mason programs in Delphi or something
similar, which by my understanding is used much less in the sorts of
bare-bones this-is-how-the-system-actually-works ways that C & C++ get
used. Not that I'm certain Bjarne necessarily likes that in the case
of C++ Smile .


Quote:
Quote:
Are you trolling me or something? What is this, the 1990s? Are you
installing the DLL to \windows\system32 and expecting to be able to leave
it
there and have everything magically work? Did you learn nothing from the
horrors that thousands of clueless Visual Basic developers unleashed upon
millions of computers worldwide by doing exactly that? We've known for
decades that that's exactly the wrong wayto deploy a DLL. Even if you
don't
bake SDL into your binary as a static library, you still drop the DLL in
the
same folder that you install the EXE to so that other programs can't
screw
it up. Are you seriously advocating deploying SDL the 1990s way? No
wonder
you're worried about this! o_0

Huh, have you ever deployed a program on Linux at all? On Linux it's
indeed that way, shared libraries are installed separately as their
own packages, and they're global to the entire system. The problem is
very much alive in the case of Linux.


I know that he programs in whatever the Windows origin of Lazarus is
(Delphi, I think, I know that he was talking about having written a
SDL2 binding for it), but I've never heard him mention Lazarus, so I'm
going to guess no. But then, neither have I, I just have enough of an
interest in low-level stuff like compilers & operating systems to know
that this sort of thing is an absolute no-go. Your average Windows
developer presumably doesn't poke into such hoary details all that
often.



Quote:
Date: Sun, 10 Nov 2013 13:03:24 -0800 (PST)
From: Mason Wheeler
To: Sik the hedgehog, SDL Development
List
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"



Quote:
On Sunday, November 10, 2013 11:09 AM, Sik the hedgehog
wrote:

Quote:
An ABI freeze implies an API freeze.

Neither of which implies a freeze on functionality or bug fixing.


An ABI freeze requires that low-level stack-and-memory interactions
with functions must continue to provide the same sets of results after
a change that they did before a change, unless the results of a
specific set of stack-and-memory interactions were Undefined Behavior
before the change. This means that the stated behavior must remain,
but new behaviors can be added. Any other definition fails the produce
any meaning that is relevant to an ABI freeze in a program or library.

Be glad that dynamic library systems on the major platforms aren't
more primitive, it's entirely possible that earlier forms didn't
support adding or moving functions. MSDOS ran into problems if
functions or data structures were moved.


Quote:
Quote:
That's the problem, it's not a bug, it's the decided intended behavior
for SDL 2.0, and as such it can't be changed without breaking any
program built against it.

Why do people keep bringing up things I've already explained?? Fixing this
bug won't break any released software, unless they update their software to
use an updated version of SDL2, in which case the new behavior will
certainly be caught in testing, and the software updated to match.? This is
a non-issue.


How do you not understand that SDL2 is designed for the user to update
the dynamic library? Besides, do you have some exhaustive list of all
software that will be released with SDL2? Steam uses it (though I
don't know that it depends on this), multiple programs pop up on the
new website, and there will never be a time when most of the programs
using it will tell the community. Unless you work for the NSA, you
don't KNOW who uses it.


Quote:
Quote:
Huh... I'm trying to understand what's the issue here. I could argue
SetLogicalSize makes the virtual resolution out of sync with the real
resolution which will bring problems as well. It's pretty much
expected with any sort of scaling.

I know I said I'd try to stop being inflammatory, but... are you being
deliberately obtuse here, or do you just not understand the implications of
the magical scaling constant inside of SDL?

OK, actual example.? Maybe this will make more sense:

Like most games, one of the things my game engine needs to be able to do is
draw text.? Part of the requirements is that the text gets drawn in colored
gradients defined by an image that gets shipped with the game.? This means
that the text-drawing routine needs to draw the shape of the letters, with
the colors taken from the image, and that requires multisampling.? (And the
actual requirements are a bit more complex still, requiring specialized
shaders, but going into too many details would confuse things.)

There is nothing in SDL, or any addon library, that can do that, therefore I
have to handle it in raw OpenGL.? The game runs at 320x240 resolution, in a
window 960x720 pixels in size. (3:1 in both dimensions.)? I set this up with
SDL_RenderSetLogicalSize.

In my original implementation of SDL_RenderSetLogicalSize, this was
implemented by using glViewport, so that the renderer only had 320x240
pixels worth of space to draw to.? All scaling was handled by the GL.

In the new, broken implementation, this is handed by keeping a viewport size
of 960x720 and setting a magical 3:1 scaling constant in the SDL renderer,
so that everything that gets drawn with an SDL call has all of its
coordinates multiplied by 3.0 to make it look like it's being drawn onto a
smaller viewport.

But then I try to render some text, and the Law of Leaky Abstractions rears
its ugly head.? If I try to render a letter at (20, 180), that's supposed to
be towards the top of the lower 1/3 of the screen.? But instead, it shows up
*tiny* in the upper-left corner, because I can't render this through SDL and
my OpenGL code doesn't know about the magical scaling constant being applied
internally by the SDL library.

I hope that makes sense, because I'm not sure I can explain any more clearly
than that why the current implementation of scaling is fundamentally
broken.


You explained very clearly why you shouldn't be using the Render API,
but not so much why you are using the Render API. Frankly, if you're
doing something that complex, you should probably be taking on all of
the OpenGL interactions yourself. The Render API is meant for simple
results, and that is not likely to ever change. The moment you get
into non-simple features, you should take it as in implication that
the Render API is just not for you, because the Render API is intended
for extremely little at all.


Quote:
Quote:
Quote:
Are you trolling me or something?? What is this, the 1990s?? Are you

Quote:
Quote:
installing the DLL to \windows\system32 and expecting to be able to leave
it
there and have everything magically work?? Did you learn nothing from
the
horrors that thousands of clueless Visual Basic developers unleashed
upon
millions of computers worldwide by doing exactly that?? We've known for
decades that that's exactly the wrong wayto deploy a DLL.? Even if you
don't
bake SDL into your binary as a static library, you still drop the DLL in
the
same folder that you install the EXE to so that other programs can't
screw
it up.? Are you seriously advocating deploying SDL the 1990s way?? No
wonder
you're worried about this! o_0>
Huh, have you ever deployed a program on Linux at all? On Linux it's
indeed that way, shared libraries are installed separately as their
own packages, and they're global to the entire system. The problem is
very much alive in the case of Linux.
*sigh*? You're *really* not making this "non-inflammatory* thing easy.? I
could make a very long and involved rant on the subject.? Instead, I will
courteously condense it down to a much shorter rant that covers only the
most relevant points.


No, that's entirely on your shoulders. He wasn't inflammatory,
insulting, or any other such thing. He pointed out something that is
reasonable and accurate, that being that the problems which CAUSED the
Windows dll hell are considered unacceptable on *nix systems in the
first place. For that matter, I can't think of how that kind of change
would be depicted as acceptable on commercial systems either, the only
reason I can think of to get away with it is to foist it off on
non-technical users who barely understand how a computer works in the
first place.

No, the inflammatory bit was entirely driven by your personal
perspective, and is not Sik's fault. Whether you agree with the *nix
stance is inconsequential, it is part of the terrain that SDL2
operates in, and operating in it is part of the reason why SDL exists
in the first place (in fact, SDL 1 started on *nix, not Windows). It
is relevant and must be taken into account.


Quote:
That right there is a perfect example of why desktop Linux never took off
and never will.? The *nix culture is not, as I intimated above, still stuck
in the 1990s; they're still stuck in the 1970s, refusing to acknowledge the
simple fact that, ever since the release of the original Apple Macintosh,
the art of computer system design has evolved and left them far behind.?
They may occasionally pay lip service to modern reality--and the ones that
do the best job of it (Ubuntu comes to mind immediately) are the ones that
have come the closest to actually gaining some semblance of mainstream
acceptance--but at its core are a bunch of philosophical principles that are
completely out of line with everything we've learned about building good,
solid systems since the year 1984!


Rule 1 of building solid systems) Don't change the documented behavior
of your dynamic libraries without changing the filename of your
dynamic libraries, because you will break things that users are
actually using.

The big problem that Linux has is a bad user experience, not a lack of
ABI change. Personally, I think that sticking to the *nix environment
in a distro is always going to be likely to prevent (or at least slow)
that distro from desktop adoption (Plan 9 is a better low-level
interface due to better uniformity, and someone really needs to start
again on the whole GUI thing, beginning with the functions required
for a program to dynamically adapt to high-dpi vs low-dpi + mouse vs
touchscreen vs etc. + small resolution vs high resolution...), but
breaking ABIs and APIs that you already have out in the wild will NOT
help.

Apple was dying a slow death until Steve Jobs came back and brought
proper management, and really great PR. The application should both be
pretty, and have the ability to easily be told to do the thinking
itself if you want to get into the desktop world, and the *nix
community hasn't caught on to that, which is why it hasn't caught on
in the consumer market. In comparison, the IT market, where the sort
of ABI changes that we're talking about are understood enough to be
dealt with, has whole-heartedly embraced Linux. Why? Because Linux is
dominated by a community of people who understand that you can't
justify just breaking things that you have already committed to public
consumption, which really makes a difference when you're running
things that need NOT to break.

An internal tool API for only you to use? Sure, stick it into a
dynamic library and break it as often as you want. But SDL 1 & 2 are
NOT such a tool. They are PUBLIC tools, and the behavior that YOU
desire is not the deciding factor.


Quote:
Quote:
What I realized is that Linux is not a
code base.? Or a distro.? Or a kernel.? It's an attitude.? And it's
not about Open Source.? It's about a bunch of people who still think
vi is a good config UI.


This is about a bad user experience. I consider vi (and vim, and
emacs...) trash because their default interfaces are precisely that:
trash designed for barely-interactive systems. We're talking about
not-even-a-command-prompt level here. If they were notepad + a command
prompt then they would be acceptable, but they're not.

And this doesn't really help you, because developers spend their time
dealing with text anyways, while the text-averse are going to have as
many problems caused by doing things your way as by not (and likely
more, which is why all of us are saying various versions of NO; we
wouldn't care if there wasn't likely to be a problem resulting from
your suggestion). Dynamic libraries are supposed to be sharable and
replaceable without replacing the entire program. You can justify them
without one of those, but your position requires justifying them
without either, which is impossible.


Quote:
Also, it's worth noting that, in the case of the only two *nix systems to
gain widespread adoption by end users--namely iOS and Android

Neither of these is a *nix system. Android usually uses a Linux
kernel, and iOS supposedly has an imitation of a BSD kernel, but
neither of them actually emulate a Unix system, whether Berkley,
System V, or any other. Which is why they're successful: they haven't
pissed off former users by breaking things, demonstrated a lack of
reliability by breaking things, or forced people into a poor user
experience (i.e. anything involving autotools) like the various *nix
distros.


Quote:
--this problem
does not exist.? In iOS, there are no dynamic libraries aside from the ones
provided by the OS, and in Android dynamic libraries are allowed, but
they're kept as part of the app bundle and not shared between programs.
</rant>

But anyway, that's getting way off-topic.? The point is, any well-designed
project (even for Linux) is going to manage its own dependencies.


And if those dependencies are publicly provided then any breaks in
them will result in turmoil for users. Go read the last month of two
of posts on the MSYS mailinglist and you'll see the sort of thing that
can happen when a project DOES manage it's own dependencies. They do
that, and still have had the sorts of problems that you're saying we
can avoid like this.

No, the problem with Windows .dlls lies entirely in the hands of those
who write the libraries, not in the hands of the applications that use
them. And even then, SDL's place lies in abstracting away the breaks
so that you can continue to use them. There is no room for your desire
in responsible library development. Even a static library needs to
follow it's specs. The only reliable way to prevent the "dll hell"
problem is to not break the ABI (for dynamic libraries) or API (for
static libraries and object files) in the first place.



At any rate, your arguments aren't going to sway any of us, because we
would prefer to write software that's robust enough to not keel over
and die from something as trivial as an update to a single dll. It's
almost like you didn't learn anything from the
dynamic-libraries-on-Windows experience.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Jared Maddox
Guest

Quote:
Date: Sun, 10 Nov 2013 20:33:00 -0600
From: Jared Maddox
To:
Subject: Re: [SDL] Stretched SDL Fullscreen (FULLSCREEN_DESKTOP)
Message-ID:
<CABXS6_npmn0gg7E5rc7yJ2mnCyU9CZjfc6JtRJmcAcw=
Content-Type: text/plain; charset=ISO-8859-1


Quote:
Quote:
Quote:
If you wanted it to behave differently, then you should
have stayed on the subject until ABI freeze.

I was working on another project at the time the ABI was frozen, or I
would
have noticed this sooner.


I half-recall discussions about the change sometime back around the
winter,

Summer, I meant summer, not winter.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org