Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
neoaggelos
|
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:
|
|||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Jonny D
|
HOW ABOUT THIS FOR UNEXPECTED BEHAVIOR?
GRRAAAHH!!! (╯°□°)╯︵ â”»â”â”» On Wed, Oct 23, 2013 at 2:19 PM, Sik the hedgehog wrote:
|
|||||||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Sik
|
I doubt that's the expected behavior...
2013/10/23,:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Jonny D
|
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:
|
|||||||||||||||||||
|
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
|
Hi all,
so is the solution to avoid using SDL_RenderSetLogicalSize() until this is fixed? Any proposed workarounds? cheers, rr
|
|||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Ryan C. Gordon
Guest
|
The letterboxing is not a bug, it's intentional behavior.
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:
|
|||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Pallav Nawani
|
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:
-- *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
|
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:
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
|
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
|
2013/11/9, Ryan C. Gordon:
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
|
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:
That's because that's what it was designed to do. |
|||||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
Sam Lantinga
|
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:
|
|||||||||||||||||
|
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
|
2013/11/10, Mason Wheeler:
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
|
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.
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.
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.
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
|
That's correct.
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.
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.
Sam and Ryan didn't design it. I did.
I was working on another project at the time the ABI was frozen, or I would have noticed this sooner.
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.
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.
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!
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!
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.
What I need is exactly what I implemented when I created the function. Otherwise, I'd have created it differently.
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.
*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
See above, re: Scale is fundamentally broken. Mason |
|||||||||||||||||||||||||||||||||||||||||||||
|
Stretched SDL Fullscreen (FULLSCREEN_DESKTOP) |
gabomdq
|
2013/11/9 Mason Wheeler
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
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
|
2013/11/10, Mason Wheeler:
An ABI freeze implies an API freeze.
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.
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.
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.
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.
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
|
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.
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.
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):
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
|
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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
"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.
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.
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.
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.
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...
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.
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++ .
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.
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.
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.
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.
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.
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.
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.
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.
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
|
Summer, I meant summer, not winter. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|