Pac-Man World 3

[Stevec]

yeah,here's a log of what happens when it stops - this is on 9.8.551 -g253e11a 32bit build

[[Unknown]]

Well, it's definitely running garbage data in the GE. Question is: why?

A debug log would help.

-[Unknown]

[sum2012]

v0.9.8-561-g2b50fc debug log:

(05-01-2014 01:38 AM)[Unknown] Wrote:  Well, it's definitely running garbage data in the GE. Question is: why?

A debug log would help.

-[Unknown]

[[Unknown]]

Well, that's interesting.

47:23:835 user_main D[SCEGE]: HLE\sceGe.cpp:427 sceGeListEnQueue(addr=49ef2700, stall=49ef2700, cbid=00000000, param=08b76820)

This seems reasonable. It enqueues (using uncached pointers) a list at stall. The operation is normal, uncached is a bit odd.

47:23:835 user_main D[SCEGE]: HLE\sceGe.cpp:473 sceGeListUpdateStallAddr(dlid=889192482, stalladdr=49ef271c)

Another very sane thing, it updated the list stall address (uncached again) +0x1c.

47:23:835 user_main D[SCEGE]: GLES\Framebuffer.cpp:611 viewport : 480x272, region : 480x272 , scissor: 480x272, stride: 512, 1
47:23:835 user_main D[SCEGE]: GLES\Framebuffer.cpp:858 Switching render target to FBO for 00088000: 480 x 272 x 3
47:23:844 user_main I[G3D]: GLES\ShaderManager.cpp:146 Linked shader: vs 58 fs 37
47:23:844 user_main W[G3D]: GLES\GLES_GPU.cpp:1823 Unknown GE command : b6fc3f48
47:23:844 user_main W[G3D]: GLES\GLES_GPU.cpp:1756 Unsupported Vertex Screen Coordinate Y : 050000
47:23:844 user_main W[G3D]: GLES\GLES_GPU.cpp:1761 Unsupported Vertex Screen Coordinate Z : 80bcad
...
47:23:862 user_main W[G3D]: GLES\GLES_GPU.cpp:1766 Unsupported Vertex Texture Coordinate S : 6cbd93
47:23:862 user_main W[G3D]: GLES\GLES_GPU.cpp:1786 Unsupported Vertex Alpha and Primitive : b20000
47:23:862 user_main W[G3D]: GLES\GLES_GPU.cpp:1066 Unsupported alphatest mask: 00
47:23:862 user_main W[G3D]: GLES\GLES_GPU.cpp:1781 Unsupported Vertex Color Value : b1bf28
47:23:862 user_main E[G3D]: GLES\GLES_GPU.cpp:896 Bad bounding box data: bd0000

That's already more than 7 (0x1c/4) cmds. Probably none of these are valid - but why didn't it stop? All the addresses are masked with 0x0FFFFFFF, so it *should* have.

Can you try the following change, find GPU/GLES/GPUCommon.cpp:
const bool useFastRunLoop = !dumpThisFrame_ && !useDebugger;

Add before:
dumpThisFrame_ = true;

Then log again. I'm specifically interested in the same point, that should make it print out the commands it's executing.

For a bit more though, actually, find this:
NOTICE_LOG(G3D, "%s", temp);

And replace with:

NOTICE_LOG(G3D, "%08x: %s", list.pc, temp);

That will also print out the addresses for extra clarity.

-[Unknown]

[sum2012]

@Unknown
It is all the change of debug log (I used save status)
https://drive.google.com/file/d/0B3OaSde...sp=sharing

[[Unknown]]

08c668b4: 0a6bc17f: CMD CALL - 08c668b4 to 096bc17f, ret=08c668b8

Hmm, that won't work correctly. That's where the wheels fall off the bus.

Does it help anything to change this, GPUCommon.cpp:

void GPUCommon::Execute_Call(u32 op, u32 diff) {
easy_guard guard(listLock);

// Saint Seiya needs correct support for relative calls.
const u32 retval = currentList->pc + 4;
const u32 data = op & 0x00FFFFFF;
const u32 target = gstate_c.getRelativeAddress(data);

To:

void GPUCommon::Execute_Call(u32 op, u32 diff) {
easy_guard guard(listLock);

// Saint Seiya needs correct support for relative calls.
const u32 retval = currentList->pc + 4;
const u32 data = op & 0x00FFFFFF;
const u32 target = gstate_c.getRelativeAddress(data) & ~3;

But, not sure. Seems like that command is wrong.

-[Unknown]

[sum2012]

@Unknown Well done, fixed it.
Debug log:
https://drive.google.com/file/d/0B3OaSde...sp=sharing
Only you can fix the command

[sum2012]

v0.9.8-602-g1bed54b
The crash solved,
can move to playable

[vnctdj]

Moved