Input Lag Compensation to compensate for game's internal lag?



FWIW I think what you’ve achieved is great. I don’t think this sounds like a good idea but what do I know.

I don’t think you should fix every core either, you should focus on cores that interest you, document your findings and fixes and let the community sort out fixes for the rest.

Just my opinion.


I just hit an amusing bug… For some reason, the main core isn’t responding to input at all, and the secondary core is getting all the inputs instead. So the primary core is just playing the title screen music and the secondary core is actually playing the game and showing video.

So this does mean I got running a core twice working…


Got the Secondary Instance feature working, and did a small amount of testing, it seems to work okay on my PC for a few cores I tried.

Primary Instance runs the emulation, input handling, and sound. Secondary instance runs the visuals one or more frames ahead. This prevents the Primary instance from loading state every frame, so there are less artifacts and crashes.


Well, got a black screen and can not compile it any more. :slightly_frowning_face:

In file included from libretro-common/compat/fopen_utf8.c:1:0:
error: unknown type name ‘bool’; did you mean ‘_Bool’?
bool unlink_utf8(const char * filename);

Installed in a new dir, can’t load the core (tested with snes9x).


Redid the fopen utf-8 stuff

I’ve never seen the black screen happen on my computer.


The black screen happens when I try to launch the exe from my usual RA folder, alongside dlls and cfg.

Trying again with Mingw64 (gcc 7.3), still some errors.

(and going to sleep for today…)


added the cpp files to griffin_cpp


Just thought I should mention that it being C++ makes it a lot less likely to be mergeable into master.


C++ was just used to develop it rapidly, if it really needs to be C, there aren’t that many changes to be made to turn it back into C. Biggest one is to eliminate use of the stl map and tuple classes.


I really don’t understand the aversion to C++. Once you link in malloc and all its friends, bringing in C++ is not much bigger, as long as you don’t do something stupid like use iostream.

C++ ends up being more maintainable if you do not go full out in multiple layers of unnecessary abstraction, just because you get stl containers and strings.

Anyway, how do I get the system temp directory on a platform other than Linux or Windows? I see that the Wii version supports dynamic loading libraries, but there is no system Temp directory on that system, and the Retroarch Cache directory is defined as blank by default.


I’m pretty sure it uses static linking against RetroArch.


Gearboy seems to work fine and didn’t crash on Skate or Die level 3 loading (still using readhead v1).


Ah, gearboy’s a different emulator.

Gambatte happens to work fine on level 3 using readahead v2. In order to get the crash on v2, you’d need a frame perfect change in input on the exact frame it would trigger, and also never change your input after that point.


I was wondering if someone could send in a directory tree that causes the black screen problem, possibly get it down to the bare minimum. The minimum might just be the config file itself.


Indeed, had the black screen just putting my cfg file in a new install alongside your exe.


It’s probably because I’m not making CG builds then.


Ah yes, that’s it… that shader in the main config file causing that issue… not the 1st time it happens. :slightly_frowning_face:

But I can’t load any core at all. Can you run the ones you get from the buildbot?


Make sure the directory defined for unzipping files (cache_directory) actually exists. The setting for cache_directory is left blank by default due to a bug. Your cfg file refers to “cache”, which isn’t created by default, make sure it exists.


Did not help.

[ERROR] Failed to open libretro core: “E:\Emulateurs\RetroArch-runahead-v2\cores\snes9x_libretro.dll”
[ERROR] Error(s): The specified module could not be found.


Failing to load a DLL usually means wrong architecture here (x86 vs x64).