While I probably haven't played either in a decade, I bring sol.exe and winmine.exe on general principle, as both had their "Copilot in Notepad" shark-jumping moments all the way back in Windows 8 with the introduction of achievements and in-app purchases.
Still used under the hood by two major auto dealership computer systems, for example (UniVerse in the Reynolds and Reynolds ERA DMS and a fork of Northgate Reality in the CDK DMS).
120 Hz is around the point where I'd start to consider frame generation in the first place, assuming everything else in the system is optimized for minimal latency.
At 100 Hz or less, I've yet to experience frame generation in any form that doesn't result in unacceptably floaty input relative to the same system with framegen disabled.
Probably just due to the fact that nothing in the standard C language maps to the x86 IN and OUT instructions for reading and writing I/O ports, though MS-DOS-era compilers supplied macros or library functions to use them (inp, inpw, outp, and outpw in Microsoft C, for example).
This was true for the 10-digit CD keys Microsoft used for many products in the 90s: the first three digits could be almost anything, and the last seven digits had to sum to a multiple of 7, so, e.g., 111-1111111 was a valid product key (for any product that used the scheme).
Sort of reminds me of the DEC PAKGEN tool to generate licenses for the VMS license management facility, which DEC distributed so third-party software vendors could issue licenses for their own software.
To prevent vendor A from creating licenses for vendor B's products, each DEC-issued PAKGEN license only authorized license generation for a specific named vendor's products.
As with all other DEC-supplied VMS software, PAKGEN was licensed through the VMS license management facility.
Thus if you could somehow get a PAKGEN license for the vendor name "DEC", you could use it to generate licenses for arbitrary DEC products.
Including PAKGEN itself.
And you could therefore generate licenses authorizing PAKGEN to generate licenses for arbitrary vendors' products.
From the context of the conversation, it was clear they were talking about the Super Famicom entries, not saying that DQXI could be demoted to a Famicom game[1]. I don't really agree with them, although I didn't feel like continuing to belabour the point at the time. I think the SFC remakes of the Famicom DQ games (1-3) add an entirely new dimension to them. Despite their influential heritage, I do not think DQ 1-3 on the Famicom stand the test of time, and I don't think they're worth playing other than for the historical value of seeing how the genre developed. Whereas I think DQ 1-3 remakes on the Super Famicom conversely absolutely do hold up as top-notch experiences.
[1] Although notably, they did release a demake of DQXI into a Super Famicom-style game!
Did you just use a Gen 8 (3DS/Switch, PS4, Xbox One) game to make a point about SNES gameplay? Did you intentionally miss the point or are you attempting to obfuscate it?
Obviously a game for modern consoles is going to be far more advanced than an NES game; even while still being quite conservative.
reply