Jump to content

Welcome to the upgraded PCGamingWiki forums and files page. The current Wiki and Forum bridge is not functioning at the moment, therefore your Forum account currently has no password set. Please reset your Forum password via email check to generate a new password. If you have any issues please message Andytizer on Discord.

Expack3

Overhaul of the editing guide?

Recommended Posts

A long conversation between multiple PCGW staff members and PCGW community members on the official PCGW Discord brought up a good suggestion: overhaul the editing guide. I've taken the liberty of putting the chat log below, as it introduces the topic much more effectively than I ever could.

SirYuiJediYesterday at 7:31 PM
Actually, this game is 16:10 pillarboxed on a 16:9 display
that makes me think perhaps "limited" could be used for widescreen
SirYuiJediYesterday at 7:31 PM
Interesting idea. There's a couple other like that that I can edit if we follow that line of thought.
BaronSmokiYesterday at 7:32 PM
I guess the most important thing is mentioning the behavior in the notes
regardless of what the value is
SirYuiJediYesterday at 8:12 PM
Of course.
mastanYesterday at 8:18 PM
if it fills the whole screen area, then its good to go, even if it is vert-

Guide mentions that stretched(which fills the whole screen) is false for widescreen.
RoseYesterday at 8:43 PM
they probably meant vert- by that whole sentence though
mastanYesterday at 8:58 PM
Doubt that. Vert- does not distort picture. And if fov setting is available, vert- can be compensated.
If vert- does not break game then it's true for widescreen imo. But if it does and there's no other proper widescreen setting, then false.
Like in Broken Sword 5 for ultrawidescreen. Game offers next choices:
- Windowed
- Stretched 
- Vert- (breaks the game)
- Pillarboxed HD/FullHD
So I've put false to ultrawidescreen since no option allows to use full screen without stretching or breaking game.
GarrettYesterday at 9:06 PM
@BaronSmoki the ultrawide pillarbox grade handling seems to be a bug on WSGF's end (setting any of the other WSGF screen types to pillarbox gives an "unsupported" grade)
CptmoldYesterday at 9:09 PM
I think a Limited would be best.  For example Grim Fandango's widescreen support adds additional artwork to the sides to fit 16:9.
As long as notes can explain though anything should be fine.
RoseYesterday at 9:17 PM
I believe limited adds it to the list of games with uw support but it shouldn't be there
@mastan I was talking about the quote, not the wiki
mastanYesterday at 9:19 PM
Not sure about that. Word "even" suggests there is something besides vert-.
RoseYesterday at 9:21 PM
in any case, pillarboxing just means you resort to widescreen, zero benefits to a UW user. we have a row for widescreen. there's no need to claim pillarboxing is limited support
GarrettYesterday at 9:22 PM
yes, limited would be for things where it is truly supported, but has some noteworthy limitation
SirYuiJediYesterday at 9:36 PM
Yeah, because, for example, Vert- in a game with adjustable horiz FOV like… pretty much any 90s FPS, has no reason to be marked limited, because you can just change the FOV.

I really wish WSGF would stop labeling every game with adjustable FOV as hor+, though.
BaronSmokiYesterday at 9:37 PM
@Garrett, would you consider 16:10 pillarboxed on a 16:9 display to be "limited" enough for wide screen?
SirYuiJediYesterday at 9:38 PM
please say yes, please say yes
CptmoldYesterday at 9:47 PM
I think Limited would be good in Widescreen for any case where it's one or the other.  for example, I'd use Limited for Metal Gear Rising because it will stretch 16:9 no matter what resolution you pick, even 16:10 ones.  It distorts the image.
BaronSmokiYesterday at 9:49 PM
If it forces a stretch, that sucks. As a 16:10 gamer, I've gotten used to  letterboxing and it doesn't bother me.
SirYuiJediYesterday at 9:51 PM
I was never able to get 2.35:1 (or 1.33:1, 1.60:1, etc) resolutions to work in FFXV demo. It would always stretch it out to my desktop resolution (even though I set GPU scaling to maintain aspect ratio).
GarrettYesterday at 9:58 PM
some games get the aspect ratio from the current desktop resolution (not what you set for the game itself), so in those cases you'd need to change the desktop resolution as well
SirYuiJediYesterday at 10:00 PM
Which is obnoxious.
GarrettYesterday at 10:13 PM
also, GPU scaling only works for non-native resolutions; if the game is doing its own handling within the native resolution it won't have any effect
AemonyToday at 6:48 AM
Are you all saying that the parameters needs a thorough rethinking of how they’re applied? Noo, tell me it isn’t so! /s
As of right now, the widescreen etc parameters per the editing guide and abbreviations (mouse hover text) mostly only concerns itself with wether the game can output to a given type of resolution, and less with /how/ the actual support is handled
mastanToday at 7:26 AM
As of right now, the widescreen etc parameters per the editing guide and abbreviations (mouse hover text) mostly only concerns itself with wether the game can output to a given type of resolution, and less with /how/ the actual support is handled

So, ultrawidescreen should be true for this then? https://pcgamingwiki.com/wiki/File:Kaptain_Brawe_A_Brawe_New_World_21-9_stretched.png
PCGamingWiki
File:Kaptain Brawe A Brawe New World 21-9 stretched.png
PCGamingWiki - fixing PC games, one title at a time.
And wooden boards instead of black bars of pillarboxing https://pcgamingwiki.com/wiki/File:Kaptain_Brawe_A_Brawe_New_World_21-9_pillarboxed.png
PCGamingWiki
File:Kaptain Brawe A Brawe New World 21-9 pillarboxed.png
PCGamingWiki - fixing PC games, one title at a time.
AemonyToday at 8:17 AM
Hence why it needs a slight clarification/rework on all parameters
https://images.aemony.se/sharex/firefox_2019-05-12_14-17-04.png

Proper definition on what constitutes the various degrees of support is needed in the editing guide, with a better abbreviation text on the actual parameter
E.g.
True ==  Exposes ultra-widescreen resolutions and uses Hor+ (extending the visible area of the game in comparison to the reference view of the game).
Limited == Exposes ultra-widescreen resolutions, but with some sort of issue such as pillarboxed or stretched display or HUD elements, or Vert- (cropping the visible area of the game in comparison to the reference view of the game).
Hackable == Support can be improved why using hack/tweak of some sorts.
False == Does not expose ultra-widescreen resolutions through the settings of the game.
supports is a lose term that means different things for different people
Expack3Today at 8:37 AM
@Aemony I've never seen supports in this context mean anything other than "The game allows use of [x]". The degree of use determined by the game's implementation, which the guide - in the very example you provided - already goes into.
AemonyToday at 8:38 AM
Please define allows use of [x]
Because NieR:Automata allows the use of 21:9 resolutions without hacking ^^
Expack3Today at 8:39 AM
*allows use of [insert feature here]
AemonyToday at 8:39 AM
https://images.aemony.se/sharex/firefox_2019-05-12_14-39-23.png

Take that for example
It doesn't specify anything other than "Support does not count if the resolution is stretched."
So a 4:3 game that is pillarboxed on 16:9 resolutions is true, since it allows the use of 16:9 resolutions, arguably
Expack3Today at 8:41 AM
No, in that case it's Limited as which it technically supports 16:9, the full resolution is not used.
AemonyToday at 8:41 AM
Limited didn't exist when the parameters was created and the Editing Guide was written
Hence why I am for a rewrite with more in-depth details of each "level of support"
Expack3Today at 8:42 AM
That part I can agree on.
AemonyToday at 8:42 AM
Otherwise we're going to argue back and forth without having a clear definition to go by, because right now the reasoning I mentioned is as equal to yours since neither is actually covered by the Editing Guide
Anyway, it's something that requires a bit more work than your typical editing, hence why it haven't been made yet.
There's issues with most of the parameters that we might as well try and clear up whenever the ball starts to roll ^^
Expack3Today at 8:44 AM
This sounds like something which should be posted to the forums.
That way, all this won't get lost under the deluge of whatever else needs to be discussed on this channel.
AemonyToday at 8:45 AM
Definitely
It requires a discussion to be had around it to ensure that whatever end result ends up being good

 

Share this post


Link to post
Share on other sites

Overhauling the editing guide sounds too encompassing 🙂

What I think is needed is that we simply go into more detail about the various parameters that allows true/limited/hackable/false values, with the focus being on Video and Input sections primarily, with the Audio section secondarily.

 

A few example discussion points:

  • 4K parameter seems heavily tied to 16:9 at the moment. Should preferably not be tied to any particular aspect ratio and more in general deal with whether a game can run at the 4K resolution of whatever aspect ratio the game is designed for (3840x2160 for 16:9-designed games, 3840x2400 for 16:10-designed games, 3840x2880 for 4:3-designed games).

 

  • Repurpose multi-monitor parameter somehow, since right now it tends to mean "wider aspect ratio than ultra-widescreen".
    • The "main element" of multi-monitor gaming today is AMD Eyefinity and Nvidia Surround, which isn't really relevant to the game itself, as all of that logic is separate from the game.
    • Possibly repurpose to real multi-monitor support? As in games that allows the use of a secondary monitor for minimaps, view etc? Real native multi-monitor support, that is, without involving AMD Eyefinity or Nvidia Surround?

 

  • Generally make it clearer whether a parameter means that a game have an option for toggling something vs. supports something. Right now the difference isn't always clear, which can cause new editors to interpret some parameters incorrect (e.g. should "mouse acceleration" be set to true or false if mouse acceleration is used, but no option is available to adjust it?)

 

  • New parameter(s) in Audio settings detailing spatial audio support and possible tech required to enable it.
    • Either replacing the existing EAX support field, or supplementing it somehow.

 

The above is just a few examples that can be discussed. Past that, we should add abbreviations (hover explanations) to all of the parameters in the tables with a short and concise description of what the parameter tracks to make it easier editing without having to visit the Editing Guide. Some parameters already have this, and it simply needs to be extended to the rest after the discussions about what the parameters should actually mean have finalized.

Share this post


Link to post
Share on other sites

Gamer Alex on Discord suggested having a separate setting state for features that exist but can't be toggled. I have made an example below of what an "always on" option might look like.

Such a state would only be available for settings where an "always on" state can exist.

on-off.png.818f4ec82603f6a600f75c40b5898867.png

9 hours ago, Aemony said:
  • Repurpose multi-monitor parameter somehow, since right now it tends to mean "wider aspect ratio than ultra-widescreen".
    • The "main element" of multi-monitor gaming today is AMD Eyefinity and Nvidia Surround, which isn't really relevant to the game itself, as all of that logic is separate from the game.
    • Possibly repurpose to real multi-monitor support? As in games that allows the use of a secondary monitor for minimaps, view etc? Real native multi-monitor support, that is, without involving AMD Eyefinity or Nvidia Surround?

I would have to disagree with this. Multi-monitor methods combine multiple physical displays into a single virtual display, so behavior beyond that is entirely handled by the game itself (just like ultra-widescreen) apart from a few games using the AMD/Nvidia APIs to determine HUD positioning.

Share this post


Link to post
Share on other sites
31 minutes ago, Garrett said:

Gamer Alex on Discord suggested having a separate setting state for features that exist but can't be toggled. I have made an example below of what an "always on" option might look like.

Such a state would only be available for settings where an "always on" state can exist.

on-off.png.818f4ec82603f6a600f75c40b5898867.png

I would have to disagree with this. Multi-monitor methods combine multiple physical displays into a single virtual display, so behavior beyond that is entirely handled by the game itself (just like ultra-widescreen) apart from a few games using the AMD/Nvidia APIs to determine HUD positioning.

The fact that the methods does the heavy lifting and sets up a virtual display is the reason why its current use is wasted.

The parameter is basically relegated right now to a “wider-than-ultra-widescreen” field, a ”hyper-widescreen”. I believe we looked it up a few weeks ago and found that in most instances that the parameter mirrors the ultra-widescreen parameter, since it’s effectively just a subparameter of that.

Meanwhile we’re losing out on tracking actual games with native multi-monitor support, since those are basically combined with every other title that can “spoof support” through Eyefinity or Surround.

 

I love the idea with a lock though, although it introduces the question of what warrants a green or red lock.

Share this post


Link to post
Share on other sites
3 hours ago, Aemony said:

I love the idea with a lock though, although it introduces the question of what warrants a green or red lock.

I have made an example update of the Section Table legend with reworked definitions. There is no "always off" in this example (features that can't be configured at all would be set to false as usual).

Currently, true has sometimes been used to mean "this is active natively" (e.g. forced Vsync); with a reworking such as this, true/limited would always mean "this can be configured natively" while the proposed "always on" state would be used for any features that are active but cannot be configured.

This would require rethinking the implementation or presentation of a couple of settings for consistency, e.g. frame rate (@Mirh has previously suggested FPS support should be redesigned).

Share this post


Link to post
Share on other sites

@Garrett I can't help but think @Aemony was also referring to multi-monitor games such as Supreme Commander, where a secondary monitor can be independently used (e.g. no Eyefinity/Surround needed) as a full-size viewport. I'd add, as a much more obscure example, MechWarrior 2, whereby users who had both a supported color video card and a Hercules Graphics Array (HGA) discovered that while the monitor hooked up to their color video card showed things as normal, the monitor attached to the HGA would show developer debugging information.

I know the latter example is barely related to multi-monitor support, but I feel it's the purest example of "multi-monitor as independent monitors" rather than the Nvidia/AMD "multi-monitor as wider-than-widescreen". As of right now, the multi-monitor setting covers both, which can potentially cause confusion since "multi-monitor as wider-than-widescreen" is so common.

Share this post


Link to post
Share on other sites
On 5/13/2019 at 12:25 PM, Garrett said:

I have made an example update of the Section Table legend with reworked definitions. There is no "always off" in this example (features that can't be configured at all would be set to false as usual). 

Currently, true has sometimes been used to mean "this is active natively" (e.g. forced Vsync); with a reworking such as this, true/limited would always mean "this can be configured natively" while the proposed "always on" state would be used for any features that are active but cannot be configured.

This would require rethinking the implementation or presentation of a couple of settings for consistency, e.g. frame rate (@Mirh has previously suggested FPS support should be redesigned).

If so, the icon for the "always on" locked state should probably be changed to blue, to be more neutral.

In the eye of the beholder, and all that.

Having it "green" suggests that whatever it is that's locked "always on" is positive, which typically isn't the case, such as with these:

- Mouse acceleration/smoothing being locked to always on.

- Anti-aliasing being locked to always on.

- Subtitles/Closed captions being locked to always on.

etc.

Hmm... "features that can't be configured at all would be set to false as usual" vs."while the proposed "always on" state would be used for any features that are active but cannot be configured."

 

On 5/13/2019 at 1:40 PM, Expack3 said:

@Garrett I can't help but think @Aemony was also referring to multi-monitor games such as Supreme Commander, where a secondary monitor can be independently used (e.g. no Eyefinity/Surround needed) as a full-size viewport. I'd add, as a much more obscure example, MechWarrior 2, whereby users who had both a supported color video card and a Hercules Graphics Array (HGA) discovered that while the monitor hooked up to their color video card showed things as normal, the monitor attached to the HGA would show developer debugging information.

I know the latter example is barely related to multi-monitor support, but I feel it's the purest example of "multi-monitor as independent monitors" rather than the Nvidia/AMD "multi-monitor as wider-than-widescreen". As of right now, the multi-monitor setting covers both, which can potentially cause confusion since "multi-monitor as wider-than-widescreen" is so common.

This is correct, and was what I was going for. There's not a lot of games with native multi-monitor support, but they exist and typically allows the use of the secondary monitors in some special way. For example some of the Battlefield games allows the use of a second monitor to show the minimap of the game, and some racing games have allows for native extended view across multiple monitors without involving AMD/Nvidia specific features.

The current multi-monitor parameter could almost entirely be worked into the existing ultra-widescreen parameter with the minor difference (if one exists) noted in the Notes field.

In my opinion, the multi-monitor parameter should be an highly obscured parameter, hidden by default, that properly categorizes games that allows the use of one or more secondary monitors for unique features independent of GPU features. Not be used as an "additional-ultra-widescreen" parameter.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Forum Statistics

    967
    Total Topics
    6166
    Total Posts
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Who's Online   0 Members, 0 Anonymous, 73 Guests (See full list)

    There are no registered users currently online

×