-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Freak Out - Extreme Freeride uneven fps #500
Comments
It seems to be expecting 0x446B00 more bytes to be free, which is quite a few. It would work if the ELF were much smaller, e.g. 0xC0C00. Clearly the module start info helped this, or it would've been even worse. Maybe it's because of something wrong in -[Unknown] |
Dragon Ball Z Tenkaichi Tag Team , similar issue i think 31:54:201 HLE\sceKernelMemory.cpp:508 E[HLE]: UNIMPL sceKernelPrintf(08a76c4c, 08a76c18, 00000000, 00000000) |
Sounds like it's still not booting but the errors have changed: A more up to date log would help. -[Unknown] |
here is an up to date log 36:14:768 user_main I[HLE]: HLE\sceKernelMemory.cpp:642 sceKernelPrintf: libc:_getmodreent: no reent structure found 36:16:269 user_main I[HLE]: HLE\sceKernel.cpp:461 KO 272: Thread "idle0": pc= 08000000 sp= 083fff00 READY (wt=0 wid=0 wv= 00000000 ) |
v0.8.1-1173-ge03acc4 05:22:793 EmuThread.cpp:122 I[BOOT]: Done. |
Any change? Is it still failing to allocate memory? -[Unknown] |
no change |
Does it work any better now with module stop handled better? Or with PSP Model set to 2000/3000? An updated log would be useful. -[Unknown] |
Tested with latest build. Game boots fine, but on player select screen game goes slow 35/35 FPS and music background plays very rare. In game FPS is normal but I get a force close after first race. I have to test it a bit more but it seems to be caused by block transfer option. P.S.: @unknownbrackets confirmed. With block transfer disable I manage to continue next level. |
Has this improved at all with the latest git build, and with block transfers still enabled? -[Unknown] |
@unknownbrackets tested with latest build. Game does not crash anymore, but sound bug is still present. |
It's still showing the unusual fps also, right? -[Unknown] |
@unknownbrackets yes. But even during game music is choppy. |
Tested with latest build. Same status. |
Tested with latest build. Sounds seems to get an improvement, but unusual fps are still there. |
Hm. Now that the memory allocations aren't failing (it sounds like), I wonder if the FPS is because of sync operations or something. Could you take a screenshot with the debug stats enabled when FPS is uneven? Anyone have this and a PSP with CFW to compare the FPS it should be? Wondering if it ought to be 30 or ought to be 60. -[Unknown] |
Even the game Hits 60 fps the audio still crackling. |
The audio in this game sounds bad, but it's not an FPS problem. It seems to convert the mono song to S32 at 08C1C884. Then, it mixes that with a zero S16 buffer at 08C11DA8 and writes to another S16 buffer. At 08C13FC8, it sends it to Output2. At a high level, that all seems right. What goes awry (and causes the static) is that it processes the buffers in a strange order:
It's really just playing a simple PCM S16 mono song, though it's doing left/right audio adjustments (I think to make it sound like the audio source is moving.) In the last part, it goes from 096ef1d0 -> 08d07280 ultimately, for 0x100 samples (0x400 total bytes, since it's stereo.) Then it sends samples (from the same place, 08d07280) to sceAudioOutput2OutputBlocking, which immediately enqueues 0x200 samples (0x800 bytes.) That's more than it actually mixed. Next up (after returning from the blocking function), it converts another 0x100 samples (0x400 bytes)... and puts them at 08d07680. 08d07680 is actually 08d07280 + 0x400. Clearly, it's trying to fill in the last 0x100 samples of the last send. A quick hack to delay the last 0x100 samples and actually enqueue them from RAM on the next call of sceAudioOutput2OutputBlocking (which isn't correct but was quick) fixes it, so that confirms the problem. I'm not quite sure if this is a bug in the game, but it does seem likely the PSP firmware just reads directly off RAM... I think the blocking func only blocks if there's content already in the queue. -[Unknown] |
Can you still reproduce this issue? |
Tested in latest Windows build. Same issues. |
Why close? Did you get confirmation that it's fixed? @benderscruffy |
The behavior I described above is definitely not changed:
We could maybe read off RAM more directly here, copying blocks using a timing event into the queue at a smaller rate. There'd probably be a perf impact, but it could be a compat option (I generally don't like those, but most games are well-behaved here, so it'd be a reasonable option in this case, I think.) -[Unknown] |
Tested in latest build. Same issues. |
just keeps on printing out this error
42:14:346 HLE\sceKernelMemory.cpp:503 E[HLE]: UNIMPL sceKernelPrintf(08cf08c8, 08cf0898, 00000112, 00000048)
42:14:346 HLE\sceKernelMemory.cpp:504 E[HLE]: libc:%s: no reent structure found
http://pastebin.com/b89ZdZvE
The text was updated successfully, but these errors were encountered: