安装 Steam
登录
|
语言
繁體中文（繁体中文）
日本語（日语）
한국어（韩语）
ไทย（泰语）
български（保加利亚语）
Čeština（捷克语）
Dansk（丹麦语）
Deutsch（德语）
English（英语）
Español-España（西班牙语 - 西班牙）
Español - Latinoamérica（西班牙语 - 拉丁美洲）
Ελληνικά（希腊语）
Français（法语）
Italiano（意大利语）
Bahasa Indonesia（印度尼西亚语）
Magyar（匈牙利语）
Nederlands（荷兰语）
Norsk（挪威语）
Polski（波兰语）
Português（葡萄牙语 - 葡萄牙）
Português-Brasil（葡萄牙语 - 巴西）
Română（罗马尼亚语）
Русский（俄语）
Suomi（芬兰语）
Svenska（瑞典语）
Türkçe（土耳其语）
Tiếng Việt（越南语）
Українська（乌克兰语）
报告翻译问题
讨论规则及指引
举报此帖
Examples:
https://www.techpowerup.com/img/kLGzbamqwTe0uFMb.jpg
http://tanalin.com/images/articles/lossless-scaling/en/interpolation-bilinear-2x.png
- Configurable pixel size (best for future proofing), as e.g. 6x pixel size is applicable for 4K displays, and higher multipliers are better for future high-res monitors.
- A new display type called "Match canvas", or reconfigure "Original" display type to actually respect the selected pixel size.
Why "original" display type results in a 568x320 canvas when a higher pixel size than 1x is selected is something I do not understand. There's no benefit from using 2-4x pixel size with Original, as the resulting canvas size will only be 568x320. It's basically upscaling a pixel-based game at 4 times the original resolution followed by downsampling it to the original res again... You're not really going to get any improvement at all...
The building blocks are all there already, they just need a tiny retweaking.
It's basically a hack at the moment as I couldn't be bothered figuring out the other relevant places I would have to modify to change the value that pixel size == 4 sets, but it works for me.
Two key changes, both in game.compiled.js:
game.compiled.js:
The above is by default a = c; b = d. c is set to IG_WIDTH which happens to be 568, and d is set to IG_HEIGHT, which happens to be set to 320. The addition here is " * window.IG_GAME_SCALE ", aka we're telling it to multiply the original resolution with the selected game_scale (aka pixel size).
A bit further up is where the hacky nature of this change comes in:
I didn't really care enough to try and figure out where game_scale is set to 4 by the pixel size option, so I simply opted to overwrite the previous IF statements that were there and always set it to 6 since I have a 4K monitor.
In general this works fine, but with some minor issues:
- Remnants of the Steam overlay will be shown at the edges of the canvas size (goes away on alt+tab): https://images.aemony.se/sharex/CrossCode_2019-06-27_16-12-25.png
- This isn't DPI aware, so if the DPI in Windows is set above 100% the canvas size will stretch beyond the window size. Workaround, I guess, is to change DPI scaling for CrossCode.
Edit:
To fix/prevent DPI scaling on 4K displays when Windows is set to a higher DPI than 100%, using the "/force-device-scale-factor=1" command-line arguments might do the trick: https://images.aemony.se/sharex/CrossCode_2019-06-27_16-49-49.png
While still not exactly where I'd say a perfect implementation would be (safety checks in window mode + launch would have to be added), it's basically feature complete.
Changes:
assets\js\game.compiled.js
Added integer display type as an option:sc.DISPLAY_TYPE = {
ORIGINAL: 0,
SCALE_X2: 1,
FIT: 2,
STRETCH: 3,
INTEGER: 4
};
Added 5 and 6 as pixel size options.- Note this whole approach is not future-proof, and preferably the number of pixel sizes available should be determined by dividing the monitorWidth / 568 and monitorHeight / 320 and then select the lowest value of the two (scrapping the decimal in the process).
sc.PIXEL_SIZE = {
ONE: 0,
TWO: 1,
THREE: 2,
FOUR: 3,
FIVE: 4,
SIX: 5 };
Added a call to _setDisplaySize() (needed to properly apply the integer ratio on launch).} else if (b == "pixel-size") {
window.IG_GAME_SCALE = (this.values[b] || 0) + 1;
localStorage.setItem("options.scale", window.IG_GAME_SCALE);
this._setDisplaySize();
}
Added new case for handling integer base scaling:case sc.DISPLAY_TYPE.INTEGER:
a = c * window.IG_GAME_SCALE;
b = d * window.IG_GAME_SCALE;
break;
assets\data\lang\sc\gui.en_US.json
Added "integer" to the localization:"display-type": {
"name": "Display Type",
"group": ["Original", "Double", "Fit", "Stretch", "Integer"],
"description": "Changes the Scaling used for the box the game runs in."
},
Added 5 and 6 as options to the localization"pixel-size": {
"name": "Pixel Size",
"group": ["1", "2", "3", "4", "5", "6"],
"description": "Higher size means sharper image. May reduce FPS. \\c[1]Needs a restart!"
},
Edit: Tidied the formattting up a bit.
This will automatically fall back on the highest integer multiplier possible if the selected pixel size extends beyond the range of the window. This takes care of the DPI issue even if "/force-device-scale-factor=1" isn't being used (although the DPI scaling may introduce blur, possibly!) as well as situations where e.g. the player might find themselves with a lower resolution than the game was originally configured for.
The below clip is slightly longer than the last one, but goes through how this code handles both DPI scaling being applied as well as without DPI scaling.
https://www.youtube.com/watch?v=O2uYA4rJtKI
I took a look at the demo and sadly these changes won't do anything for you as the demo is heavily outdated (the manifest is from August 11, 2016 – 19:02:53 UTC) and not as open for modifications as the full game.
I'd recommend you purchase the game and try the tweaks out. I have a finished script that applies the necessary tweaks in a couple of seconds here: https://github.com/Idearum/CrossCode-IntegerScaling You just need to run it once.
Although be aware that since these tweaks adds new settings values not originally in the game, the saves of the game will be dependent on those until the game is configured to not use them. This means that before removing the mod, it is necessary to enter the display settings and configure the settings back to Original/Double/Fill/Stretch and 1-4x pixel size, as otherwise you won't be able to enter the display settings screen when the mod have been removed without the game crashing due to the missing option values.
I am cautiously optimistic that my patcher will continue to work for future game versions as well if we don't see official support, as it is quite basic in what it searches for and replaces, although official support is obviously the preferred solution
Edit: The video settings menu can be made inaccessible after the mod have been removed if the save file still refer to the custom video options. Open the general settings menu and click the B key or Reset all settings to restore the original video settings to be able to access the video settings menu again.
Been trying it out and would be great to see dev support for this. Works really well and is a necessity. Can't wait to play through the game when i have time, just purchased it earlier :D
Nvidia's integer scaling isn't really an option per se as this game does not run in an exclusive fullscreen mode (as it's basically a fullscreen Chrome window). To use Nvidia's integer scaling in conjunction with CrossCode you would have to do add a custom resolution in Nvidia's control panel that matches one of CrossCode's original resolution multiplied by some factor, then configure Windows to use that resolution for the desktop, and finally launch CrossCode.
Suffice to say, it's a hassle to utilize with CrossCode, and even a workaround (such as using the Lossless Scaling tool) would be easier to accomplish.
Which means that the scaling is, as with their current GPU-driven scaling modes, applied _after_ the full "desktop image" (which includes the game and other parts of the Windows desktop) has been finalized and sent down to the hardware level from the software level.
So you basically have a level like this:
This is a bit more complicated, as you basically have three different types of games involved:
Some games use the first form of HDR. Others the second. A few SDR games are mistakenly assumed to be HDR due to the third bullet.
The only way to differentiate between the two last bullets is by changing the "SDR content appearance" slider ( https://images.aemony.se/sharex/ApplicationFrameHost_2019-08-21_16-54-44.png ) while the desktop is running in HDR mode and the game in question is displayed on the desktop. That slider controls how bright or dark SDR content is translated into when displayed in HDR mode.
* _If_ the brightness of the game changes along with the slider, then it's only using SDR colors, and Windows' SDR-to-HDR tonemapping is what changes the colors as part of the HDR mode the desktop is running at.
* If the brightness _doesn't_ change along with the slider, then the game outputs native HDR colors which Windows leaves untouched.
This is even true for media players like VideoLAN VLC, which can display HDR content while their own window borders and controls are displayed in SDR. Changing the "SDR content appearance" slider while playing a HDR clip in VLC while the desktop is running in HDR mode will see the window borders and controls change brightness, while the HDR media itself is left completely untouched, as that's already being displayed in HDR and so doesn't need to be translated from SDR.
Before Windows 10 v1803, this sort of SDR-to-HDR tonemapping didn't exist in Windows, and so whenever you enabled HDR mode on the desktop you'd end up with basically _everything_ being extremely dark and "diminished", looking "greyed out" or similarly "washed out", except native HDR content. Microsoft added the SDR-to-HDR tonemapping to Windows in v1803 to make regular SDR content usable while the desktop was running in HDR mode.
Oooo, that's interesting, and might allow the use of Nvidia's integer scaling as long as the game itself used an output resolution that actually matched its internal render resolution.
Although the hindrance would be that DXGI, to my knowledge, only allows output resolutions that matches what the monitor reports it supports, so it's possible outputting to such a resolution wouldn't be allowed until the user added it as a custom resolution through Nvidia's control panel.
Just run it through whatever beautifier tool online, such as https://beautifier.io/, and that will structure it nicely.
After having implemented the changes and confirmed they work with the "beautified" file, I transpose them back into the original file by finding the relevant section to edit and add the custom code without line breaks and the like.
You're welcome.
That tool is basically just one out of many online tools that basically does the same, such as JavaScript Beautifier[javascriptbeautifier.com] or JSBeautifier[jsonformatter.org], etc. These sorts of tools exists for basically all forms of HTML, CSS, or JavaScript (and possibly other languages as well).
What's typical with game.compiled.js is that the developers have basically run it through what's called a "minifier" (JavaScript Minifier[javascript-minifier.com], Minify[www.minifier.org]) which takes the original JavaScript code and removes all extraneous data such as tab, space and line break characters and the like. The reason this is done is to "minimize" and essentially "compress" the size of the file as much as possible so that it is quicker downloaded when used as a resource on websites.
Hence why "beautifiers" (also sometimes known as "formatters") which sorta does the opposite (properly structures code to make them more human-readable and easier to modify) becomes relevant as they can undo the compressed text and restore it to a more easily understood file.
Neither have any actual effect when playing CrossCode on a computer though, so it doesn't matter if the file is "compressed" or not, as the code will execute identically regardless. I prefer to make my patches compatible with the original files though as that ensures the highest compatibility with future version of the game.