Dynamically setting display size

Ok. So, I need to adjust windowed display size based on user screen res.

I can easily pull user desktop res with the windows API, but I have tried multiple ways to change Orx display size to no avail.

I was able to change display size by modifying a display_video_mode object manually, but this lead to all manner of problems with the viewport and frustum either distorting or just leaving a huge amount of black space with a tiny viewport.

The problem with using the push/pop method seems to be that the display section of the config is processed before any code can be called. Or, at least before code can be called by Orx to modify its config keys.

My question is quite simple: Can code be called IN the config file to act on a key, or can code modify the display size keys BEFORE the display is created?

Thanks in advance,
-Wolf

Comments

  • Hey @WolftrooperNo86, to answer your question yes, but that's probably not what you need at the moment. :)

    Lemme give you more details. First, regarding code execution "in the config". You can execute commands from config, and there are two ways to do so:

    • during config load, as a global command
    • lazily as part of the retrieval of a property's value

    Here's the quick summary that can be found at the top of CreationTemplate.ini/SettingsTemplate.ini

    ; Commands can be used in order to get more dynamic contents, they'll be prefixed by `%`.
    ; A sequence of multiple commands can be expressed by separating them with `,`.
    ; There are two ways to define embedded commands:
    ; - Commands evaluated at load time, not tied to any specific property. These will be evaluated once, when the file is loaded. Example:
    ;   % > Get OtherSection BaseValue, + < 1, Set NewSection ValuePlusOne <
    ; - Commands that are lazily evaluated every time the value of a property is retrieved. Example:
    ;   Key = % MyOwnCommand 42
    ; In this second case, when more than a single command is defined, the property's value will be the result returned by the last one.
    ; Example:
    ; MyOtherKey = % log "Fetching dynamic content of MyOtherKey", * 21 2; Fetching MyOtherKey will return 42
    ; Lazy commands can also be embedded inside lists.
    ; Example:
    ; Key = 1 # % + 2 3 # 10; Fetching Key will return either 1, 5 or 10
    

    That being said, if your goal is only to use the desktop resolution, simply remove the ScreenWidth/ScreenHeight properties of the Display section, and the native desktop resolution will be used. Note that if you want to go for the infamous borderless fullscreen, I'd recommend setting Decoration = false in the same section as well.

    Now if you want to do it later on during runtime, for example for switching after the user has changed his settings, you can retrieve the current desktop resolution easily by passing orxU32_UNDEFINED to orxDisplay_GetVideoMode().

    Here's the relevant inlined documentation:

    /** Gets an available video mode
     * @param[in]   _u32Index                             Video mode index, pass _u32Index < orxDisplay_GetVideoModeCount() for an available listed mode, orxU32_UNDEFINED for the the default (desktop) mode and any other value for current mode
     * @param[out]  _pstVideoMode                         Storage for the video mode
     * @return orxDISPLAY_VIDEO_MODE / orxNULL if invalid
     */
    extern orxDLLAPI orxDISPLAY_VIDEO_MODE *orxFASTCALL   orxDisplay_GetVideoMode(orxU32 _u32Index, orxDISPLAY_VIDEO_MODE *_pstVideoMode);
    
  • Also note that you shouldn't get any viewport deformation, no matter what video mode you set. Orx should maintain the aspect ratio and use pillar/letter boxing depending on the requested resolution.
    If you have a test sample for me to try, I'd be happy to have a look at this issue.

  • Ah. Yes. I think it was because I was modifying display, viewport, and camera separately. I was probably taking over control manually, thus not allowing Orx to adjust some internal values. Once I only changed display size, Orx did the rest!

    I’ll test your example over the next couple days.
  • Ah I see. Let us know how it goes then. :)

  • BTW, what did you mean by "infamous borderless fullscreen?" Is fullscreen frowned upon or disliked, or is there something buggy about how fullscreen works? Basically, is it something to be avoided?

  • I mean it is a bit of a misnomer: it's not actually fullscreen, it remains a window albeit without any decoration and that covers the whole surface of your desktop.

    That means it can't run at a different refresh rate than your desktop, for example, and usually will yield inferior performance than an actual fullscreen mode.

    To sum it up:

    ; Real fullscreen at the desktop resolution
    [Display]
    FullScreen = true
    
    ; Borderless fullscreen
    [Display]
    Fullscreen = false
    Decoration = false
    
Sign In or Register to comment.