[SDL] SDL_Window suggestion
donny.viszneki at gmail.com
Thu Apr 30 16:59:47 PDT 2009
On Thu, Apr 30, 2009 at 7:27 PM, Gerry JJ <trick at icculus.org> wrote:
> Den Thu, 30 Apr 2009 04:25:19 -0400
> skrev Donny Viszneki <donny.viszneki at gmail.com>:
>> Yes, but the feature you're asking for will *not* display your games
>> "properly and undistorted."
> Well, someone's misunderstanding here, obviously. What feature do you
> think I'm asking for?
You're asking for non integer-scale picture resampling. There is
nothing "proper and undistorted" about that.
>> The proper solution is to get your operating system to deny these
>> video modes for that display.
> You're missing the point.
I didn't miss any point. I'm just being thorough. :\
Sorry for the confusion.
>> > Because of this, simply adding black bars isn't enough.
>> Actually, that would work, and is in fact a better suggestion.
> No, it wouldn't. Read my mail again.
>> Why not
>> an environment variable like SDL_FORCERESOLUTION which would force SDL
>> to ask for a certain resolution, and then letterbox the client
>> application's content as discussed above?
> You'd prefer having to mess with environment variables over a proper
> API? This also doesn't allow for scaling, unless you add environment
> variables for that.. ugh.
I'm a bit confounded by this entire reaction. What API are you
proposing? SDL_AskUserIfPictureLooksStretched()? Let's consider a few
Environment variables provide both an informal API (via the setenv()
API) *and* a way for users to set SDL options without the
application's intervention. That means those games you say we want to
be displayed a certain way on our feature-deficient displays will be
able to display properly even if it was written before this new API
you propose is created. But let's also take a look at the way SDL
already deals with changing SDL options which oughtn't require
I cannot think of even a *single* SDL application which has a dialog
asking me what video back-end (SDL_VIDEODRIVER environment variable)
or what audio back-end (SDL_AUDIODRIVER) I want to use. You might be
able to make the argument that without a functioning video back-end,
perhaps the application cannot ask the user *anything* and so there
needs to be an outside-the-application solution for setting this
option. But SDL_VIDEODRIVER is only one such option of several.
Why then would letterboxing and integer-scaling/resampling the picture
The most confounding thing is that if you really want a formal API for
doing this, it already exists! Just draw your picture to an
intermediate buffer! It's pretty painless, what more could you
possibly want? SDL_PleaseResampleVideoSurfaceForMe()?
On the other hand, if we want this option to provide a picture scaling
solution that is *backward compatible* with existing SDL/JEDI/Pygame
applications, the proposed environment variable route actually *works*
as opposed to adding a formal C API specifically for this feature.
Proposed environment variable route:
SDL_VIDEORESOLUTION = "WxH"
SDL_VIDEOSCALE = "WxH"
SDL_VIDEORESAMPLE = integer
The first option forces SDL to ask for a certain video mode and
letterbox as necessary. The second option forces SDL to provide the
programmer with an intermediate buffer when they would ordinarily get
the video surface, and then integer-scale and/or resample the picture
as necessary to fit the user's specifications. The third option would
specify a resampling algorithm as per SDL_TextureScaleMode:
* \enum SDL_TextureScaleMode
* \brief The texture scale mode used in SDL_RenderCopy()
SDL_TEXTURESCALEMODE_NONE = 0x00000000, /**< No scaling,
rectangles must match dimensions */
SDL_TEXTURESCALEMODE_FAST = 0x00000001, /**< Point sampling or
equivalent algorithm */
SDL_TEXTURESCALEMODE_SLOW = 0x00000002, /**< Linear filtering
or equivalent algorithm */
SDL_TEXTURESCALEMODE_BEST = 0x00000004 /**< Bicubic filtering
or equivalent algorithm */
More information about the SDL