Me And My Katamari - missing Katamari in hand, can't pass rename screen

[zaranrapu]

Soft

OpenGL

Direct3D9

consol
https://youtu.be/0HjR7Y8xh9s?t=1m58s

I want you to correct an expression of the distant view.

[zaranrapu]

Test play emu version PPSSPP v1.0.1(x86 and x64).

[daniel229]

30:29:629 user_main    W[G3D]: GLES\TextureCache.cpp:1692 Decoding texture from VRAM mirror at 04288000 swizzle=0

GE debugger

more tabs
https://gist.github.com/daniel229/ad7f2bff983b8406f4dd

[unknownbrackets]

Oh, yeah, so this is a mirror thing. Maybe we flip the swizzle bit when it does that?

-[Unknown]

[unknownbrackets]

The texture type shows in the texture tab of the GE debugger. Should be that same 0x42... address.

Does it ever draw to 04088000? I guess it's also possible it's depth. What depth does it use? That's on the Settings tab, but it might be during a different draw.

-[Unknown]

[daniel229]

Found them.I don't see any 04088000 during step tex.
Texture L0 addr 04288000, w=512
Depth test pass if src >= dst

[unknownbrackets]

Well, I'm interested in the texture type. In this screenshot:
https://cloud.githubusercontent.com/assets/3481559/3440997/d4308cb6-00fe-11e4-8ae1-2b38002cf65c.png

It says "Tex format: CLUT8". The reason is because unswizzling is applied a bit differently in each texture format.

And for the depth, I'm wondering if any draw uses that address as depth. It would be in the "Creating FBO" log lines, or also here:
https://cloud.githubusercontent.com/assets/3481559/3440558/b4e88eb8-00f8-11e4-8962-2bb1e625d14f.png

At the top it says "Depthbuffer: 00088000, w=512". In that game, it is using 04088000 as a depth buffer, and so if that game were trying to use 04288000 as a texture, it would actually be trying to use the depth. More commonly depth is accessed as 04688000, though, because that deswizzles depth correctly.

-[Unknown]

[daniel229]

I don't see any Creating FBO during the glitch screen,Pressing ESc and back,It shows up these

49:45:257 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1856 Destroying FBO for 00044000 : 480 x 272 x 1
49:45:272 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1856 Destroying FBO for 00000000 : 480 x 272 x 1
49:45:324 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 00044000 : 480 x 272 x 1
49:45:358 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 00000000 : 480 x 272 x 1

[unknownbrackets]

Oh sorry, for some reason I had thought it showed the depth. That's only when two buffers use the same depth, though. It should still show during the majority of draws in the Settings tab.

-[Unknown]

[daniel229]

"Depthbuffer 00088000, w=512" is always there.

[unknownbrackets]

Aha, so it's trying to do a depth buffer.

Since it's reading the wrong mirror, it should be getting a picture of depth like this:
http://hitmen.c02.at/files/yapspd/psp_doc/chap10.html#sec10.2.2

That means it's probably either doing tricks with the UVs (which will be annoying to support), or doesn't care about the depth actually, and just about the average value across. Hmm.

-[Unknown]

[zaranrapu]

OpenGL
Read Framebuffers to Memory (CPU)

[VIRGINKLM]

The issue is a duplicate of #6411
I guess It's hard to debug this game it has a couple of bugs that seem puzzling.
So to get things in order:

BUG 1:
(Depth buffer issue?)The game seems to try to render that texture (which I heavily doubt it should originally look like this) which simply ends up looking like the background of the stage or take the basic color of the ambience lighting of the stage (it can vary from white [broad daylight] to orage [afternoon] to blue [night]):

Things get really nasty on stages that you get really big because the bug renders infront of you obstructing view of completely everything.

BUG 2:

I think it's related/same bug as the first one (I may be wrong). After completing a stage, "The King" will have in his hand a texture that consists of your in-game Katamari. That texture gets corrupted.

BUG 3:
There is an issue that causes hanging if you try to name/rename your island in the game, after you have finished naming your island and hit "FINISHED" the emulator will stay forever idle with only this line popping up at the moment you hit "FINISHED".

If you savestate though just after you hit "FINISHED", exit the game, switch to software rendering, re-load the game, load the savestate you just did, it will let you get past that issue.
What is more intresting is that as long as you don't exit the emulator/reload the save you will be able to rename your island without the emulator hanging and having to do that trick again.

[VIRGINKLM]

According to #6261 the Island rename bug gets fixed by changing Rendering Mode to Read framebuffer to memory, bypasses the hang.

[unknownbrackets]

It may be that that ends up zeroing out some vram, that the game depends accidentally to be zeroed, and that's why it works. Or it might be that just hides the issue. It's hard to tell.

-[Unknown]

[VIRGINKLM]

Is there any way I could help finding the issue? I'm in the process of learning MIPS/PSP syscall basics.

[unknownbrackets]

Well, what I want to know is what's reading from those areas that makes it hang. How can it "tell" that the memory wasn't overwritten?

It could be it's enqueuing a displaylist there, or any number of things.

-[Unknown]

[VIRGINKLM]

I don't think that it reads something, it feels more like it doesn't let it store something that the game expects to read and the game in it's turn will not move on until it reads what it expects to read.

I could be terribly wrong but let me check step by step.

[unknownbrackets]

But even if it won't move until it expects to read, where is it doing this read? Is it reading the entire framebuffer, or just certain areas of it? What I want to understand is, what specifically is the game expecting to happen?

For example, it could indeed be that it waits for an image to appear. What does it define as an image? Do the pixels have to be exactly accurate? If there's latency before it appears in ram, is that still okay?

-[Unknown]

[VIRGINKLM]

My wild guess -if I get what's going on- is that it creates an FBO with a texture/image using a pgf font with the name you just gave to the island. For some reason, it won't get created/read unless you change Render Mode.(Maybe pgf fonts are not visible to the emulator for FBO effects until a change of Render Mode?) But the fact that it goes further after changing mode might not be the right thing to do, it may just bypass a bug. Could it be that that emulator creates an FBO with a wrong size and the game has zero tolerance to incorrect FBO sizes? It could also explain the bug I posted above with the corrupted texture of King holding your ingame Katamari. I will keep on investigating that.

[unknownbrackets]

PGF fonts are rendered to memory, and are directly visible to everything in memory. They can, however, be textured onto a framebuffer. This won't be immediately visible in the framebuffer VRAM.

Changing "render mode" isn't necessarily a thing. To explain what happens:

1. We estimate a size of the framebuffer. Usually this estimate is wrong; PSP games draw with a canvas that has no height (it's bottomless), but we have to "guess" a height.
2. If you don't use "read framebuffer to memory", then only detected block transfers will download the framebuffer data into RAM. Otherwise, it will stay ONLY on your OpenGL video card memory. The game will never see it unless we detect a block transfer.
3. If you DO use "read framebuffer to memory", PPSSPP will corrupt game memory. Some games crash. This is because the height is wrong. Even if we got the height right, performance will tank because we are downloading the framebuffer from your OpenGL video card memory every frame. This is a very slow operation in OpenGL.

Please note: the PSP allowed games DIRECT and FAST access to the PSP video card memory. PPSSPP does NOT have direct OR fast access to OpenGL (or Direct3D) video card memory. The equivalent to what the PSP does is what software rendering does; it writes to memory immediately. There's no heights or anything, it's just writing bytes.

So "read framebuffers to memory" was an ATTEMPT at compromising: at the end of every frame, it downloads every framebuffer into RAM. It's a bad hack and causes glitches, and there's almost no way to fix those glitches. I want to remove the feature PERMANENTLY so that it is no longer possible to select "read framebuffers to memory."

The only way the game can "tell" if we are in "read framebuffers to memory" mode is if it is READING from emulated PSP video card memory in some way. If it's doing that, I want to know WHERE it is reading form that memory, and HOW. The memory addresses will be 0x?4??????. That indicates PSP video card memory.

The sizes of FBOs aren't different between "read framebuffers to memory" and other rendering modes. However, entering the menu and changing any setting will cause the framebuffers to be recreated, which may in some cases alter their size.

-[Unknown]

[LunaMoo]

The island renaming "hang" pretty much happens since the game reads something from vram starting at 04154000 - which doesn't show in GE debugger, but I would guess should be a single or double color texture - and the check for it fails.

In buffered rendering the check wants "FFF9C977" which should repeat 0x40 times before passing, that pattern shows every second line (as "00F9C977", but FF000000 is added before check ~ assume it's alpha) and stops repeating too early which causes the code to end up in an infinite loop.
When I check with "read to memory" it checks the same way for a different pattern "FF73CEE2" which is actually copied when finishing renaming and since that pattern repeats every line and enough number of times, code can successfully finish.

Both might actually be wrong since the game does check only every second word which kind of fits what's stored in vram when using buffered mode ~ well it would if it wasn't too short. Game works just fine with no visual difference doesn't matter what texture or whatever it is that it checks so a cwc hack works pretty well here.

Probably useless, but just to visualize words above here's a small screenshot of this check:

[unknownbrackets]

Hmm. Okay, this could mean that it's expecting to read stencil 0xFF from the framebuffer, but not.

If you set a write breakpoint on 0x04154000, does it hit? Also, if you pause and unpause, does it show any FBOs? They might likely show at 0015400 in the log.

-[Unknown]

[unknownbrackets]

So, the content initially is from the opening video - either before the game start, or after you start a new game. They both write to 0x04110000, for 0x88000 bytes - so until 0x04198000. That covers the first part of 0x04154000.

After I beat the practice level though, it created an FBO:

Creating FBO for 00154000 : 256 x 256 x 3

If I pause and resume, the FBO is not recreated, so it probably was either being textured from or not used. There was no obvious reading from the FBO either.

It draws first black, and then in the center of the 256x256, it draws your sphere/object/thing. If I turn off framebuffer decimation, he's holding it in his hand. Basically, it's not redrawing it every frame, so we throw away the FBO.

Everything works fine if I force just that framebuffer to be downloaded:

    hackForce04154000Download_ = gameId == "NPJH50631" || gameId == "NPJH50372" || gameId == "NPJH90164" || gameId == "NPJH50515";
    if (gameId == "ULUS10094") {
        hackForce04154000Download_ = true;
    }

I don't think that's really a solution, though.

So, hmm. The problem is, it doesn't live long enough for us to detect that it ought to be saved.

-[Unknown]

[LunaMoo]

Appears you found everything yourself so it's fine I guess, write breakpoint for me triggers at:

~ seems pretty wrong.

Edit: oh and cool, tested the force download hack and aside from renaming island bug, it also fixes result screen katamari glitch and camera mode. Pretty much everything except the in-game background effect so that would kind of point that it's a separate issue.

In case there'll be no other solution but this hack ~ here's a list of all id's ~ http://www.gamefaqs.com/psp/929985-me-and-my-katamari/data

[unknownbrackets]

Yeah, I had forgotten that I picked up this game a little while ago since I wanted to see what it was doing on the selection screen and saw it for pretty cheap.

It's triggering there because the operation that wrote also rescheduled. If you go to the PC in the log it'll show the actual trigger.

-[Unknown]

[unknownbrackets]

When it creates the framebuffer... region, scissor, and viewport all agree that it's 256x256. The stride also matches at 256.

More importantly, it's in throughmode/clearmode, and there are 16 verts. Unfortunately, the clear it draws is 480x272 (d'oh.) But, we could have a "safeHeight" of 256 on this buffer.

Maybe then, at least, we could store it to RAM on decimate. Better than whitelisting the game id? What do you think, @hrydgard?

The depth buffer is, crazy enough, at 0x04330000 (swizzled 0x04130000.) Honestly, I hadn't even thought of that as an option before. Rendering to swizzled RAM. What does it mean?

-[Unknown]

[LunaMoo]

^ I might be just unlucky, so let's leave this at it.:3

But wow ~ soo many old issues move forward recently. O.o

[hrydgard]

@unknownbrackets as the swizzling is the same for write/read presumably, it probably only matters for the layout the depth buffer seems to be in when you read it using the CPU. It is pretty odd though.

I think that probably makes sense to do. Though the game doing a clear of 480x272 is a pretty clear sign that it considers that framebuffer to be of that size. So maybe should do the thing I did in the failed vulkan buffered rendering branch where we don't make the framebuffer update until after we know it's a detected clear...

[unknownbrackets]

Well, it goes ahead and clearly draws to it and I think uses it as a 256x256. The stride is 256, so really a 480x anything clear doesn't make sense. It's clearing pixels twice, and clearing (256 * 272 + (480 - 256)) * 4 total pixels, which is an overrun by 17,280 bytes from the presumably correct size.

I think the clear is just a bug in the game.

But anyway, it centers your sphere thing in the middle of the 256x256 surface so it's definitely de facto 256x256, besides being de jure 256x256. It's just the clear that doesn't agree. It'd be nice if they all lined up...

But we could take the minimum height in a scenario where everything lines up and the clear is larger. We'd at least know for sure we can write that much VRAM, I suppose? Just don't want to cause crashes by writing too far.... I guess it can still happen even with this.

-[Unknown]

[hrydgard]

Hm, I suppose if the scissor region boxes it into 256x256, then the clear will draw as 256x256. Or, I don't remember - does the scissor region constrain clearmode? It should, right?

[unknownbrackets]

Hmm, well, it's also through. I guess it's worth testing. I suppose it should, yeah. So then, right, it does not clear outside the 256x256.

Anyway, since it clears, we can safely assume it would be safe to write the entire 256x256 to memory. I think that's the flag. If it doesn't clear, then it's not safe.

-[Unknown]

[unknownbrackets]

Note: we have #6411 for the background / depth issues.

-[Unknown]

[LunaMoo]

#8757 fixes katamari on the result screen, however still gets stuck on renaming screen also photography mode looks fixed when taking pictures, but saving them to album doesn't work and instead shows a glitched scene from the intro for every picture taken.

I forgot to test how that last part earlier with the hack, but doing it now seems it worked, not perfectly as when opening album it still showed 1 of the 3 pictures glitched, but closing/re-opening album made all 3 pictures appear.

[unknownbrackets]

Can you give me steps to reproduce? I didn't check saving to album (actually I didn't even know about that feature), but the naming screen worked fine for me.

-[Unknown]

[unknownbrackets]

Ah, I see, if I reset and load a saved game, it can't rename. That's odd.... what's supposed to write the mem then, hmmm...

-[Unknown]

[unknownbrackets]

So, it does draw something there right when you rename too, but since it doesn't decimate, it only works if you cancel first and then rename (which I think might've been the first thing I did.)

Anyway, at this point the framebuffer exists, so it's a matter of detecting the read.

-[Unknown]

[LunaMoo]

About photo mode and album I think it only unlocks after finishing the game, here's my save
http://www.mediafire.com/download/t7on93bm73jl9xr/ULES00339000.7z
I think you have US, not sure if renaming savedata will work, if not try some 100% from here http://www.gamefaqs.com/psp/929985-me-and-my-katamari/saves

With photo mode available, when you're walking on the island you can press select to make up to 3 pictures, then walk towards this book:

and open it with X.