clementgallet
N++ softlocks on loading screen
Running the steam version of N++ (64-bit, Virtual Steam client checked), the game hooks properly and has working savestates + OSD, but the loading screen is eternal. The frames advance and the loading screen continues to animate, but it never actually gets to the main menu. None of the time tracking options seem to help.
Here's the output in the terminal from GDB, no idea if this will help:
Attempt 1: Couldn't connect to socket. Attempt 2: Connected. [libTAS f:0] Thread 44069 (main) ERROR: Could not import symbol SDL_DYNAPI_entry [libTAS f:0] Thread 44069 (main) Could not find the original SDL_DYNAPI_entry function, using the system one [libTAS f:0] Thread 44069 (main) ERROR: Could not import sdl dynapi symbol SDL_GetDisplayUsableBounds [New Thread 0x7fffe549b640 (LWP 44074)] [New Thread 0x7fffe4c9a640 (LWP 44075)] [New Thread 0x7fffdffff640 (LWP 44076)] [New Thread 0x7fffdf7fe640 (LWP 44077)] [New Thread 0x7fffdeffd640 (LWP 44078)] [New Thread 0x7fffde7fc640 (LWP 44079)] [New Thread 0x7fffddffb640 (LWP 44080)] [New Thread 0x7fffdd7fa640 (LWP 44081)] [New Thread 0x7fffdcff9640 (LWP 44082)] [libTAS f:0] Thread 44069 (main) OpenGL vendor: Mesa/X.org [libTAS f:0] Thread 44069 (main) OpenGL renderer: llvmpipe (LLVM 12.0.1, 256 bits) [New Thread 0x7fffe4358640 (LWP 44084)] [New Thread 0x7fffdc74a640 (LWP 44085)] [New Thread 0x7fff88010640 (LWP 44086)] [New Thread 0x7fff8380f640 (LWP 44087)] [New Thread 0x7fff8780f640 (LWP 44088)] [New Thread 0x7fff8700e640 (LWP 44089)] [New Thread 0x7fff8680d640 (LWP 44090)] [New Thread 0x7fff8600c640 (LWP 44091)] [New Thread 0x7fff8580b640 (LWP 44092)] [New Thread 0x7fff8500a640 (LWP 44093)] [New Thread 0x7fff84809640 (LWP 44094)] [New Thread 0x7fff8300e640 (LWP 44095)] [New Thread 0x7fff8280d640 (LWP 44096)] [New Thread 0x7fff8200c640 (LWP 44097)] [New Thread 0x7fff8080a640 (LWP 44098)] [New Thread 0x7fff44ffc640 (LWP 44099)] [New Thread 0x7fffac3ea640 (LWP 44100)] [New Thread 0x7fff3ffff640 (LWP 44101)]
If there are any other logs that would be helpful here, let me know.
That's odd. If frames are still advancing, then time is also advancing so it should not be a matter of the game waiting for time to advance. As a precaution, you could run the game with Runtime > Debug > Uncontrolled time to see if it gets further. Also maybe Runtime > Debug > Native events.
It could be a problem of locating/loading data files maybe? You could uncheck Runtime > Prevent writing to disk.
Those options didn't make a difference, unfortunately.
I figured out that N++ writes a log file every time you boot it, so I wanted to compare the log when you boot natively vs with libTAS.
Natively: https://pastebin.com/Nm5phXL9
With libTAS: https://pastebin.com/UDma9jUw
I don't see a difference here, other than that with libTAS it offers the game an enormous amount of sound drivers.
I don't see a difference here, other than that with libTAS it offers the game an enormous amount of sound drivers.
That difference is likely due to how libTAS is forcing ALSA to be used rather than PulseAudio (which is probably what the game ends up using without libTAS), which ends up having a ton more devices available. Although, having that many more devices "available" seems to indicate some ALSA functions are not being hooked so it's being exposed to native sound devices (maybe snd_card_get_name needs to be hooked? dunno)
Another person in the libTAS discord tried to get this game running, and the latest interim seems to be having even more trouble, now getting softlocked before the window is even created, the log sent seems to indicate it's getting stuck with the main thread waiting on the audio thread to advance (in sem_wait), while the audio thread is forever stuck (in snd_pcm_writei while in block mode) since the main thread can't advance time and mix audio due to it waiting on the audio thread libtaslog.txt
