Using GE Debugger to find Texture Coords

[Calivi]

Hi there, I am new to this forum. I would like to thank you a lot for this awesome emulator. With the addition of the debugger, it made reverse engineering PSP games a piece of cake .

I have some questions regarding the GE Debugger. I am currently trying to find where my game stores on-screen coordinates of a particular texture, in order to change them, and move this texture on another place, on screen .

As far as I understand, in this game, every texture's on-screen coordinates get computed by (matrix?) transformations, since the vertices (before the transform) are always the same: (0,0,0)(40,0,0)(0,40,0)(40,40,0).

I would like to ask what is the easier way to find this transformation (matrix), maybe in RAM at least, so I can backtrack the code, and find where it comes from, in the original game data.
Or, maybef I am completely wrong, and I should follows a completely different approach.

Thanks for your help. Keep the good work going!

[Henrik]

Well sometimes there's a matrix (the game could use world, view or proj or any combination) sometimes there isn't. In "through mode", no transform is applied. The game can also move things around using the offset or viewport registers, or even by block memory copies. You need to figure out what the game is really doing ...

[[Unknown]]

Yuo really want to see where it's writing the display list data. Look at the display list pc and the display list commands before the break. Then check what's writing to that.

-[Unknown]

[Calivi]

I see. So, I think the best starting point would be to check the display list and see where the matrix is stored. Thus, I suppose that the display list is stored in user RAM, like the old PSX did, and then I can use plain memory write breakpoints in the CPU debugger.

I will let you know how far I get!

---

Ok, I think I was completely wrong. I read some documentation on sceGuDrawArray and, looking to the GE debugger, the games is actually constructing the rectangular area, with a TRIANGLE_STRIP. That is, it is drawing 4 triangles, where the first has vertices (0,0,0)(40,0,0)(0,40,0).
I hope I am not mistaken. I already found where these vertices are loaded into RAM for the very first time. But now, any other write breakpoint to this RAM location will not trigger.

Is it maybe because they are loaded from disc through DMA?

[Henrik]

Yeah, it could very well be that we forgot to hook up some mechanism to the write breakpoints...

[[Unknown]]

Well, there are ways that HLE can write to RAM still that don't trigger. But, also, games do not always reuse the same addresses for displaylists (annoyingly.) Even more, if it's using the same texture coordinates, it may not be changing the displaylist at all. It could run another displaylist, somewhere else, to update the matrix registers, or it can even use HLE to provide the matrix (sceGeSetMtx().)

For example, Final Fantasy 4 iirc doesn't draw in the way you might expect, vertex wise. It draws always to the same place, but translates the world matrix for each tile. Very "the spoon doesn't bend." In the GE debugger you can see the matrices, so you can see if they change each frame or prim.

-[Unknown]

[Calivi]

My game is FF4, indeed. And, as I already noticed, it moves and stretches textures on screen, just with the world matrix, leaving the vertices untouched.

[Calivi]

Hi everyone!
It has been a while. I just wanted to let you know I managed to find the on screen texture coordinates.

The game actually was using floating point values to fill the World 2 matrix, which is then used to ransform the fixed vector that I was talking about in the previous post. With a bit of backtrace of the code, I managed to find out that these values are actually integers that get converted to floating point with the pair mtc1/cvt.s.w.

Thank you very much for this wonderful emulator and especially to Kingcom for this awesome debugger!