Ratchet & Clank:Size Matters - Crash/Freeze on Ad-Hoc - 1.10.1 #13104

ghost · 2020-07-07T10:33:46Z

Hi,it is me again,i encountered issue with Ad-Hoc option of game Ratchet & Clank:Size Matters.When i enter Ad-Hoc menu with both devices,running latest version of course,i can't create Profiles for both devices,stating Password needed to enter,but this is Ad-Hoc and there is no password frame for entering it.If i manage to do so,game crashes when hosts enters the game,interestingly enough,i tried version 0.9.7 and everything worked fine.If possible,i could be happy if you managed to fix this problem for next update.

TIA

ghost · 2020-07-07T14:05:09Z

I dont think this will be fixed anytime soon.
You could use JPCSP or the old PPSSPP for now.

ghost · 2020-07-07T17:31:29Z

Thank you for feedback,i appreciate it.
I don't want to sound mean,but i will wait for developer's answer and rant about this

hrydgard · 2020-07-07T19:30:02Z

PPSSPP's AdHoc support is still very experimental and rough. It seems as soon as someone fixes one game, another game breaks so it's very hard to keep everything working. The AdHoc APIs are extremely complex and fragile and indeed not enough effort has been spent on this so far for it to be reliable...

It's just way harder than other parts of the PSP to emulate and very difficult to work on due to the need to use multiple instances for debugging. I know this is excuses, but it's what it is.

ghost · 2020-07-08T05:04:34Z

PPSSPP's AdHoc support is still very experimental and rough. It seems as soon as someone fixes one game, another game breaks so it's very hard to keep everything working. The AdHoc APIs are extremely complex and fragile and indeed not enough effort has been spent on this so far for it to be reliable...

It's just way harder than other parts of the PSP to emulate and very difficult to work on due to the need to use multiple instances for debugging. I know this is excuses, but it's what it is.

Well,i see,it is complicated a lot,and it must be hard to work on the code otherwise than Ad-Hoc itself,it is fine and i understand,i will silently wait in future for the fix.Thanks

adenovan · 2020-07-12T20:40:33Z

PPSSPP code style on C++ is beauty and dang when i jump into adhoc code im looking a spagethi , it is just an excuse but it's what it is too.

need to solve #10832 before jumping into this issues and clear some confusion on the mips call and the adhoc control handler it is the most biggest change from 0.9.7.

rewrite the BSD socket implementation and C code into PPSSPP C++ code style need much energy too , emulator scope is broad especially looking for host machine supported on PPSSPP compability is not an easy thing to maintain as the host machine can restrict some of low level networking call beside of that autotest TDD on adhoc is not finisihed too, some manual work needed as its often crash your PSP WLAN DRIVER.

ghost · 2020-07-14T13:33:33Z

@adenovan
Hi,me again.Since ANR2ME is retiring from PPSSPP,what is your next to-do list on PPSSPP branch?This is little off-topic,but it seems Ad-Hoc here is the major problem.

adenovan · 2020-07-25T05:50:23Z

My to do list right now

create homebrew for adhoc test environment with real console
redocument and dig error info on scenetadhoc , scenetadhocmatching , scenetadhocctl , scenet sony implementation.
build new network protocol or use existing lib on networking as transport layer (adhoc tunnel experiment) for internet play , need edge to edge relay server like whatsapp for this its still uknown pretty fragile.
improve compability and ease of use in local network
play between sony console and the emulator

ghost · 2020-07-25T06:47:18Z

That is really big list,and seems it is very complicated to completely rewrite Ad-Hoc functions.I wish you best luck on it.

anr2me · 2020-08-01T13:03:14Z

My to do list right now

* create homebrew for adhoc test environment with real console

* redocument and dig error info on scenetadhoc , scenetadhocmatching , scenetadhocctl , scenet sony implementation.

* build new network protocol or use existing lib on networking as transport layer (adhoc tunnel experiment) for internet play , need edge to edge relay server like whatsapp for this its still uknown pretty fragile.

* improve compability and ease of use in local network
  play between sony console and the emulator

Don't forget to implement the blocking-socket simulation using non-blocking socket + hleDelayResult :) this should helped reducing stutter (including audio stutter perhaps) and performance degradation during multiplayer a lot :D

ghost · 2020-08-31T15:15:38Z

The game wont crash when using the european version of the game - it will just freeze instead.
It's interesting that it worked on previous versions of PPSSPP though.

anr2me · 2020-09-01T13:41:09Z

The game wont crash when using the european version of the game - it will just freeze instead.
It's interesting that it worked on previous versions of PPSSPP though.

On the EU version, i think it started to freeze (at least the image on screen) when these errors appearing:

PS: Software renderer will crash instead of freezing

Also regarding the issue with profile, @zakilj3 said it only happened when he speedup the game, so may be it have something to do with the timing?

zakilj3 · 2020-09-01T14:02:46Z

I think its timing too as when you create a profile in ratchet & clank size matter, it actually create a specific savefile for it and when you open the multiplayer it load the savefile for multiplayer. So when you speed up the game, I guess it doesn't load properly the save

ghost · 2020-09-02T08:22:52Z

Also note this is another game that works (multiple instances) on JPCSP and you dont even need the prx files there.
It works fine and wont freeze or crash but I only managed to do it with multiple instances last time I tried.

anr2me · 2020-09-02T10:02:03Z

Based on the logs i posted, it's clearly GPU issue LOL, need someone to check those vertex and illegal BJUMP errors first

hrydgard · 2020-09-02T10:28:11Z

Well, if you get that kind of logs, memory got corrupted somewhere and caused the game to run garbage as a display list. No way to recover from there.. The bug that caused the corruption needs fixing and that can be hard to find.

Double-0-seven7 · 2020-09-02T11:12:34Z

So its adhoc related or not? Should another issue be opened not related to this?

hrydgard · 2020-09-02T11:57:23Z

If it only blows up when using the network stuff, it might very well be the cause, either due to a bug directly in networking functions, or some unrelated timing bug, similar to the very obscure one we recently fixed in Crazy Taxi (an example of the kind of bug, not an example of network related)... Hard to say.

anr2me · 2020-09-03T04:34:46Z

If it only blows up when using the network stuff, it might very well be the cause, either due to a bug directly in networking functions, or some unrelated timing bug, similar to the very obscure one we recently fixed in Crazy Taxi (an example of the kind of bug, not an example of network related)... Hard to say.

Actually, it also happened once before using any networking API, right after choosing "Multiplayer Mode" from start menu there will be 3D animation of a rocket flying to a planet, and during this animation it suddenly crashed, while network are initialized on the next menu (Adhoc and Infrastructure selection) after this animation finished.

But on the US version these crash is random, just like the issue of Profile/savedata(issue without speedup), but if it were able to successfully start the multiplayer match and enter the field it won't crash or freeze like what happen on EU version.

PS: The issue of Profile in the US version can be annoying because it happened often and when it happened we can't progress any further without deleting the savedata first, while the EU version didn't have this issue. So may be we can solve this Profile/savedata first?

anr2me · 2020-09-04T10:09:50Z

@EX-e-LD you probably need to track down the last version that didn't crash since 0.9.7 you can jump forth at larger interval and jump back halfway if it was broken until you can close the gap.

You can download older version from https://github.com/hrydgard/ppsspp/tags?after=v1.3

adenovan · 2020-09-05T01:56:56Z

Well, if you get that kind of logs, memory got corrupted somewhere and caused the game to run garbage as a display list. No way to recover from there.. The bug that caused the corruption needs fixing and that can be hard to find.

pretty sure its get corrupted in the network loop , on real console when i do some test on adhoc with joining some game throught their networking beacon to do some test tdd as client many of the display got broken in the host when we just idling not replying something they game expect is always there.

That some sort of packet is still far deep down below , corrupting the host display is so simple , play an adhoc game that make the wireless adhoc turn green.

join the control room with homebrew with same name without do some kind of pdp or ptp broadcasf , host will just keep going without any crash but display is screwed everywhere.

ghost · 2020-09-18T12:32:12Z

Well there is also a graphics corruption issue when going to the adhoc lobby on Kingdom Hearts : https://media.discordapp.net/attachments/509529410123333632/756492385218723860/Recoded.png?width=818&height=630
Dunno if its related to Ratchet & Clank but I decided to share it here anyway.
It's random and not that harmless bug there because after you start a game the graphics become ok.

ghost · 2020-09-23T09:55:06Z

Hi.Me again.Long time no see.I'm in bit of a hurry and i won't be able to test games for really while,i have schedule that's not so easy to follow and GitHub or video-games won't fit for sure.I'm sorry,but i think i will maybe be able to do so when nearest holidays come,until that i won't be active.I'm sorry for any inconvenience i caused.May i ask you to just report latest progress you will do.

TIA

ghost · 2020-10-24T10:06:17Z

Look like I got the game to work without crashing but the 2nd player is stuck under the map for some reason.
Here are some pictures:
1st player:

2nd player:

This only works with the european version for now.
If you want to get to this state you need to choose the Death Match mode and choose Danger Valley as the map.
Capture The Flag mode also works with the map but you will get the same result.

anr2me · 2020-11-02T00:50:04Z

Looks like the issue with Ratchet & Clank Size Matter is related to Dynarec/JIT.
If i use Interpreter the logs are no longer spammed with Bad vertex address errors and the game runs without issue (other than the slow performance with interpreter)

Btw, what is the difference between Interpreter with IR Interpreter?

Edit: Looks like disabling the VFPU_VEC on the JIT is sufficient.

anr2me · 2020-11-02T05:41:49Z

Looks like i was just lucky not to get crashed just by disabling VFPU_VEC because i was using Debug build when testing it (to findout why it crashed, which apparently a crash on JIT), probably because Debug build runs slower compared to Release build, just like how interpreter runs slower than JIT.

When i tested again using Release build, it still crashed even when i've disabled all FPU/VFPU related JIT

Edit: Hmm.. it's really strange, It always works when i use Interpreter on Debug build, but i need to load it from savastate due to very slow boot time.

ghost · 2020-11-02T05:49:18Z

I already tested this with interperter and the software renderer and it didnt work so...
But maybe the issue is closer then you think.

anr2me · 2020-11-02T06:08:55Z

Ah.. looks like what fixed it was because i load it from savestate, tested on Release build with Interpreter, IR Interpreter, and Dynarec were all successful.

I create that savestate because this game were having annoying issue when loading profiles from savedata, where i need to reboot the game many times before i can successfully get the profile to load without weird issue (ie. after creating new profile it can't be loaded), so when i managed to get the profile working properly i decide to create a savestate to saves me from this annoying profile issue.
May be those profiles issue sometimes corrupting the data?

anr2me · 2021-01-11T17:37:41Z

I did some testing to programmatically loads the savestate to locate which line causing the memory corruption during loading module LEVEL_20.PRX

It's started from sceKernelModule.cpp:

u32 sceKernelLoadModule(const char *name, u32 flags, u32 optionAddr) {
...
	PSPModule *module = nullptr;
	u8 *temp = new u8[(int)size];
	u32 handle = pspFileSystem.OpenFile(name, FILEACCESS_READ);
	pspFileSystem.ReadFile(handle, temp, (size_t)size);
	u32 magic;
	u32 error;
	std::string error_string;
	// <-- Loading SaveState at this line won't get corruption
	module = __KernelLoadELFFromPtr(temp, (size_t)size, 0, lmoption ? lmoption->position == PSP_SMEM_High : false, &error_string, &magic, error);
	// <-- Loading SaveState at this line will get corruption
	if (strcmp(name, "disc0:/PSP_GAME/USRDIR/BIN/LEVEL_20.PRX") == 0) {
		delete[] temp;
		SaveState::LoadSlot(PSP_CoreParameter().fileToStart, g_Config.iCurrentStateSlot, NULL);
		return SCE_KERNEL_ERROR_ERRNO_FILE_NOT_FOUND;
	}
	delete [] temp;
	pspFileSystem.CloseFile(handle);
...
}

I'll try to locate the exact line deeper within __KernelLoadELFFromPtr later,
currently i'm having difficulty trying to differentiate between LEVEL_20.PRX from other PRX within __KernelLoadELFFromPtr

anr2me · 2021-01-11T18:15:24Z

Looks like the corruption occurred within KernelImportModuleFuncs in sceKernelModule.cpp

static PSPModule *__KernelLoadELFFromPtr(const u8 *ptr, size_t elfSize, u32 loadAddress, bool fromTop, std::string *error_string, u32 *magic, u32 &error) {
...
	INFO_LOG(LOADER, "Module %s: %08x %08x %08x", modinfo->name, modinfo->gp, modinfo->libent, modinfo->libstub);
	DEBUG_LOG(LOADER,"===================================================");

	u32 firstImportStubAddr = 0;
	// <-- Loading SaveState at this line won't get corruption
	KernelImportModuleFuncs(module, &firstImportStubAddr);
	// <-- Loading SaveState at this line will get corruption
	if (elfSize == 0x000000000028e8ed && (*magic == 0xcccccccc || *magic == 0x464c457f)) {
		if (newptr)
			delete[] newptr;
		SaveState::LoadSlot(PSP_CoreParameter().fileToStart, g_Config.iCurrentStateSlot, NULL);
		return nullptr;
	}
...
}

Trying to go deeper within KernelImportModuleFuncs
Apparently Loading SaveState within KernelImportModuleFuncs will cause infinite loop using this condition:

	if (strcmp(module->nm.name, "rcp1")==0 && module->memoryBlockSize == 0x003c0d00) {
		SaveState::LoadSlot(PSP_CoreParameter().fileToStart, g_Config.iCurrentStateSlot, NULL);
		return false;
	}

So i can't pinpoint the exact line causing the corruption :(

Update:
I was able to avoid the infinite loop by checking the nm.status of the first load

	if (strcmp(module->nm.name, "rcp1")==0 && module->memoryBlockSize == 0x003c0d00 && module->nm.status == 0) {
		SaveState::LoadSlot(PSP_CoreParameter().fileToStart, g_Config.iCurrentStateSlot, NULL);
		return false;
	}

And the corruption occurred within

	bool needReport = false;
	while (entryPos < entryEnd) {
	...
	}

anr2me · 2021-01-11T18:57:46Z

Okay i think i found the main source of corruption in sceKernelModule.cpp

static bool KernelImportModuleFuncs(PSPModule *module, u32 *firstImportStubAddr, bool reimporting) {
	...
	bool needReport = false;
	while (entryPos < entryEnd) {
		...
			for (int i = 0; i < entry->numVars; ++i) {
				u32 varRefsPtr = Memory::Read_U32(entry->varData + i * 8);
				u32 nid = Memory::Read_U32(entry->varData + i * 8 + 4);
				if (!Memory::IsValidAddress(varRefsPtr)) {
					WARN_LOG_REPORT(LOADER, "Bad relocation list address for nid %08x in %s", nid, modulename);
					continue;
				}

				u32_le *varRef = (u32_le *)Memory::GetPointer(varRefsPtr);
				int cnt = 0; // testing to count number of iteration
				// <-- Loading SaveState at this line won't get corruption
				for (; *varRef != 0; ++varRef) {
					var.nid = nid;
					var.stubAddr = (*varRef & 0x03FFFFFF) << 2;
					var.type = *varRef >> 26;
					module->ImportVar(var);
					cnt++;
				}
				// <-- Loading SaveState at this line will get corruption (cnt = 62)
				if (strcmp(module->nm.name, "rcp1") == 0 && module->memoryBlockSize == 0x003c0d00 && module->nm.status == 0) {
					SaveState::LoadSlot(PSP_CoreParameter().fileToStart, g_Config.iCurrentStateSlot, NULL);
					return false;
				}
			}
		...
	}
	...
}

May be the for-loop is getting out of bound? We may need to check the range/validity to prevent corrupting memory outside PSP's memory

Looks like these RCPM is the problematic module (the logs right before loading savestate where corruption will occurs)

anr2me · 2021-01-12T02:36:04Z

I tried to go deeper to find out which iteration causing the corruption, by using this:

				u32_le *varRef = (u32_le *)Memory::GetPointer(varRefsPtr);
				int cnt = 0; // testing to count number of iteration
				// <-- Loading SaveState at this line won't get corruption
				for (; *varRef != 0; ++varRef) {
					var.nid = nid;
					var.stubAddr = (*varRef & 0x03FFFFFF) << 2;
					var.type = *varRef >> 26;
					module->ImportVar(var);
					cnt++;
					if (cnt == 17 && strcmp(module->nm.name, "rcp1") == 0 && module->memoryBlockSize == 0x003c0d00 && module->nm.status == 0) {
						SaveState::LoadSlot(PSP_CoreParameter().fileToStart, g_Config.iCurrentStateSlot, NULL);
						return false;
					}
				}
				// <-- Loading SaveState at this line will get corruption (cnt = 62)

Apparently the 17th iteration is the first one causing the corruption, 16th is okay.

16th data:

varRefsPtr = 0x0936727c
varRef = 0x000002e228d772b8 {0x1a485f82}
var.moduleName = 0x000000ee0acfdf08 "RCPM"
var.nid = 0x4afb919a
var.stubAddr = 0x09217e08
var.type = 0x06 '\x6'

17th data:

varRefsPtr = 0x0936727c
varRef = 0x00000240890872bc {0x16485f98}
var.moduleName = 0x000000e3e57fe588 "RCPM"
var.nid = 0x4afb919a
var.stubAddr = 0x09217e60
var.type = 0x05 '\x5'

case R_MIPS_HI16:
exportAddress = 0x09001310
reloc.addr = 0x09217e60
reloc.data = 0x3c050000

Checked with Debugger, after LEVEL_20.prx fully loaded (not using savestate) the content of memory address [0x09217e60] is 0x3c050900, which is the same content when using savestate, so not sure why using savestate didn't have the corruption.

anr2me · 2021-01-12T12:56:17Z

Okay, i found the main issue and the fix (sort of)

The main issue is because of static vars inside WriteVarSymbol, probably the static vector contains addresses belonged to a different module sometimes (ie. even after the module unloaded)

static void WriteVarSymbol(u32 exportAddress, u32 relocAddress, u8 type, bool reverse = false)
{
	// We have to post-process the HI16 part, since it might be +1 or not depending on the LO16 value.
	static u32 lastHI16ExportAddress = 0;
	static std::vector<HI16RelocInfo> lastHI16Relocs;
	static bool lastHI16Processed = true;
	...
}

And my fix is by adding another argument to reset those static vars

static void WriteVarSymbol(u32 exportAddress, u32 relocAddress, u8 type, bool reverse = false, bool reset = false)
{
	// We have to post-process the HI16 part, since it might be +1 or not depending on the LO16 value.
	static u32 lastHI16ExportAddress = 0;
	static std::vector<HI16RelocInfo> lastHI16Relocs;
	static bool lastHI16Processed = true;

	if (reset) {
		lastHI16ExportAddress = 0;
		lastHI16Relocs.clear();
		lastHI16Processed = true;
		return;
	}
	...
}

And reset it during PSPModule::Cleanup() to removes reloc addresses related to the unloaded module from static vectors

void PSPModule::Cleanup() {
	MIPSAnalyst::ForgetFunctions(textStart, textEnd);

	loadedModules.erase(GetUID());

	for (auto it = exportedVars.begin(), end = exportedVars.end(); it != end; ++it) {
		UnexportVarSymbol(*it);
	}
	for (auto it = exportedFuncs.begin(), end = exportedFuncs.end(); it != end; ++it) {
		UnexportFuncSymbol(*it);
	}

	if (memoryBlockAddr != 0 && nm.text_addr != 0 && memoryBlockSize >= nm.data_size + nm.bss_size + nm.text_size) {
		DEBUG_LOG(LOADER, "Zeroing out module %s memory: %08x - %08x", nm.name, memoryBlockAddr, memoryBlockAddr + memoryBlockSize);
		for (u32 i = 0; i < (u32)(nm.text_size + 3); i += 4) {
			Memory::Write_U32(MIPS_MAKE_BREAK(1), nm.text_addr + i);
		}
		Memory::Memset(nm.text_addr + nm.text_size, -1, nm.data_size + nm.bss_size);
		WriteVarSymbol(0, 0, 0, false, true); // Reset static vars

		// Let's also invalidate, just to make sure it's cleared out for any future data.
		currentMIPS->InvalidateICache(memoryBlockAddr, memoryBlockSize);
	}
}

Since i'm not familiar with PSPModule, not sure if it's wise to reset the whole static vars instead of per module.
May be you guys have a better fix :)

unknownbrackets · 2021-01-12T13:04:39Z

I'm not sure I understand why you're loading a state mid module load - that doesn't seem like it'd ever work right.

HI/LO should always be paired. If you don't interrupt it, is it not paired at the end?

Perhaps we should change how that's managed, but it sounds so far like that's just an artifact of you loading a state at a random time (when normally states cannot be loaded)?

-[Unknown]

anr2me · 2021-01-12T13:18:59Z

Loading the state is just to pinpoint the location (something like a breakpoint) of the corruption, since it's hard to locate the code that cause the corruption due to the corruption resides within PPSSPP internal memory instead of PSP's memory (which is why bypassing the sceKernelLoadModule/sceKernelUnloadModule for LEVEL_20.PRX module using savestate won't trigger the corruption, Without savestate corruption always occurred and persist even after Exiting the Game & Relaunching the Game)

anr2me · 2021-01-12T13:29:47Z

@mojojojodojo
Here are the test build with this fix
Win32&64: https://www.dropbox.com/s/b2mxcsw3w6gb9wq/PPSSPP_1.10.3-testbuild_Win32x64.zip?dl=0
Android(ARMv7): https://www.dropbox.com/s/329379pz4i7g0eo/PPSSPP_1.10.3-testbuild_ARMv7.apk?dl=0

I do think it's not a wise thing to clear those static vars on every PSPModule::Cleanup since the cleanup is per module, so i won't be creating any PR for this.

anr2me · 2021-01-13T03:09:44Z

Okay this one seems to be "safer" fix

static void WriteVarSymbol(u32 exportAddress, u32 relocAddress, u8 type, bool reverse = false, u32 unloadBaseAddr = 0, u32 unloadSize = 0)
{
	// We have to post-process the HI16 part, since it might be +1 or not depending on the LO16 value.
	static u32 lastHI16ExportAddress = 0;
	static std::vector<HI16RelocInfo> lastHI16Relocs;
	static bool lastHI16Processed = true;

	// Remove reloc addresses pointing to unloaded module's memory block to avoid corrupting the data of the memory block's new owner
	// TODO: We still need to make sure these static vars to be reset when Exiting current game or when Launching the next game, to prevent corrupting the new game.
	if (unloadBaseAddr != 0) {
		u32 unloadEndAddr = unloadBaseAddr + unloadSize;
		lastHI16Relocs.erase(std::remove_if(lastHI16Relocs.begin(), lastHI16Relocs.end(), 
			[unloadBaseAddr, unloadEndAddr](HI16RelocInfo const& ri) {
				return (ri.addr >= unloadBaseAddr && ri.addr < unloadEndAddr);
			}),
			lastHI16Relocs.end());

		if (lastHI16Relocs.empty()) {
			lastHI16ExportAddress = 0;
			lastHI16Processed = true;
		}
		return;
	}
	...
}

And using it on PSPModule::Cleanup

void PSPModule::Cleanup() {
	MIPSAnalyst::ForgetFunctions(textStart, textEnd);

	loadedModules.erase(GetUID());

	for (auto it = exportedVars.begin(), end = exportedVars.end(); it != end; ++it) {
		UnexportVarSymbol(*it);
	}
	for (auto it = exportedFuncs.begin(), end = exportedFuncs.end(); it != end; ++it) {
		UnexportFuncSymbol(*it);
	}

	if (memoryBlockAddr != 0 && nm.text_addr != 0 && memoryBlockSize >= nm.data_size + nm.bss_size + nm.text_size) {
		DEBUG_LOG(LOADER, "Zeroing out module %s memory: %08x - %08x", nm.name, memoryBlockAddr, memoryBlockAddr + memoryBlockSize);
		for (u32 i = 0; i < (u32)(nm.text_size + 3); i += 4) {
			Memory::Write_U32(MIPS_MAKE_BREAK(1), nm.text_addr + i);
		}
		Memory::Memset(nm.text_addr + nm.text_size, -1, nm.data_size + nm.bss_size);

		// Remove unloaded reloc addresses from static vars
		WriteVarSymbol(0, 0, 0, false, memoryBlockAddr, memoryBlockSize); 

		// Let's also invalidate, just to make sure it's cleared out for any future data.
		currentMIPS->InvalidateICache(memoryBlockAddr, memoryBlockSize);
	}
}

So basically we need to removes reloc addresses pointing to unloaded module's memory block to avoid corrupting the data of the new owner of that memory block (ie. vertex/displaylist data)

But we still need to make sure all of these static vars to be reset when exiting a game, or when launching a game tho.
Not sure where is the best place to do that (ie. PSPModule::Cleanup didn't get triggered when exiting a game), otherwise the next game being launched will have a chance to be corrupted due to lingering reloc address on static local vars. (ie. The corruption on Ratchet & Clank will get worse when exiting the game after LEVEL_20.prx was loaded and relaunching the game, repeatedly)

I'm also unsure if we should use a simple if (memoryBlockAddr != 0) before removing reloc addresses in order to catch all possible corruption, or use the complex condition along with currentMIPS->InvalidateICache like that. (ie. if (memoryBlockAddr != 0 && nm.text_addr != 0 && memoryBlockSize >= nm.data_size + nm.bss_size + nm.text_size)).
One thing i know is that, using the same memory range with Memory::Memset for removal range won't fix the issue on Ratchet&Clank, so it must be the whole memory block just like currentMIPS->InvalidateICache.

PS: Personally, i think memory corruption should be put at a higher priority to be fixed, because it could lead to all kind of bugs (depends on where the corruption occurred) which will be hard to identifies whether it's really a bug or not.
In Ratchet&Clank case, it's causing graphical bug and crashes where many people will probably thinking it's graphical issue but isn't really a graphical bug.

ghost · 2021-01-13T15:01:57Z

So should i check the build still?
I thought this is a PSP hardware issue because it also appears there as well in certain maps and game modes.
It happens less there though.

hrydgard · 2021-01-13T15:59:08Z

Hm, interesting ...

anr2me · 2021-01-13T20:17:08Z

So should i check the build still?
I thought this is a PSP hardware issue because it also appears there as well in certain maps and game modes.
It happens less there though.

The corruption always occurred on PPSSPP when not using savestate, but didn't happened on JPCSP, so it's PPSSPP bug.

Have you tried playing this game on PPSSPP/JPCSP without using savestate?
Have you ever entered multiplayer map successfully without any graphical issue on PPSSPP?

PS: This bug can be reproduced with solo multiplayer, just need to create the room and start the mission.

ghost · 2021-01-13T21:22:41Z

Yeah I know about the bug on PPSSPP too well but there was 1 time when I played on JPCSP and the screen went black after i entered a game match (something similar happens on a PSP when a crash occur) it could be that the PSP user got the crash and it affected JPCSP because I played against a PSP user.
I think that the crash also occurs when you play only with PSP users but not sure.
I would try that build later and find out what happens tho on PPSSPP.
Someone I know tested it and confirmed it worked for him though.

unknownbrackets · 2021-01-16T18:03:24Z

Hm, the solution here looks a little messy. Let me explain the functionality here a bit.

PSP games use relocations to "import" variables from other modules. For example, the game might have this:

XXX0: lui v0, 0x0000
XXX4: addiu v0, v0, 0x0000
XXX8: lw v1, v0(4)

As-is, the above code would try to read from the invalid address 0x00000004. In a table in the module, though, it says:

Import from MyAmazingModule:
   CurrentHP, type HI16 at XXX0
   CurrentHP, type LO16 at XXX4.

These are required to be "paired" (HI16 then LO16, but you can have multiple of each iirc.) This tells the runtime linker (in this case PPSSPP, on a PSP the firmware) to write the address of that variable to those instructions.

When MyAmazingModule is loaded, it writes (links) them. When it's unloaded, it has to "unlink" them. In my example, it puts them back to 0x0000 (but it should just subtract, because those might've been offset if the variable was a large struct.)

These static vars are to keep track of the HI/LO pairs, but they aren't some long-term cache of all exported vars. The vector is cleared every time it sees a new export address, because then the paired chain is broken. It should not be necessary to clear a "range" of these or anything. That doesn't make sense.

To me it looks simply like this module imports one variable, and the HI/LO pair is getting confused because the export address is not changing.

-[Unknown]

If there is only one imported variable as a HI16/LO16, unloading the module wasn't properly reversing the link. See hrydgard#13104.

ghost · 2021-01-16T23:32:22Z

Tried the latest build with the module PR merged.
Now with "ignore bad memory access" disabled you will get this screen:

Even with it enabled you will get a "multiplayer memory card failed" or something message (the game saves multiplayer data on a seperate file).

anr2me · 2021-01-17T02:27:41Z

The memory card issue when selecting multiplayer profile is a separate issue with graphical glitch i think. It also happened on JPCSP sometime (but rare on JPCSP, while it's quite often on PPSSPP)

Disabling I/O on Thread seems to helped reducing the chance for this "multiplayer memory card failed" issue to happen, i haven't been getting this issue much lately on both US and EU version.
Using Simulate UMD also rarely got this issue.

Edit:
Apparently with PR #13927
I can no longer Select multiplayer profile, it's grayed out.
Trying to create a new profile didn't work either (it asked me to enter a password while the password button is grayed out too, so can't enter any password)

And i saw a lot of errors in the log:
US version:

EU version:

unknownbrackets · 2021-01-17T02:59:11Z

Is this reproducible in the demo at all?

If you find this part:

				u32_le *varRef = (u32_le *)Memory::GetPointer(varRefsPtr);
				for (; *varRef != 0; ++varRef) {
					var.nid = nid;
					var.stubAddr = (*varRef & 0x03FFFFFF) << 2;
					var.type = *varRef >> 26;
					module->ImportVar(var);
				}

And make it:

				u32_le *varRef = (u32_le *)Memory::GetPointer(varRefsPtr);
				for (; *varRef != 0; ++varRef) {
					var.nid = nid;
					var.stubAddr = (*varRef & 0x03FFFFFF) << 2;
					var.type = *varRef >> 26;
					WARN_LOG(LOADER, "Import for %08x, stub=%08x, type=%d", var.nid, var.stubAddr, var.type);
					module->ImportVar(var);
				}

What does it log?

-[Unknown]

anr2me · 2021-01-17T03:11:12Z

EU version:

Logs

08:13:668 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x350d4fc5] : 09367770
08:13:668 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x3bd5eb1d] : 09367778
08:13:668 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x8f3287d1] : 09367780
08:13:668 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09148260, type=5
08:13:668 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09148264, type=6
08:13:668 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09148264 for 09001310
08:13:668 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0920dc30, type=5
08:13:668 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0920dc34, type=6
08:13:668 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0920dc34 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0920dc94, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0920dc98, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0920dc98 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0920f114, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0920f118, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0920f118 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921798c, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217990, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09217990 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217c8c, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217c90, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09217c90 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217d0c, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217d10, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09217d10 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217e04, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217e08, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09217e08 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217e60, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09217e64, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09217e64 for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09219a18, type=5
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09219a1c, type=6
08:13:669 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09219a1c for 09001310
08:13:669 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921ab9c, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921aba0, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0921aba0 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921d214, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921d218, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0921d218 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921d524, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921d528, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0921d528 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921d944, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921d948, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0921d948 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921da5c, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921da60, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0921da60 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921ea2c, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0921ea30, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0921ea30 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092205a0, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092205a8, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 092205a8 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092208b0, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092208b4, type=6
08:13:670 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 092208b4 for 09001310
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092212b0, type=5
08:13:670 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092212b4, type=6
08:13:671 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 092212b4 for 09001310
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092217e0, type=5
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092217e4, type=6
08:13:671 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 092217e4 for 09001310
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09222894, type=5
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09222898, type=6
08:13:671 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09222898 for 09001310
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092231c8, type=5
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=092231cc, type=6
08:13:671 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 092231cc for 09001310
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09223440, type=5
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09223444, type=6
08:13:671 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09223444 for 09001310
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0922354c, type=5
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09223550, type=6
08:13:671 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09223550 for 09001310
08:13:671 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09223594, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09223598, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09223598 for 09001310
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09224c08, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09224c0c, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09224c0c for 09001310
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09225254, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09225258, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09225258 for 09001310
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09225cc0, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09225cc4, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09225cc4 for 09001310
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0922615c, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09226160, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09226160 for 09001310
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0922836c, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09228370, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09228370 for 09001310
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09228738, type=5
08:13:672 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0922873c, type=6
08:13:672 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0922873c for 09001310
08:13:672 level load & D[LOADER]: HLE\sceKernelModule.cpp:1070 -------------------------------------------------------------
08:14:261 level load & I[HLE]: HLE\ReplaceTables.cpp:1444 Replaced memcpy_jak at 09233858 with hash 0ffa5db8396d4274
08:14:261 level load & I[HLE]: HLE\ReplaceTables.cpp:1444 Replaced memmove at 09233898 with hash 5c0b3edc0e48852c
08:14:261 level load & I[HLE]: HLE\ReplaceTables.cpp:1444 Replaced memset_jak at 0923392c with hash eabb9c1b4f83d2b4
08:14:264 level load & I[LOADER]: HLE\sceKernelModule.cpp:1438 Exporting ent 0 named rcp1, 2 funcs, 3 vars, resident 09244fdc
08:14:265 level load & I[SCEMODULE]: HLE\sceKernelModule.cpp:2029 364=sceKernelLoadModule(name=disc0:/PSP_GAME/USRDIR/BIN/LEVEL_20.PRX,flag=00000000,(...))
08:14:265 level load & I[SCEKERNEL]: HLE\sceKernelThread.cpp:2204 sceKernelExitDeleteThread(0)

US version:

Logs

10:21:573 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0xf7a875ce] : 092e7350
10:21:573 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x6d0c1e4e] : 092e7358
10:21:573 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x350d4fc5] : 092e7360
10:21:573 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x3bd5eb1d] : 092e7368
10:21:573 level load & D[LOADER]: HLE\sceKernelModule.cpp:368 Importing [UNK: 0x8f3287d1] : 092e7370
10:21:573 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=090c7170, type=5
10:21:573 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=090c7174, type=6
10:21:573 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 090c7174 for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0918a888, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0918a88c, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0918a88c for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0918a8ec, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0918a8f0, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0918a8f0 for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0918bd38, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0918bd3c, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0918bd3c for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09194570, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09194574, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09194574 for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09194870, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09194874, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09194874 for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091948f0, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091948f4, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091948f4 for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091949e8, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091949ec, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091949ec for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09194a44, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09194a48, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09194a48 for 08fffd60
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09196584, type=5
10:21:574 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09196588, type=6
10:21:574 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09196588 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091971e4, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091971e8, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091971e8 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091997b0, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091997b4, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091997b4 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09199ac0, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09199ac4, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09199ac4 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09199ee0, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09199ee4, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09199ee4 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09199ff8, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=09199ffc, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 09199ffc for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919afc4, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919afc8, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919afc8 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919cb28, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919cb30, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919cb30 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919ce7c, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919ce80, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919ce80 for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919dd28, type=5
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919dd2c, type=6
10:21:575 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919dd2c for 08fffd60
10:21:575 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919e258, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919e25c, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919e25c for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919ed14, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919ed18, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919ed18 for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919f2b0, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919f2b4, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919f2b4 for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919f528, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919f52c, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919f52c for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919f654, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=0919f658, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 0919f658 for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a0cb4, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a0cb8, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091a0cb8 for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a12c8, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a12cc, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091a12cc for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a1d34, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a1d38, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091a1d38 for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a21d0, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a21d4, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091a21d4 for 08fffd60
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a4350, type=5
10:21:576 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a4354, type=6
10:21:576 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091a4354 for 08fffd60
10:21:577 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a4630, type=5
10:21:577 level load & W[LOADER]: HLE\sceKernelModule.cpp:1061 Import for 4afb919a, stub=091a4634, type=6
10:21:577 level load & E[LOADER]: HLE\sceKernelModule.cpp:636 LO16 without any HI16 variable import at 091a4634 for 08fffd60
10:21:577 level load & D[LOADER]: HLE\sceKernelModule.cpp:1070 -------------------------------------------------------------
10:22:024 level load & I[HLE]: HLE\ReplaceTables.cpp:1444 Replaced memcpy_jak at 091af7a0 with hash 0ffa5db8396d4274
10:22:024 level load & I[HLE]: HLE\ReplaceTables.cpp:1444 Replaced memmove at 091af7e0 with hash 5c0b3edc0e48852c
10:22:024 level load & I[HLE]: HLE\ReplaceTables.cpp:1444 Replaced memset_jak at 091af874 with hash eabb9c1b4f83d2b4
10:22:026 level load & I[LOADER]: HLE\sceKernelModule.cpp:1438 Exporting ent 0 named rcp1, 2 funcs, 3 vars, resident 091c0d30
10:22:027 level load & I[SCEMODULE]: HLE\sceKernelModule.cpp:2029 362=sceKernelLoadModule(name=disc0:/PSP_GAME/USRDIR/BIN/LEVEL_20.PRX,flag=00000000,(...))
10:22:027 level load & I[SCEKERNEL]: HLE\sceKernelThread.cpp:2204 sceKernelExitDeleteThread(0)

unknownbrackets · 2021-01-17T03:35:30Z

Ah, sorry, I only checked exporting for the state. The import state has to be higher up, where the list of imported vars are - see 8fe9bed.

-[Unknown]

anr2me · 2021-01-17T03:43:49Z

Okay it's working fine now on both US and EU version, no more profile issue and no more graphical glitches :D

Good works @unknownbrackets !

Btw @mojojojodojo as i remembered you also had an issue where your character spawned under the map or something and stuck there.
Is this still happening?

ghost · 2021-01-17T05:54:27Z

Ah yeah forgot to tell about the issue with the password.
At least this time when i fast forward the game during the multiplayer loading it wont have any issues.

Okay it's working fine now on both US and EU version, no more profile issue and no more graphical glitches :D

Good works @unknownbrackets !

Btw @mojojojodojo as i remembered you also had an issue where your character spawned under the map or something and stuck there.
Is this still happening?

I remembered this only happened in the EU version and it stopped hapenning after the new module commits.
I guess you can close this issue now.
I still think the multiplayer game mode is just buggy in general but everything seems to work alright now.

* add assets to ubuntu build artifact This enables us to run PPSSPPSDL in the ubuntu artifact zip as normal release. Can be uploaded to the automated ppsspp download pake. After downloading the artiact zip just chmod +x PPSSPPSDL and install libsdl2-dev libgl1-mesa-dev libglu1-mesa-dev. Then everything works fine :) * Add more error checking in SD storage detection See hrydgard#13827 * Add 3 games to ForceMax60FPS * Add game ID for russian version of Tron Evolution * Prevent access violation when running out of userMemory due to piling up AdhocMatching events. * Send AdhocMatching Data from within HLE whenever possible instead of through matchingEvent Thread. * Reducing AdhocMatching events delay to prevent matchingEvents from piling up on Lord of Arcana. * Try another method for getting SD card storage paths (env vars). See hrydgard#13827 * Add a fullscreen toggle button to the main screen (Windows-only for now) * Manually tighten up the layout a bit in the top right corner * Use the same logic of game setting for main menu full screen, add other system * Add a file picker (WIP) * Enable using the folder browser on Android to select SD card through a gross hack. Should help hrydgard#13827 Not yet using storage framework properly, just stealing the URI. * Improve some i18n things - reuse some translations - move some strings to a more suitable category I will adapt the lang .ini files accordingly. * jit: Fix conditional disable flags. * irjit: Correct flags for SetCtrlVFPUReg. Fixes hrydgard#13897. Caused the reg to be optimized out. * irjit: Fix mtv for INF4. * Windows: Handle fullscreen message consistently. This handles it the same way as SDL, etc. so that the new button on the main screen works again. * http: Prevent Windows header leak from HTTPClient. * UI: Cleanup Windows header in MainScreen.cpp. Better to have this come from System, probably. It's mainly for Windows anyway, to alert people their save data isn't permanent. * FixPGF for Euro Characters.(Balance emphasis) * GPU: Correct shader gen with weights as floats. For now, this supports the option. We should probably just move to everything being floats, but we already prefer software skinning. Fixes hrydgard#13903. * Fix copy/paste typo causing crash getting tempdirs if an env var had no value * Android: Fix headless and unittest build. * Build: Validate unittest/headless on Android. * Android: Add NEON/SSE funcs into Headless/UnitTest. * irjit: Add disable flag for simplify passes. * irjit: Update clobber flag on inst swap. Fixes IR in Persona 3. * PGF Re-Fixed Euro Characters * Enable BlockTransferAllowCreateFB for Gradius Collection * Update Template * Make sure we don't try to set a negative viewport size. Should help hrydgard#13921. * VK: Re-apply the old Adreno driver bug workaround. Fixes hrydgard#13910. Should likely fix issue hrydgard#13923 too. * Fix Stuck issue on some games (Dissidia 012, Full Auto 2, etc) when Failed to connect to Adhoc Server (faked success) * Module: Reverse a single HI16/LO16 pair correctly. If there is only one imported variable as a HI16/LO16, unloading the module wasn't properly reversing the link. See hrydgard#13104. * Module: Keep HI16/LO16 in a temp state object. This doesn't need to live any longer than the link or unlink, so let's just make that abundantly clear. * Remove re-test each month * Compat: Note that Gradius requires block transfer. Of course, there are many more that do, but might as well add since we're tracking it here. * Headless: Allow connecting the web debugger. * Module: Keep the state for each import. On exports, we iterate modules then imports. But on imports, we iterate the exports to find the module, so we need to keep the state around higher up. * SoftGPU: Fix sprite provoking vertex in fast path. It was right everywhere else. * Vulkan: Delete only created swapchain images. We do other null checks here, same reason. Create may have failed. * There's little reason to build at O3, so let's just not. Changing to O2. See hrydgard#13920 for a breakage report. * CMake fixes and new --ios-xcode ./b.sh command. Also enables stencil for the iOS backbuffer. Fixes the GPU test and will doubtlessly fix problems with running non-buffered (which you shouldn't do anyway though). Slim alternative to hrydgard#13766 with less risk to buildbots. * Adds two new tests to GPU driver test screen: Adreno shader logic test and flat shading The adreno test tests for the bug mentioned in hrydgard#13910. Very clear repro on Adreno 630, Pocophone F1. The flat shading test is an untested attempt at a repro of (will test that tomomorrow). * Add texture to flat shaded test. * Compat: Note that 3 LEGO games those are require Buffered rendering * More GPU test improvements * Fix the flat test. Unfortunately doesn't repro the bug :( * GL FB readback: Only use "inout" if we actually want to read from the fb. * Headless: Allow screenshot compare without backend. This makes not just graphics-enabled tests work in headless on softgpu, but also screenshot comparison ones. * Headless: Read expected file as a FileLoader. This makes it possible to run tests from network locations. * Headless: Allow PNGs and http:// for screenshot. * Headless: Disable http disk cache. * Headless: Simplify executing a ppdmp via headless. * Headless: Default to PNG for ppdmp tests. * GPU: Fix safe size checks when rect offscreen. * Vulkan: Prevent scaling shader leak. No need to recreate if they haven't changed. * Compat: Enable reinterpret for Kingdom Hearts. See hrydgard#11223. Should enable it for everything at some point. * Debugger: Add API to trigger buttons. * Debugger: Broadcast ctrl input events. This can be useful to trigger debugging functionality on button press. * Debugger: Include all press states for convenience. In case of a multi-button shortcut, which might be common for debugging. * Kernel: Adjust sceKernelGetThreadExitStatus timing. See hrydgard#13703. * PGF Fixed Bold & Italic property and camouflage the Font name. * Oops! I misstook uploading jpn0.pgf. * Resample all mp3 Fix hrydgard#5213 * Fix Russian (Cyrillic alphabet) on jpn0.pgf. * Some marks position fixed on jpn0.pgf * build fix * PPGe: Scale down by worst of window/internal res. See hrydgard#13958. * compat.ini: Add Split/Second to [ReinterpretFramebuffers]. See hrydgard#13957 * Plugins: Enable by default. * Resample only in 32000Hz * Fix Greek characters & Roman numbers & all balance on jpn0.pgf * Do PtpConnect internally during PtpOpen, since some games (ie. The Warriors) seems to do PtpSend immediately after PtpOpen without trying to PtpConnect first. * Fix returned error code on PtpSend and PtpRecv when socket is not connected yet. * OpenGL fragment shader gen: Fix precision inconsistency for v_color0/1. Probably won't fix anything, just want this in for, well, consistency. Noticed it debugging the iOS flat shading issues, but doesn't fix that. * Fix duplicate shader version in the flat shader test Unbreaks the flat shading test on Adreno (ended up in trying to link a #version 300 and a #version 320 shader together which it didn't like) * Io: Don't allow async close while async busy. See hrydgard#6582. * GE: Better naming of render passes for color reinterpret * GPU: Respect stencil write mask for 5551 buffers. If the mask is 0x7F on 5551, that's equivalent to allowing the clear entirely. See hrydgard#13391. * D3D9: Don't allow separate alpha clears. Doesn't seem like the color mask applies to clears. * Reporting: Expose CRC queue methods for other uses. This way UI can expose the CRC if needed. * Don't allow ForcedFirstConnect hack when using PtpConnect within PtpOpen to prevent returning result from blocking PtpConnect instead of result of PtpOpen. * sceMp3Init:Add layerBits and versionBits information * Add header information * GLES: Remove direct khrplatform.h header include. Shouldn't be needed anymore, was a hack for Nokia. See hrydgard#13978. * Mp3: Correct error handling for newer sdk versions. The 6.xx behavior might be important if a game relies on it to add data. * Mp3: Allow decode without pcm pointer. Just like other audio decoding, you're allowed to skip audio. Also prevents a crash if the mp3 is not yet inited. * Add back XCode TARGETED_DEVICE_FAMILY config line xcode warns that the value is deprecated or something, but maybe it still does something. Appears iPad support is broken right now. * Mp3: Always keep sample rate from original mp3. Our codec context is updated with the source sample rate, so this makes us not resample at all. Converting to stereo still seems correct. * Updated GameMode initial data sync, in case remote players aren't listening yet when sending initial data (fix Pocket Pool) * Mp3: Correct logging for init. * Remove duplicates from ThreadManForKernel * Vulkan: Add MMPX upscaling texture shader. See https://casual-effects.com/research/McGuire2021PixelArt/index.html * Vulkan: Allow tex shaders to specify a max scale. * Specify MaxScale=2 for the new MMPX texture scaling shader * Fix Greek characters ltn0~7.pgf * gitlab ci change requested by m4xw * FindFFmpeg: Fix a few issues 1. postproc now looks for postprocess.h (there is no postproc.h header). 2. pkg-config fallback condition now works (find_path/library set the variable to ${var}-NOTFOUND but it was checking for an empty string). * (.gitlab-ci.yml) Add windows-x64 target * Mpeg:Only allow firmware >= 3 for warmup Fix hrydgard#13996 * Try to build fix on non-windows * CMake: Add USE_UBSAN * CMake: Rename USE_ADDRESS_SANITIZER to USE_ASAN For consistency with USE_UBSAN * CMake: Fix UBSAN link error * Fix Russian characters ltn8~15.pgf * Fix alignment issues in ISOFileSystem Fixes hrydgard#14002 * jit: Make branch shift more obvious. And also not technically undefined behavior. * Fix connection issue on Dynasty Warriors (Shin Sangoku Musou) games when playing with more than 2 players. * Minimize the Adreno shader compiler bug repro test * Fix left shift of negative value in MIPSCodeUtils Fixes a benign UBSAN error to improve the signal-to-noise ratio of UBSAN errors. Fixes hrydgard#14015 * x64Emitter: Fix unaligned store UBSAN errors This compiles to the same assembly as before even without optimizations and avoids UB. https://godbolt.org/z/4G5edM While the UB here is benign, this improves signal-to-noise ratio of UBSAN errors. Fixes hrydgard#14005 * Fix logging flags 1. The logging flags were being ignored (-v, -d) 2. Adds a `--loglevel` argument. Useful when using the debug build for ASAN/UBSAN to hide extremely noisy debug messages. * Attempt to fix hrydgard#14022 * Fix Apple gpu detection * Core: Correct branch analysis truncation. * jit: Be very clear on sign extension. * Only force the log level if it set via an argv Follow-up to hrydgard#14019 * Io: Consistently use LE values of ISO entries. Better to be consistent across big endian and little endian, in case something was mastered wrong. * Vulkan: Fix image layout issues after compute shader uploads. We're already in GENERAL so probably not worth to transfer to DST just to do even more transfers due to the silliness of GenerateMip. I'm planning to rework the whole texture upload thing to be far more optimal with some kind of TextureUploadManager Fixes hrydgard#13987 * Mpeg:Only allow firmware >= 6 for warmup Fix blue screen in hrydgard#13146 * Ge: Improve some logging and memchecks. Explicitly trigger memchecks on readback. * Ge: Restore saved context when ending a list. Otherwise another list queued by a Head push could use the wrong context data. See hrydgard#13346. * Framedump test screen. Downloads a list of framedumps. * Add a new command in developer tools to list and load framedumps from framedump.ppsspp.org/repro/ Useful to make it easy to test GPU driver bugs etc, without having to use real games or copying files around. * Add checkbox to enable/disable driver bug workarounds. * Fix minor rendering glitch in PPSSPP's menus on iOS * Have the flat shading workaround obey the driver workarounds checkbox * Loaders: Prevent errors on 0 byte reads. Was happening when opening an http:// GE frame dump. * Core: Maintain frame dump disc ID in SFO. This way we won't generate a fake one later and use it for anything else. * vertexjit: Correct saved registers on x64. * Core: Assert debug stats remain positive. * vertexjit: Only save extra regs on x64. * Updated PdpStat and PtpStat * Update README.md for 1.11 * Address initial feedback by iota97 * List fixed games. Thanks sum2012 * More from unknown and sum2012 * More stuff in README.md * (.gitlab-ci.yml) Add linux-i686 and windows-i686 targets (+ prevent creation of 'null' file when building Windows libretro cores) * Fix possible lock issue during AdhocMatchingStart * Updated PdpStat to prevent rcv_sb_cc from exceeding the buffer size arg (since we use larger buffer size to prevent micro stutters or disconnection issue due to too many dropped packets with small buffer size). TODO: May need to improve it to be able to calculate the correct size if there are multiple datagram messages * UI: Correct developer tools test run. * Make a couple of UI animations refresh rate independent * Core: Reset state properly on CPU init failure. * Windows: Prevent crash on null symbol map. Happened during a double error scenario, but might as well check. * We don't really need to allocate a buffer when using MSG_TRUNC on recvfrom * Minor renaming * Moving hleDelayResult from internal function of SetSocketAlert to prevent waking up HLE-blocked thread * Fix possible race condition issue. * Fix jpn0.pgf characters position. * Debugger: Populate funcs if disassembly open early. * PPGe: Fallback to atlas text on alloc fail. * PPGe: Clear text allocations on shutdown. * Updated some Logs to help finding the location of the call to debug. * Removing hleDelayResult from internal adhoc functions to prevent waking up thread that supposed to be blocked by the outer HLE. * Run the link script * Run the link script, fixups * Update lang,pspautotests submodules * Do the title screen animation by accumulator instead, to avoid a long first frame breaking it. * Update version to 1.11 * PPGe: Decimate text images properly. Co-authored-by: kaiomatico <[email protected]> Co-authored-by: Henrik Rydgård <[email protected]> Co-authored-by: Panderner <[email protected]> Co-authored-by: ANR2ME <[email protected]> Co-authored-by: iota97 <[email protected]> Co-authored-by: vnctdj <[email protected]> Co-authored-by: Unknown W. Brackets <[email protected]> Co-authored-by: nassau-tk <[email protected]> Co-authored-by: sum2012 <[email protected]> Co-authored-by: AdamN <[email protected]> Co-authored-by: Florin9doi <[email protected]> Co-authored-by: Gleb Mazovetskiy <[email protected]> Co-authored-by: jdgleaver <[email protected]>

hrydgard added the Networking / adhoc label Jul 7, 2020

hrydgard added this to the Future milestone Jul 7, 2020

Double-0-seven7 mentioned this issue Oct 28, 2020

Dissidia 012 Ground Detection issues #13594

Open

hrydgard modified the milestones: Future, v1.12.0 Jan 12, 2021

hrydgard modified the milestones: v1.12.0, v1.11.0 Jan 13, 2021

unknownbrackets added a commit to unknownbrackets/ppsspp that referenced this issue Jan 16, 2021

Module: Reverse a single HI16/LO16 pair correctly.

17f3de6

If there is only one imported variable as a HI16/LO16, unloading the module wasn't properly reversing the link. See hrydgard#13104.

unknownbrackets mentioned this issue Jan 16, 2021

Module: Reverse a single HI16/LO16 pair correctly #13927

Merged

anr2me closed this as completed Jan 17, 2021

ghost mentioned this issue Jul 19, 2021

Games that won't reach the versus/ad-hoc menu in-game #14624

Open

6 tasks

Ratchet & Clank:Size Matters - Crash/Freeze on Ad-Hoc - 1.10.1 #13104

Ratchet & Clank:Size Matters - Crash/Freeze on Ad-Hoc - 1.10.1 #13104

Comments

ghost commented Jul 7, 2020

ghost commented Jul 7, 2020

ghost commented Jul 7, 2020

hrydgard commented Jul 7, 2020

ghost commented Jul 8, 2020

adenovan commented Jul 12, 2020 • edited Loading

ghost commented Jul 14, 2020

adenovan commented Jul 25, 2020

ghost commented Jul 25, 2020

anr2me commented Aug 1, 2020

ghost commented Aug 31, 2020

anr2me commented Sep 1, 2020 • edited Loading

zakilj3 commented Sep 1, 2020

ghost commented Sep 2, 2020

anr2me commented Sep 2, 2020

hrydgard commented Sep 2, 2020

Double-0-seven7 commented Sep 2, 2020

hrydgard commented Sep 2, 2020

anr2me commented Sep 3, 2020 • edited Loading

anr2me commented Sep 4, 2020

adenovan commented Sep 5, 2020

ghost commented Sep 18, 2020

ghost commented Sep 23, 2020

ghost commented Oct 24, 2020 • edited by ghost Loading

anr2me commented Nov 2, 2020 • edited Loading

anr2me commented Nov 2, 2020 • edited Loading

ghost commented Nov 2, 2020 • edited by ghost Loading

anr2me commented Nov 2, 2020

anr2me commented Jan 11, 2021 • edited Loading

anr2me commented Jan 11, 2021 • edited Loading

anr2me commented Jan 11, 2021 • edited Loading

anr2me commented Jan 12, 2021 • edited Loading

anr2me commented Jan 12, 2021 • edited Loading

unknownbrackets commented Jan 12, 2021

anr2me commented Jan 12, 2021 • edited Loading

anr2me commented Jan 12, 2021 • edited Loading

anr2me commented Jan 13, 2021 • edited Loading

ghost commented Jan 13, 2021 • edited by ghost Loading

hrydgard commented Jan 13, 2021

anr2me commented Jan 13, 2021 • edited Loading

ghost commented Jan 13, 2021 • edited by ghost Loading

unknownbrackets commented Jan 16, 2021

ghost commented Jan 16, 2021

anr2me commented Jan 17, 2021 • edited Loading

unknownbrackets commented Jan 17, 2021

anr2me commented Jan 17, 2021 • edited Loading

unknownbrackets commented Jan 17, 2021

anr2me commented Jan 17, 2021 • edited Loading

ghost commented Jan 17, 2021 • edited by ghost Loading

adenovan commented Jul 12, 2020 •

edited

Loading

anr2me commented Sep 1, 2020 •

edited

Loading

anr2me commented Sep 3, 2020 •

edited

Loading

ghost commented Oct 24, 2020 •

edited by ghost

Loading

anr2me commented Nov 2, 2020 •

edited

Loading

anr2me commented Nov 2, 2020 •

edited

Loading

ghost commented Nov 2, 2020 •

edited by ghost

Loading

anr2me commented Jan 11, 2021 •

edited

Loading

anr2me commented Jan 11, 2021 •

edited

Loading

anr2me commented Jan 11, 2021 •

edited

Loading

anr2me commented Jan 12, 2021 •

edited

Loading

anr2me commented Jan 12, 2021 •

edited

Loading

anr2me commented Jan 12, 2021 •

edited

Loading

anr2me commented Jan 12, 2021 •

edited

Loading

anr2me commented Jan 13, 2021 •

edited

Loading

ghost commented Jan 13, 2021 •

edited by ghost

Loading

anr2me commented Jan 13, 2021 •

edited

Loading

ghost commented Jan 13, 2021 •

edited by ghost

Loading

anr2me commented Jan 17, 2021 •

edited

Loading

anr2me commented Jan 17, 2021 •

edited

Loading

anr2me commented Jan 17, 2021 •

edited

Loading

ghost commented Jan 17, 2021 •

edited by ghost

Loading