Fate/Stay Night [Realta Nua] - Ultimate Edition (thread discontinued, see OP for new thread)

[NM64]

But we can always add super high quality option for 1200p

If we did something like that, then personally I'd prefer to do something like the following:

• Low @ 600p
• Medium @ 960p
• High @ 1200p
• Ultra @ the highest resolution we can confirm that works, whether it be 2160p, 2880p, 4320p, or whatever (this is meant to be a sort of "future-proofing" option)

Alternatively we could either ditch the 1200p setting altogether and just have "Low' @ 600p, "Medium" @ 960p, "High" @ 2160+p, or ditch the 960p setting and have "Low' @ 600p, "Medium" @ 1200p, "High" @ 2160+p

Though for the sake of using such an "2160+p" setting in windowed mode, it would probably be wise to also include window sizes that are smaller than 0.80x (because even 2160p with 0.80x scaling is still going to be 1728p which is too big for not only a 1440p display but even a 1600p one).



...however, if I'm being honest, wouldn't it just be easier to always render at a particularly ultra high resolution (like 2160p) and then just use the window sizing to get all of the smaller sizes necessary? This would largely eliminate the issue of text not being rendered at your screen's native resolution (with the only exceptions being for resolutions that are so absurdly high that the quality difference is likely to be quite minimal anyway) and would greatly simplify bug testing since we already know that the window size function works without issue (well, at least until the OP videos come into play...)

I mean, in that case we could even simplify it back down to two quality settings - "low" for the original 800x600 mode and art assets (which would additionally not even really need the "window size" function and could be always locked to 800x600 and just grey out the window size settings) and a "high" quality mode that renders at like 2160p and is used in conjunction with the window size setting to achieve the desired size, in which case the labels could be returned to using actual resolution sizes rather than relative scaling values (or heck the text labels could have both, like "50% - 1080p"), and because most of the settings in this situation would be less than 1.0x it would make more sense to use percentages instead.

Now normally I could understand if performance may be a concern when rendering at ultra high resolutions, but the krkrz engine isn't exactly all that demanding in the first place...

[Jacktheinfinite101]

Now normally I could understand if performance may be a concern when rendering at ultra high resolutions, but the krkrz engine isn't exactly all that demanding in the first place...

Well skipping has already been slowed down.

[NM64]

Well skipping has already been slowed down.

I tried benchmarking how long it takes to complete the prologue while holding Ctrl, but I'm unable to test how much of the impact is due to rendering at a higher resolution or is due to using WebP and the according plugin.

On my Pentium G3258 @ 4.5GHz (with Intel HD2500 integrated graphics mind you), "Low" quality took ~57 seconds while "High" quality took ~93 seconds. Again, no idea if that's due to the higher resolution or due to the use of WebP or if it's some combination of the two.

My idea is that if the bottleneck is mainly to the use of WebP and/or the according plugin, then rendering at even a much higher resolution may very well have minimal performance impact.

[castor212]

would it be correct to assume that
there's gonna be an updated version

apologize for double asking
is there gonna be a release of newer ver of the patch?

[Mizuti]

So, how about that touch screen input?

If that isn't a priority right now: do you have a repository somewhere so I could have a go at it myself? I am a programmer.

[TheUnknownIdentity]

So, how about that touch screen input?

If that isn't a priority right now: do you have a repository somewhere so I could have a go at it myself? I am a programmer.

Try running Fate.exe from the command line and specifying the option --ignoretouch=false and see if that helps. I'm not entirely sure if it is false or true by default as the line is as follows:
" "caption":"タッチイベントの無効化", "description":"タッチイベントを無効化して、代わりにマウスイベントを発生させま す。",
"name":"ignoretouch",
"type":"select",
"user":true,
"values":[
{ "value":"false", "desc":"有効", "default":true },
{ "value":"true", "desc":"無効" }
]"

I'm not sure if that means the default is true, or if the value false is to be the default. Either way I'm not exactly sure what would cause touch input to not work. The only thing I could think of would be that it is actually working but it has shifted due to the dispscroll or something. If this was the case the main menu would work ok as would touching to move to the next dialogue but somethings would appear to not work.

[Mizuti]

Try running Fate.exe from the command line and specifying the option --ignoretouch=false and see if that helps. I'm not entirely sure if it is false or true by default as the line is as follows:
" "caption":"タッチイベントの無効化", "description":"タッチイベントを無効化して、代わりにマウスイベントを発生させま す。",
"name":"ignoretouch",
"type":"select",
"user":true,
"values":[
{ "value":"false", "desc":"有効", "default":true },
{ "value":"true", "desc":"無効" }
]"

I'm not sure if that means the default is true, or if the value false is to be the default. Either way I'm not exactly sure what would cause touch input to not work. The only thing I could think of would be that it is actually working but it has shifted due to the dispscroll or something. If this was the case the main menu would work ok as would touching to move to the next dialogue but somethings would appear to not work.

That looks like JSON so i would say "false" is the default value. Also I found this in the code:

if(TVPGetCommandLine(TJS_W("-ignoretouch"), &touch)) {
    ttstr str = touch;
    if(str == TJS_W("true")) ignore_touch = true;
}

This means touch should be enabled by default and can only be explicitly disabled via the command line.


Additionally the game does recognized the touch input device as evidenced by the log during startup:

19:43:44 (info) Rebuilding Auto Path Table ...
19:43:44 (info) Total 0 file(s) found, 0 file(s) activated. (1ms)
19:43:44 Enable Digitizer
19:43:44 The device has an integrated touch digitizer. 
19:43:44 The device has an integrated pen digitizer.
19:43:44 The device supports multiple sources of digitizer input. 
19:43:44 The device is ready to receive digitizer input.
19:43:44 (info) Loading startup script : startup.tjs

Here are the settings I run the game at:
- Window Size: 1.00x
- Quality: High (tried Low as well)
- Aspect Ratio: Standard

Neither the main menu nor advancing text work with touch input. What does work are the configuration tabs for activating the various patch features at the top of the window. I would guess that is handled by the Windows window itself and the rest is handled by the game.
Could you please have a look at the the #define "TVP_TOUCH_DISABLE" I mentioned before?

[TheUnknownIdentity]

That looks like JSON so i would say "false" is the default value. Also I found this in the code:

if(TVPGetCommandLine(TJS_W("-ignoretouch"), &touch)) {
    ttstr str = touch;
    if(str == TJS_W("true")) ignore_touch = true;
}

This means touch should be enabled by default and can only be explicitly disabled via the command line.


Additionally the game does recognized the touch input device as evidenced by the log during startup:

19:43:44 (info) Rebuilding Auto Path Table ...
19:43:44 (info) Total 0 file(s) found, 0 file(s) activated. (1ms)
19:43:44 Enable Digitizer
19:43:44 The device has an integrated touch digitizer. 
19:43:44 The device has an integrated pen digitizer.
19:43:44 The device supports multiple sources of digitizer input. 
19:43:44 The device is ready to receive digitizer input.
19:43:44 (info) Loading startup script : startup.tjs

Here are the settings I run the game at:
- Window Size: 1.00x
- Quality: High (tried Low as well)
- Aspect Ratio: Standard

Neither the main menu nor advancing text work with touch input. What does work are the configuration tabs for activating the various patch features at the top of the window. I would guess that is handled by the Windows window itself and the rest is handled by the game.
Could you please have a look at the the #define "TVP_TOUCH_DISABLE" I mentioned before?

I will have a look tonight when I get back to my dorm. Worst comes to worst I guess the left mouse click could be overridden to be that and touch.

Also I'm assuming the define would be a preprocessor definition for krkrz. If this is the case you can try setting the correct preprocessor to have it enabled and compile it. The krkrz compiled from the GitHub source will run just fine for Fate.

[NM64]

I'd like to inquire the possibility of changing the text label for "Quality" to instead say "Resolution".

This would better reflect that users using "low" aren't really missing out on graphical quality or the like in the traditional PC gaming sense of low vs high graphical quality.

...and technically the "low" quality art assets are actually higher quality due to their lossless nature compared to the lossy-compressed art assets used for "high" quality.



EDIT: Heck maybe I could try doing it myself, but this time actually doing it properly by taking into account that there's seperate files for Japanese and English.



EDIT 2: Uhhh, what's up with the existance of "Fate.jpg" (not a typo) in bgimage.xp3? Why JPEG?

[TheUnknownIdentity]

I'd like to inquire the possibility of changing the text label for "Quality" to instead say "Resolution".

This would better reflect that users using "low" aren't really missing out on graphical quality or the like in the traditional PC gaming sense of low vs high graphical quality.

...and technically the "low" quality art assets are actually higher quality due to their lossless nature compared to the lossy-compressed art assets used for "high" quality.



EDIT: Heck maybe I could try doing it myself, but this time actually doing it properly by taking into account that there's seperate files for Japanese and English.



EDIT 2: Uhhh, what's up with the existance of "Fate.jpg" (not a typo) in bgimage.xp3? Why JPEG?

There are a handful of unexplained things. I just assume it to have been something TM did for some reason. Like how HollowAtaraxia is set to 1 (True) in some if the script files. It's like umm ok...

That being said, everything not in a patch_ file isn't us anyway so I'm not sure anyone can explain it. If someone could I'd have a laundry list of questions lol

[Jacktheinfinite101]

Resolution sounds like a more fitting name for the "window size" option so I feel like that'd get too confusing.

[NM64]

Resolution sounds like a more fitting name for the "window size" option so I feel like that'd get too confusing.

But window size doesn't change the resolution at all...it only changes the zoom scaling factor.

Of course this confusion between the two settings wouldn't be an issue if we went with my crazy idea of making "high" quality natively render at some ultra high resolution and then use large amounts of downscaling to archive more normal sizes.

[Alyinghood]

My multi-platform version supports arbitrary scaling thanks to its usage of SDL2. Currently, I'm working on REing the effect DLLs.

krkrz has separate events for mouse and touch input. I think the game does not handle touch input separately, so you may need to disable it with a manifest value or similar so that Windows knows to send mouse events instead of touch events. The proper fix would be to implement touch input in the game script files. The relavent events are Layer.onTouchDown, Layer.onTouchUp, Layer.onTouchMove, Layer.onTouchScaling, Layer.onTouchRotate, Layer.onMultiTouch, Window.onTouchDown, Window.onTouchUp, Window.onTouchMove, Window.onTouchScaling, Window.onTouchRotate, and Window.onMultiTouch.
There are no documentation for these functions, so you'll need to look at the krkrz source code:
https://github.com/krkrz/krkrz/blob/...Intf.cpp#L3140
https://github.com/krkrz/krkrz/blob/...wIntf.cpp#L386

Status update on GCC building: I can't build krkrz itself and expect it to work, but I CAN build most of the plugins. (The ones I can't build are related to Windows codecs, DirectShow, streams.h, etc)
mingw-w64 6.0.0, GCC 8.3.0, and binutils 2.32 seemed to fix my problems.

[TheUnknownIdentity]

Well unfortuantely I don't have much time to investigat this week but I have confirmed that the touch was indeed working with the old fate/stay night realta nua patches. It is likely due to a difference between engines. I also did confirm that TVP_TOUCH_DISABLE is not defined.

@uyjulian got any ideas?

Edit: I see your post now lol

[NM64]

I wouldn't care so much about the terminology of "Quality" if there was a window size of like 0.65x available since, as I made quite clear before the first public release, it's currently impossible to use "high" quality in windowed mode on 768p and 800p displays once you factor in toolbars and such.

I even humored myself and tried adding such a "0.65x" window size, and while it functioned in the VN itself without issue, the GUI itself did not display a bullet point next to the value whenever it was selected...

windowSizeMenu.add(this.window520MenuItem = new KAGMenuItem(this, "0.65x", 1,
                "kag.onWindowSizeMenuItemClick(,520)", false))

[TheUnknownIdentity]

I wouldn't care so much about the terminology of "Quality" if there was a window size of like 0.65x available since, as I made quite clear before the first public release, it's currently impossible to use "high" quality in windowed mode on 768p and 800p displays once you factor in toolbars and such.

I even humored myself and tried adding such a "0.65x" window size, and while it functioned in the VN itself without issue, the GUI itself did not display a bullet point next to the value whenever it was selected...

windowSizeMenu.add(this.window520MenuItem = new KAGMenuItem(this, "0.65x", 1,
                "kag.onWindowSizeMenuItemClick(,520)", false))

Ah congrats you now have the same level of tjs programming experience as I do lol.

[NM64]

Ah congrats you now have the same level of tjs programming experience as I do lol.

But I didn't even do anything other than change the pixel count numbers from 640 to 520 and the "0.80x" text label to "0.65x"... (though not after first making a copy for the "640" option so that the "0.80x" selection was still present).

I'm not really sure one can call such a basic number change "programming" - this is much more akin to manually changing some settings via config.ini files or the like.

[TheUnknownIdentity]

That looks like JSON so i would say "false" is the default value. Also I found this in the code:

if(TVPGetCommandLine(TJS_W("-ignoretouch"), &touch)) {
    ttstr str = touch;
    if(str == TJS_W("true")) ignore_touch = true;
}

This means touch should be enabled by default and can only be explicitly disabled via the command line.


Additionally the game does recognized the touch input device as evidenced by the log during startup:

19:43:44 (info) Rebuilding Auto Path Table ...
19:43:44 (info) Total 0 file(s) found, 0 file(s) activated. (1ms)
19:43:44 Enable Digitizer
19:43:44 The device has an integrated touch digitizer. 
19:43:44 The device has an integrated pen digitizer.
19:43:44 The device supports multiple sources of digitizer input. 
19:43:44 The device is ready to receive digitizer input.
19:43:44 (info) Loading startup script : startup.tjs

Here are the settings I run the game at:
- Window Size: 1.00x
- Quality: High (tried Low as well)
- Aspect Ratio: Standard

Neither the main menu nor advancing text work with touch input. What does work are the configuration tabs for activating the various patch features at the top of the window. I would guess that is handled by the Windows window itself and the rest is handled by the game.
Could you please have a look at the the #define "TVP_TOUCH_DISABLE" I mentioned before?

On second thought ignore my private message. You can just run it from the command prompt with -ignoretouch=true
It must be one dash and not two, krkrz wants to be picky and I didn't notice.

Edit: This will be fixed in the next patch update. Also I apologize for the delay on this after stating I would look into it. I have been busy with course work and honestly just forgot about it.

[NM64]

I just realized that the "known bugs" list is missing the bug where the window sizing is borked up after playing a Vita OP video in-game in windowed mode when using window sizes other than 1.00x.


Also in the "known bugs" list, the following are two separate issues are missing a line-break, and the mention of "800x600" is no longer applicable ever since the window size label change; I'd also like to elaborate on the second listed bug that it results in underscan when using sizes below 1.00x:

-The default window size for 768p displays will result in the program window "overflowing" the desktop and thereby running off the screen-The PS2 and especially the Vita Fate OP have the bottom of the video cut off when using window sizes larger than 800x600 / 1.0x, and larger window size ratios will cut off the bottom to even greater degrees.

So it should look like this:

-The default window size for 768p displays will result in the program window "overflowing" the desktop and thereby running off the screen

-The PS2 and especially the Vita Fate OP have the bottom-right corner of the video cut off when using window larger than 1.00x, and using a window size of 0.80x results in underscan on the OP video instead of cropping

EDIT: ...but if we're going to add a mention of the window-size bug after the Vita OP videos, then it should really look something like this:

-The default window size for 768p displays will result in the program window "overflowing" the desktop and thereby running off the screen

-The PS2 and especially the Vita Fate OP have the bottom-right corner of the video cut off when using window larger than 1.00x, and using a window size of 0.80x results in underscan on the OP video instead of cropping

-After playing one of the Vita OP videos in-game in windowed mode, if you set the window size to anything other than 1.00x or it's already set to something other than 1.00x, the bottom-right of the main in-game graphics and text will either have underscan (0.80x size) or be cropped off (sizes larger than 1.00x)

[Mizuti]

On second thought ignore my private message. You can just run it from the command prompt with -ignoretouch=true
It must be one dash and not two, krkrz wants to be picky and I didn't notice.

That did the trick. Now both touch and pen input work (including right click by long touch). Unintuitive, but that is Windows programming for you

I apologize for the delay on this after stating I would look into it. I have been busy with course work and honestly just forgot about it.

No worries. School/university/etc. comes first.