Rpcs3: Vulkan/GL: Katamari Forever

Created on 2 Sep 2016  路  14Comments  路  Source: RPCS3/rpcs3

Katamari Forever (US, English - BLUS30336) boots to a black screen. This happens with Vulkan and OpenGL.

I noticed that if I wait 10 seconds or so the log would spew out

路U {PPU[0x7000000b] Thread (bnusCoreUpdateThread) [0x004b38b0]} cellSpurs TODO: cellSpursQueuePopBody

_extremely_ fast, creating hundreds of thousands entries in the log in only a few seconds. It seemed like that even after closing the game it'd still spew out that same entry, just nowhere near as fast.

RPCS3.log is found here. It's nearly 50 MBs in size, so here's a version with around 470k lines removed.

-PC specs: http://pcpartpicker.com/list/NpJ99W
-OS Win7 Ultimate 64bit

Unrelated, but I'd like to suggest making a guide on creating useful issue reports with a standardized issue report format, like the PCSX2 devs have.

Most helpful comment

Why? The bug where the log is spammed with literally hundreds of thousands of "TODO: cellSpursQueuePopBody" entries within seconds, eventually becoming so huge that most text editors can't open the log, is pretty bad.

This isn't a "this game won't boot, please fix" report, which is what the support forum there seems to be for.

All 14 comments

Please discuss this in http://www.emunewz.net/forum/forumdisplay.php?fid=162

However , i agreed to standardie the issue report format .

Why? The bug where the log is spammed with literally hundreds of thousands of "TODO: cellSpursQueuePopBody" entries within seconds, eventually becoming so huge that most text editors can't open the log, is pretty bad.

This isn't a "this game won't boot, please fix" report, which is what the support forum there seems to be for.

Should be a simple tweak to not write out duplicate lines and keep a running counter that eventually writes out TODO: cellSpursQueuePopBody (x8000000000000) or something.

@Two-Tone if you read it it says TODO = devs know its not implemented (hence this issue is useless), and also you should read this: http://www.emunewz.net/forum/showthread.php?tid=174352

The issue isn't the TODO, its the spamming of duplicate log lines till the disk is full

@paulsapps and if he would've read the beginners guide, he would know that there are tons of stuff unimplemented and needs LLE. (and with LLE theres no log spam.) and also you can always zip the log so it wouldn't be big. (also who would run a game for hoursdays until his HDD gets full because of the logging? lol)

It wasn't for hours or days

"extremely fast, creating hundreds of thousands entries in the log in only a few seconds."

Nearly 6 months later this bug still exists and yet this report is still closed.

To clarify: The bug is that when running Katamari Forever the log prints hundreds of thousands of duplicate entries every second or two. The game booting or not booting is completely unrelated.

I'd try to reproduce this bug with other games, but I don't own any other games.

Hopefully this drives the point home, but I ran KF for about 1 minute and ended up with a log file that was just under 1.7 gigabytes. How is that not a bug?

The report is invalid, "路U {PPU[0x7000000b] Thread (bnusCoreUpdateThread) [0x004b38b0]} cellSpurs TODO: cellSpursQueuePopBody" just means you didn't LLE libsre and libspurs_jq. Check out the quick start guide: https://rpcs3.net/quickstart

The game itself runs fine once rpcs3 is set up correctly.

The report isn't about the game not booting. I know the game boots. This is about the log file endlessly spewing out literal millions of duplicate entries.

That's because the game endlessly retries millions of times. Not a rpcs3 bug.

How? How is rpcs3 needlessly repeating millions of duplicate entries not a rpcs3 bug?

Because the log file reflects the game. If the game does a thing one million times so should the log file. This is intentional.

So then log it by keeping a running tally with timestamps? That'd solve the issue of millions of duplicates, it'd clean up the log file, and it'd be more efficient since the log would be _substantially_ smaller.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

xiangzhai picture xiangzhai  路  3Comments

altiereslima picture altiereslima  路  3Comments

Xcedf picture Xcedf  路  3Comments

JohnGodgames picture JohnGodgames  路  3Comments

Nezarn picture Nezarn  路  3Comments