GE debugger: Allow displaying two tabs at once, separate DL view

[hrydgard]

Should really make a new cross platform GE debugger somehow, but in the meantime, this.

This lets you show two tabs at the same time, and also moves the display list view out of the tabs. Additionally it reorders things so that parameters critical for debugging of tricky framebuffer texturing effects are at the top (this is going to be the most common use going forward, it seems).

See how the core texturing and framebuffer parameters are visible at the same time in the screenshot (Note: There's something wrong with the DPI scaling of the main screenshot, I'll deal with that separately):

[unknownbrackets]

I think it might be fair to call it a prim if we highlight the area it's uploading to and it actually affects the target framebuffer. Otherwise, I think this is confusing. I think it might make sense to add a new step type, but a LOT of people use the GE debugger to rom hack and investigate graphics, and seeing a bunch of prim steps that highlight nothing is a confusing experience.

-[Unknown]

[hrydgard]

I'm gonna revert this for now. I do want the functionality though so will do it in some optional way.

[unknownbrackets]

Maybe it can be under Breakpoints, "Break on block transfers"? I would kinda want some way to know when it's starting a list and a memcpy happened too, because I agree this sort of thing is useful when debugging. I'm most interested in block transferred from/to the render target (color, depth), although textures are interesting too (but less so, depending.)

-[Unknown]

[hrydgard]

Yeah, could be okay there. Can also think of some other additional break types that could be useful (break on through mode, for example, to skip to HUD/post processing after 3D in some games, for example).

[unknownbrackets]

Well, you can already break on the vertex type changing. It'd be nice to filter those by bits, that feels more like a condition on the existing register-based breakpoints.

Edit: then again, I don't always remember exactly the bit for throughmode, so something dedicated for that could be nice. Ideally, it'd split out the various bit fields for registers to individually breakpoint...

-[Unknown]

[unknownbrackets]

I'm sure there will always be more problems with depth, stencil, splines, etc. I don't think the most visible problem now will always be the One True Problem. That said, I don't really care that much about the reordering, I just don't agree with that assertion.

This really looks like one of those screenshots now people use to joke about why not to let engineers design UIs, now. Not that it looked amazing before... though I wish the list change was at least more optional since it seems like it'll make it harder to actual read the list.

-[Unknown]

[hrydgard]

Well, out of the graphics problems that are next on my mental list, most are fb/texture oriented, and the drive for this is entirely to be able to see both fb and tex without clicking back and forth. But yeah it doesn't fully hold generally of course.

I agree it looks horrible but it does help me. You're right though that the display list view gets worse, I'll solve that with an option or something before this goes in.

[unknownbrackets]

Let me try making it so the panel can be moved...

-[Unknown]

[unknownbrackets]

Okay created #15842 (targeting this branch), which would allow me to keep the display list where I want it.

-[Unknown]

[hrydgard]

OK, merged your (rather excellent!) change, and reverted the blocktransfer-as-prim thing, though something in that direction is useful so will come later in some optional or clearer (highlighting, if targeting the current framebuffer maybe?) form.