Fate/Stay Night [Realta Nua] PC version Mirror Moon TL insertion project

[NM64]

Whelp, trying to run the installer and VN itself on ReactOS gives the same errors as one gets on XP.

This isn't exactly surprising as ReactOS is specifically targeting XP compatibility and even identifies itself as NT5.2 (same as XP x64 and Server 2003; for reference Vista is NT6.0), but this does mean that it, like XP, will too be completely out of the question in terms of being compatible with the "ultimate edition".

I mean, it kind of makes sense since there is a lot of software and hardware that's basically stuck with only supporting XP at the newest, so attempting to make a FreeDos equivalent for XP can be particularly useful, especially since compatibility between Vista and even Win10 hasn't radically changed unlike the XP to Vista transition (even more-so considering the incompatibility between 32bit drivers on 64bit OSes).

[TheUnknownIdentity]

Whelp, trying to run the installer and VN itself on ReactOS gives the same errors as one gets on XP.This isn't exactly surprising as ReactOS is specifically targeting XP compatibility and even identifies itself as NT5.2 (same as XP x64 and Server 2003; for reference Vista is NT6.0), but this does mean that it, like XP, will too be completely out of the question in terms of compatibility.I mean, it kind of makes sense since there is a lot of software and hardware that's basically stuck with only supporting XP at the newest, so attempting to make a FreeDos equivalent for XP can be particularly useful, especially since compatibility between Vista and even Win10 hasn't radically changed (even more-so considering the 32bit and 64bit driver situation between XP and everything newer).

And that error is that a function was not found in kernel32.dll. In other words RIPIn case anyone is wondering, I could, in theory, fix it by creating a fake dll that sits between the os and installer and calls the correlating xp functions. However, not only is it a bunch of unnecessary work, and decent antivirus will immediately freak out upon seeing a kernel32.dll doing so.No, I'm an idiot. I really thought I could patch a dll that is part of the kernel for a minute.

[NM64]

Amusingly enough though, it seems like the visual c++ 2015 32bit runtime installed perfectly fine on ReactOS. I mean in an ideal world it should, but it just seems hilarious to see it installing on something that isn't Windows.

No, I'm an idiot. I really thought I could patch a dll that is part of the kernel for a minute.

Well the next "off-the-beaten-path" thing I was going to test it on was Linux+Proton, and if it works there then in my mind it'll largely make up for the lack of compatibility with XP and ReactOS.

Fun fact - I demonstrated back in 2010 that the original 2004 Fate/stay night + mirror moon installer seemed to work decently back on the now-old version 0.3.11 of ReactOS (the only issues back then being font rendering and a tenancy to crash when save data is present).

[TheUnknownIdentity]

Amusingly enough though, it seems like the visual c++ 2015 32bit runtime installed perfectly fine on ReactOS. I mean in an ideal world it should, but it just seems hilarious to see it installing on something that isn't Windows.Well the next "off-the-beaten-path" thing I was going to test it on was Linux+Proton, and if it works there then in my mind it'll largely make up for the lack of compatibility with XP and ReactOS.Fun fact - I demonstrated back in 2010 that the original 2004 Fate/stay night + mirror moon installer seemed to work decently back on the now-old version 0.3.11 of ReactOS (the only issues back then being font rendering and a tenancy to crash when save data is present).

I know that uyjulian was looking into porting krkrz to mingw. Not sure where he went with it, if anywhere but linux and mac would be childs play from there.

[NM64]

Wait a minute, at least ReactOS is FOSS, so there's no reason why you couldn't modify a kernel DLL in that specific scenario. Sure you might not be able to do it while the OS is running, but I mean it'd technically be possible in some manner regardless.

(though I would guess that such patches wouldn't be officially accepted since it deviates from the XP compatibility target)



Now to clarify, I wouldn't necessarily say that doing such a thing is actually worth the time and effort, but it should technically still be possible.

...and technically it could even theoretically be possible to use that modified ReactOS DLL on XP as well, though it'd probably be unwise to use in in-place of the original XP DLL and would be better to just use the modified DLL for just the VN (assuming that's even possible of course.)

[TheUnknownIdentity]

Supported platforms are Windows 7 >=

[Jacktheinfinite101]

Supported platforms are Windows 7 >=

all right so that's our definitive answer?

[NM64]

Wait, what about Win7 without a service pack?

...I mean, SP1 can be installed for free, but the VN set to "low" quality works absolutely perfectly and it's just the installer that doesn't.

[TheUnknownIdentity]

It looks that way. Qt5 is supposed to work in Vista but I can't run it directly installing it in Vista and the amount of errors I had to ignore while installing tells me that it's bs. Also I couldn't find win7 without sp1. However, if you tell me exactly what the msg box error that comes up says I can give a definite answer.

[NM64]

It looks that way. Qt5 is supposed to work in Vista but I can't run it directly installing it in Vista and the amount of errors I had to ignore while installing tells me that it's bs.

Is that for the VN OPs or the installer?

Because for the VN itself, there's always the possibility of bootleg bundles of the ultimate edition that ditch the installer route entirely and just use a pre-existing portable installation of the VN similar to what I've been using for testing.

...or someone that has access to a Win7 PC but either doesn't own one or wants to run it on a laptop that only has Vista or the like.

Also I couldn't find win7 without sp1

I may or may not be able to rig something up...stay tuned.

However, if you tell me exactly what the msg box error that comes up says I can give a definite answer.

Here you go:

http://forums.nrvnqsr.com/showthread...=1#post2952084

[TheUnknownIdentity]

Is that for the VN OPs or the installer?

Because for the VN itself, there's always the possibility of bootleg bundles of the ultimate edition that ditch the installer route entirely and just use a pre-existing portable installation of the VN similar to what I've been using for testing.

...or someone that has access to a Win7 PC but either doesn't own one or wants to run it on a laptop that only has Vista or the like.



I may or may not be able to rig something up...stay tuned.




Here you go:

http://forums.nrvnqsr.com/showthread...=1#post2952084

No, with the newest installer I have sent. The errors may look the same but they may not be.

Actually I will double check its presence and reedit hold on.

Edit: It's there please ensure it is the newest version.

[Alyinghood]

So here are the following issues that I see:
Runtime resizing bugs
Video playback issue
WebP Susie Plugin does not load on Windows XP
Installer issue on Windows XP

The runtime resizing bug could be worked around by saving, relaunching, and loading.
The video playback issue could be solved by replacing the DirectShow/WMF code with ffmpeg.
The WebP Susie Plugin issue could be solved by recompiling the plugin with a lower version of MSVC, GCC, or Clang.
I'm not too sure about the installer issue on Windows XP.

Here's my current progress on porting krkrz to GCC: https://github.com/uyjulian/krkrz (check mingw branch)

JXR support, SSE2/AVX special code, and movie playback support are currently stripped out. They will be added back in eventually.
Some plugins cause a memory access exception due to different ABIs between GCC and MSVC. I heard that Clang has better ABI support for MSVC, so I might try that later.

There is also the option to port the script to Ren'Py, fixing those four problems while re-adding support for Windows XP. The installer code could be migrated into the Ren'Py engine. Additional features with Ren'Py support are much faster skipping, GPU rendering, Video rendering with ffmpeg (no need to deal with DirectShow/WMF), All codec support by ffmpeg (built right in with no additional plugin needed), and macOS/Linux/Raspberry Pi/iOS/Android support. Porting the KAG scripts to Ren'Py is very easy, but porting the interfaces, adding XP3 support, and converting TCRF files may take a bit more effort.

[NM64]

It's there please ensure it is the newest version.

Yes, it occurs with your newest "Vista fix" as well.



----------------------------------------------------------------

Video playback issue

You really should elaborate what you mean because, outside of a non-standard video configuration (modified via Win7DSFilterTweaker or CodecTweakTool) or having audio drivers not be installed (why?), I literally could not get the OP videos to not work as long as the OS was not Vista or older.

WebP Susie Plugin does not load on Windows XP.

The entire VN itself doesn't run on XP regardless of whether the the WebP Susie Plugin is present or not.

To clarify, the WebP Susie Plugin also doesn't run on the likes of Win7 without any service pack, yet the VN itself when set to "low" quality (or when the high quality XP3 is not present) can be ran on even Vista without any service pack (though the OP videos currently bork out on any version of Vista).

There is also the option to port the script to Ren'Py, fixing those four problems while re-adding support for Windows XP.

While the current implementation of the VN does not support freely resizing the program window and therefore there's no guarantee that such a hypothetical Ren'Py port would include that, I would like to point out that there's a "WON'TFIX" bug on Win7 and older that results in Ren'Py VNs in windowed mode from being unable to run truly maximized (this is most noticeable, but not exclusive to, when the taskbar is set to auto-hide).

It would however mean a native Linux version which is always nice.

Video rendering with ffmpeg (no need to deal with DirectShow/WMF), All codec support by ffmpeg (built right in with no additional plugin needed)

We need to use AVC 8bit for hardware decode support anyway (the Vita Fate OP is in 1080p after all), so extra codec support is largely meaningless unless you're running 12+ years old stuff that doesn't even have AVC hardware decode (in which case Ren'Py's native support of lighter-weight formats like VP8 could be useful).

[TheUnknownIdentity]

So for the installer on windows 7, SP1 is indeed required. I will ensure that it is the minimum requirement though.

[Jacktheinfinite101]

So for the installer on windows 7, SP1 is indeed required. I will ensure that it is the minimum requirement though.

Cool. Is everything set on your end or do you need to update and send me the installer again?

[TheUnknownIdentity]

Cool. Is everything set on your end or do you need to update and send me the installer again?

The latest one I sent should be fine. I'm just making sure now.

Edit: It works just fine with SP1

[NM64]

I humored myself and tried the installer and the ultimate edition VN itself on Linux Mint 19.1 64bit Cinnamon via Steam beta's proton 3.16-6 running with mesa 18.3.3-1 padoka...and I didn't exactly get far.


This is what I got when running the installer (all versions except 32bit vista fix):


And this is what I got when trying to run the VN itself with the according save file set to "low" quality (the newest 32bit Vista fix also gave this error):

EDIT: Crap, I forgot about trying to delete the "config.ksc" file! Guess I'll have to go test that...



Note however that I was testing via a Haswell iGPU (the newest GPU I own) which has incomplete Vulkan support; since Proton uses Vulkan, it's possible that newer GPUs with full Vulkan support could actually have better luck.

So for the installer on windows 7, SP1 is indeed required.

May I ask what the limiting factor is? I wouldn't think it'd be anything related to c++ 2015 since the installer runs on vanilla SP1 when that isn't installed.

...though at the same time it does sometimes seem to require it just to run - while my friend was over here yesterday, in addition to ripping his Windows install disc, I tested on his Sandy Bridge-based (no discrete GPU) Win7 SP1 laptop and found that the installer would not run until I manually installed c++ 2015 32bit even though the OS was originally installed by myself directly as Win7 SP1 (not as Win7 without any service pack and then upgraded to SP1).

[TheUnknownIdentity]

I humored myself and tried the installer and the ultimate edition VN itself on Linux Mint 19.1 64bit Cinnamon via Steam beta's proton 3.16-6 running with mesa 18.3.3-1 padoka...and I didn't exactly get far.


This is what I got when running the installer (all versions except 32bit vista fix):


And this is what I got when trying to run the VN itself with the according save file set to "low" quality (the newest 32bit Vista fix also gave this error):

EDIT: Crap, I forgot about trying to delete the "config.ksc" file! Guess I'll have to go test that...



Note however that I was testing via a Haswell iGPU (the newest GPU I own) which has incomplete Vulkan support; since Proton uses Vulkan, it's possible that newer GPUs with full Vulkan support could actually have better luck.






May I ask what the limiting factor is? I wouldn't think it'd be anything related to c++ 2015 since the installer runs on vanilla SP1 when that isn't installed.

...though at the same time it does sometimes seem to require it just to run - while my friend was over here yesterday, in addition to ripping his Windows install disc, I tested on his Sandy Bridge-based (no discrete GPU) Win7 SP1 laptop and found that the installer would not run until I manually installed c++ 2015 32bit even though the OS was originally installed by myself directly as Win7 SP1 (not as Win7 without any service pack and then upgraded to SP1).

The limiting factor is non SP1 Windows 7. It's a software issue. Specifically "The procedure entry point ucrtbase.abort could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll." The runtimes are incompatible with what is provided in pre SP1 Windows 7.

[NM64]

There is also the option to port the script to Ren'Py, fixing those four problems while re-adding support for Windows XP.

Additional features with Ren'Py support are much faster skipping, GPU renderin

So funny thing about that - on the face of it one would think that using Ren'Py would result in better performance overall, but in my experience Ren'Py VNs actually have higher minimum CPU requirements than comparable kirikiri VNs (and seemingly krkrz as well)..

Perhaps it's be most accurate to say that Ren'Py can take better utilization of newer and higher-end hardware, but kirikiri (and seemingly krkrz) is in general lighter-weight and can run well on weaker configurations, sometimes considerably so (1st gen Atoms run it fine which means CPU performance would be adequate going back ~18 years, but such CPUs can sometimes be touch-and-go for Ren'Py).

Currently our hardware minimum requirement is considerably older than our software minimum requirement - Win7 SP1 for the software, ~2GHz Athlon 64 x2 and 1.6GHz Core 2 Duo for the hardware, but if you disregard the 1080p Vita Fate OP, then the CPU requirement can run on single core ~1GHz CPUs from the early 2000s without issue (even the PS2 Fate OP ran well on my 1.6GHz 1st gen Atom which itself is comparable to a 2GHz Northwood Pentium 4 and a 1.7GHz Athlon XP). And of course, if you have any GPU made in the decade, then CPU requirements basically go out the window as AFAIK all CPUs compatible with GPUs that support AVC hardware decode are definitely going to be fast enough to run the VN without issue.

So the thing is, while Ren'Py could allow you to make it compatible with older OS software, it's quite possible that it would then make it require newer hardware, and replacing hardware tends to require more time, money, and effort than it does to replace software (especially since replacing hardware commonly requires re-installing your OS anyway...unless you're on Linux). Admittedly Athlon 64 x2 and Core 2 Duo-era stuff is commonly given away for free at this point, but that still can require some more time and effort then most normal people would want to deal with.



----------------------------------------------------------------



Interesting thing about Steam & Proton/Steam Play - you have to actually first install a non-Linux-native game that is available on Steam/in your Steam account in order for Proton to give you any result when trying to run non-Steam games through Proton. If one doesn't didn't do that, then clicking "Play" for the likes of Fate.exe would just result in what looked to me like a small window that would instantly close


OK, so after deleting "config.ksc" and then trying to run Fate.exe through Proton 3.16-6 beta (older versions of proton gave the "instantly-closing small window" result) with mesa 18.3.3-1 padoka on my Intel Haswell iGPU via Linux Mint Cinnamon 19.1 x64, I get the following, which I believe would normally be the window that pops up asking for the save folder location:



Yes, that tiny thing is all there is of the resulting program window. In this case I cannot resize the window or anything, so the only thing I can do is click the X to close it.



After a moment this window then appears:

screenshot

And nothing happens at all if I click around or hold CTRL or anything, and there didn't seem to be any sound and stuff.

This is exactly the sort of thing I wouldn't at all be surprised is caused by the incomplete Vulkan implementation on my Intel Haswell iGPU, but again that's the newest GPU I own as no other GPU I have is even compatible with Vulkan in the slightest.



But then clicking the X on that window gave me the following:

screenshot

So the VN is in fact running, and I can even click either "Cancel" to make the message go away or click "OK" to actually close the program cleanly.

[Jacktheinfinite101]

The latest one I sent should be fine. I'm just making sure now.

Edit: It works just fine with SP1

Alright, since that hasn't been overturned I'm green lighting a public release. I'm going to set anywhere from tomorrow to this weekend as the target range for release. As a preparatory phase I'm going to take stock of 2 things here just to make sure I have them correct.

First is the bugs:

Bugs

switching from full screen to wide screen and back creates white line
switching from SD to HD causes Decensored H CGs to not play in H scenes
mature content CGs don't display unless you switch fom HD to SD then back to HD, and they only display in HD mode (Hotfix in place for now)
Openings crash if ctrl'ed through when in fullscreen
Skipping H scenes sometimes crashes the game and sometimes H scenes fail to be skippable even after being viewed
Title misaligned
Changing between HD and SD mode in music menu soft crashes the game
Some menu items are positioned offscreen when using wide mode during certain CGs
Playing the openings in non-default resolutions can result in the game scaling back to normal incorrectly

The second is people who have worked on it. I've been out of the loop for a bit on this project so my knowledge of who has been working on it is limited to people who have been helping me now, and people I worked with before I disappeared for multiple years, and I imagine Quibi might have worked with some other people I don't know about in that time, and I would like them to be credited so I'd appreciate someone who has been eyeing this more than me (such as NM64) to verify I'm not missing anyone.

staff

Jacktheinfinite101
Quibi
Hintay
Annonamous
NM64
Kotonoha
Waku Waku
MeruP
uyjulian
Hyarion
bishopcruz and Annonymous
Himeros and Belldandy100
Terrafire
Dallas Hickan
ニサンカタンソ
Taka-jun, ArchDemon, Tjm, and puKKa from Mirror Moon

I'm also willing to give credit to those who beta tested for me as the help they provided was extremely helpful in spotting and fixing issues, however if one of the beta testers here doesn't wish to have their name in the credits please let me know.