Games that still need "Framebuffer to memory"

[hrydgard]

Our new blocktransfer support (Thanks to @unknownbrackets for fixing tons of issues!) and related memcpy overrides fix most of the games that previously needed the "Framebuffer to memory" modes.

Are there any games that still need them? Otherwise I would like to remove or at least hide them in developer options, as they are slow and often cause instability.

#2713
#4739
#7695
#6880
#6547

[solarmystic]

EDIT:- Trails in the Sky was working fine all along, I just had function replacements disabled.

[solarmystic]

EDIT:- Same thing goes for GEB, function replacements resolved the issue. Buffered + Simulate Block Transfer fixes the flickering now.

[hrydgard]

Hm, that save screen thingy is curious. Not really critical though, the Trails one is worse (but has worked previously?)

[solarmystic]

@hrydgard Afaik the Trails one has always required Read Framebuffers to Memory enabled to work properly in all prior revisions.

[unknownbrackets]

@solarmystic do you have function replacements disabled? Gods Eater Burst and Trails both work. They both require function replacements (default on - FuncReplacements = True.)

-[Unknown]

[solarmystic]

@unknownbrackets Ahh, my bad, that was the culprit for both games. Thanks for the heads up.

[hrydgard]

Thanks for clearing that up :)

[daniel229]

Rockman Dash #4739
Maybe Danganrunpo still investigate wrong thing on mobile without Framebuffer to memory.I heard.

[unknownbrackets]

Hmm, we have a Danganronpa hack directly, it should work everywhere...

For Rockman DASH, I was hoping the framebuffer texture offset thing would fix it (#6259). Does it detect it as an offset?

-[Unknown]

[daniel229]

Yes, Rockman DASH is fixed.

[unknownbrackets]

Nice. So it doesn't need "read framebuffers to memory" anymore, right?

-[Unknown]

[daniel229]

No need it any more.

[daniel229]

Sakura Taisen video still need "read framebuffers to memory" ,graphics are fixed just like Rockman DASH.

without "read framebuffers to memory".

[unknownbrackets]

Is it using sceMpeg or scePsmf? Basically I'm wanting to know where it writes the video to, and how that's supposed to make it to the display. A debug log would probably do the trick.

-[Unknown]

[daniel229]

Debug log(rename jpg to rar)

[daniel229]

the silent hill games might need it.

[unknownbrackets]

14:49:561 user_main D[HLE]: HLE\sceDmac.cpp:89 sceDmacMemcpy(dest=04000000, src=098be820, size=524288)
14:49:561 user_main W[G3D]: GLES\Framebuffer.cpp:2048 Memcpy fbo upload 098be820 -> 04000000

That memcpy is either 512x256 or 480x272, but it should still theoretically work.

Est: 44088000

It's got its FBOs at 44. Maybe there's still an issue matching framebuffers. If you press "step frame" during the video, where is it texturing from? I assume it's texturing from 04000000 to draw the video to 44128000 / 44088000. Those are at least 320 apart so there should be space...

Hmm, might need more breakpoints in the silent kill game to see what it's doing.

-[Unknown]

[daniel229]

Right,it's 0x04000000

[unknownbrackets]

Hmm. I wonder if the FBO has the wrong format. It's not drawing to it.

Render to texture with different formats 3 != 1

I wonder if we should swap the format if it gets used for too long like that without being rendered to. What if you change:

WARN_LOG_REPORT_ONCE(diffFormat1, G3D, "Render to texture with different formats %d != %d", entry->format, framebuffer->format);

Add below:

                if (framebuffer->last_frame_render + 10 < gpuStats.numFlips && entry->format <= 3) {
                    framebuffer->format = (GEBufferFormat)entry->format;
                }

(or, really, in this case we could also skip rendering from the texture. Which may also be safe...)

-[Unknown]

[daniel229]

Not help.

[daniel229]

If I click buffered rendering,it works fine.

[daniel229]

So the sakura's video works with framebuffer to memory on game bootup,or changing buffer rendering mode("normal buffered rendering" to "normal buffered rendering",or "normal buffered rendering" to "framebuffer to memory") while the video playing.changing resolution does not help.

[LunaMoo]

#5447 - macross games kind of needs it to show heat wave effect over the engines, however it get's slightly wrong color(?) which makes it look kind of bad anyway.

[hrydgard]

update: Macross no longer needs fb to memory, the effect mostly works without it.

[LunaMoo]

#6411 reminded me that Me & My Katamari requires framebuffer to memory while naming an island.

59:57:053 user_main    I[SCEGE]: GLES\Framebuffer.cpp:986 Creating FBO for 00044000 : 480 x 272 x 1
59:57:152 user_main    I[SCEGE]: GLES\Framebuffer.cpp:986 Creating FBO for 00000000 : 480 x 272 x 1
59:57:156 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
59:57:199 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:05:977 user_main    I[HLE]: JitCommon\JitBlockCache.cpp:173 Adding proxy root 088a38a0 to block at 08823d18
00:05:979 user_main    I[SCEGE]: GLES\Framebuffer.cpp:986 Creating FBO for 00154000 : 128 x 128 x 3
00:05:979 user_main    W[SCEGE]: GLES\Framebuffer.cpp:1024 FBO using existing buffer as depthbuffer, 00154000/00000000 and 00000000/00088000
00:07:806 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:07:806 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:07:807 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:07:807 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:07:807 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:07:807 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:07:808 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture

^ this shows up in buffered rendering with simulate block transfer and the game doesn't allow to continue althrough doesn't crash or anything

changing to read framebuffers to memory allows to continue with:

00:38:802 user_main    I[G3D]: GLES\TextureCache.cpp:111 Texture cached cleared from 29 textures
00:38:855 idle0        I[SCEGE]: GLES\Framebuffer.cpp:2043 Destroying FBO for 00044000 : 480 x 272 x 1
00:38:856 idle0        I[SCEGE]: GLES\Framebuffer.cpp:2043 Destroying FBO for 00000000 : 480 x 272 x 1
00:38:856 idle0        I[SCEGE]: GLES\Framebuffer.cpp:2043 Destroying FBO for 00154000 : 128 x 128 x 3
00:38:864 user_main    I[SCEGE]: GLES\Framebuffer.cpp:986 Creating FBO for 00000000 : 480 x 272 x 1
00:38:887 user_main    I[SCEGE]: GLES\Framebuffer.cpp:986 Creating FBO for 00044000 : 480 x 272 x 1
00:38:971 user_main    I[SCEGE]: GLES\Framebuffer.cpp:986 Creating FBO for 00154000 : 128 x 128 x 3
00:38:972 user_main    W[SCEGE]: GLES\Framebuffer.cpp:1024 FBO using existing buffer as depthbuffer, 00154000/00000000 and 00000000/00088000
00:39:022 user_main    I[HLE]: JitCommon\JitBlockCache.cpp:173 Adding proxy root 088dd560 to block at 08823d18
00:39:078 user_main    I[SCEGE]: GLES\Framebuffer.cpp:2006 Decimating FBO for 00154000 (128 x 128 x 3), age 6
00:39:079 user_main    I[SCEGE]: GLES\Framebuffer.cpp:2027 Decimating FBO for 00154000 (128 x 128 x 3), age 6
00:39:672 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture
00:39:729 user_main    I[G3D]: GLES\TextureScaler.cpp:545 TextureScaler: early exit -- empty/flat texture

Edit: blah I don't know how to use code tags on github ;| ~ should be ok now.

[achurch]

As of 8b67f42, Brandish (ULJM05424) still needs "read framebuffer to memory" for both fading out to the utility menu (Start button) and generating save file screenshots; without it, the fade or save file image is some random image from an earlier point in time, or solid black shortly after startup. Changing the FuncReplacements setting doesn't seem to make a difference.

[unknownbrackets]

Can you set breakpoints to see where it's trying to read? It may just be a memcpy or similar that we don't recognize. Best way is to see where it fades from (via GE debugger) and how, and then set breakpoints there to see where that data is supposed to come from.

-[Unknown]

[achurch]

It looks like the GE debugger is only built for Windows? I'm on Linux and I can't get the Windows build to run under Wine (it needs the new VC runtime and that dies during install). I tried running under GDB and setting read watchpoints on 0x40{00,88}000 in the emulated memory region but didn't catch anything obvious, so I'm not sure what else I can do.

I'll see if I can trace back through the code that generates the save screenshot, since that seems to use the same framebuffer copy as the fades.

[unknownbrackets]

Unfortunately, that's true (although some effort was made to keep the breakpointing portable.)

I think it works in WINE, although the fonts aren't pretty (unless you have Lucida Console.) To get the runtime, you need to extract it and copy the dlls, iirc.

See here:
http://forums.ppsspp.org/showthread.php?tid=9193

-[Unknown]

[daniel229]

Thanks,It's an RPG like other RPG Final Fantasy and Tales of series,learn skill,magic,change jobs and battles,Not really play into it.

[daniel229]

Sakurasou no Pet na Kanojo saveicons
https://gist.github.com/daniel229/ee3674788f4c560e8258

[unknownbrackets]

I can't really tell from that func where the source is coming from, it's a bit of a complicated function.

-[Unknown]

[hrydgard]

The function does itself call memcpy. Catching that is not enough?

[daniel229]

Maho Shojo Lyrical Nanoha A's Portable,saveicons only works on Framebuffer to memory
I set a breakpoint address 0x04000000 size 200000.It did not hit anything.It should store that frame to somewhere after about 6 seconds from battle start,because if I change buffered Rendering to Framebuffer to memory between time 99.9994.xx,then the saveicons work.,if change buffered Rendering to Framebuffer to memory between the battle time 93.xx0 then the saveicons are still black,(battle time countdown from 99.99 to 0)

[unknownbrackets]

Hmm. There are probably still some HLE functions that it might use that would copy without triggering a breakpoint, so I'm guessing it must be one of them. Does it call any interesting syscalls during that time?

-[Unknown]

[daniel229]

Debug log(rename jpg to rar)

[daniel229]

Kirameki School Life SP saveicons.
https://gist.github.com/daniel229/20115693e8aa37575b93

Not sure why adress is S0,but it works
#6875

[daniel229]

Ore no Imouto ga Konnani Kawaii Wake ga Nai saveicons
https://gist.github.com/daniel229/9be33beee1958072c1d7

Adress is V1.

[daniel229]

@hrydgard Yeah,replace the memcpy seems fixes the saveicons.
#6880

[pal1000]

Some homebrews require Read Framebuffers to Memory to work properly.
UO GPSP Kai needs this mode to display GUI otherwise you only see blue screen. If you have only 1 GBA game you can run it by pressing X and then switching from Buffered Rendering to Buffered Rendering; it's sounds odd but it works. Of course the GUI doesn't work without Read Framebuffers to Memory, so if you have multiple games you won't be able to see what you select in the menu.
There are plenty of homebrews like this out there. The official forum is a good source of information on this topic.

[thedax]

That's pretty much #4685, @pal1000. I'm honestly not sure if it'd be worth hooking and replacing homebrew functions though. There could be dozens of versions of one homebrew, and if they then update, our function hooking might not catch new drawing methods.

I'll let [Unknown] or Henrik give a more informed opinion, though..

[unknownbrackets]

Switching between modes will force an upload nowadays with "slow effects" enabled.

Well, hooking homebrew memcpy's may make sense, but if the gba emulator is pixel poking, we're pretty much in a bad place. Better to use software, or convince the authors to render "better" (using a block transfer or texture would be great, probably.)

-[Unknown]

[pal1000]

I think homebrew development for PSP has diminished significantly. UO GPSP Kai development ended in June 2012. The other ones GPSP official doesn't work due to missing key as it is fake signed and GPSP-J cannot load ku_bridge,prx kernel module. Anyway pretty much all emulators running on PSP had their development ceased by now. Filetrip.net has the biggest homebrews collection and they don't host warez. You can find plenty of them there.

[daniel229]

Hentai Ouji To Warawanai Neko https://gist.github.com/daniel229/ec2472c5d962ecfd4cec
and Toradora! Portable https://gist.github.com/daniel229/d27475363bf19fd511e9
can use the hook "kirameki_school_life_download_frame"

    { 0x8f09fb8693c3c49d, 992, "kirameki_school_life_download_frame", }, // Hentai Ouji To Warawanai Neko
    { 0x757d7ab0afbc03f5, 948, "kirameki_school_life_download_frame", }, // Toradora! Portable

Little Busters Converted Edition https://gist.github.com/daniel229/b8698cabb82b91c3c9eb

{ 0xdeb6a583659e3948, 1080, "little_busters_download_frame", }, // Little Busters Converted Edition

static int Hook_little_busters_download_frame() {
    const u32 fb_address = currentMIPS->r[MIPS_REG_A0];
    if (Memory::IsVRAMAddress(fb_address)) {
        gpu->PerformMemoryDownload(fb_address, 0x00088000);
        CBreakPoints::ExecMemCheck(fb_address, true, 0x00088000, currentMIPS->pc);
    }
    return 0;
}

{ "little_busters_download_frame", &Hook_little_busters_download_frame, 0, REPFLAG_HOOKENTER, },

[daniel229]

Hot Shots Tennis Portable,I can't get the icons work
demo
http://www.pspdemocenter.com/page.php?id=2990

the first icon is after I saving,it's missing.the second one showing the character is the default icon.

Press triangle to change style.it likely to catch the icon after pressing confirm button in the following screen.

set breakpoint address x04000000 size a0000,then press confirm button from above screen,can catch something,then uncheck that breakpoint,set breakpoint on zz_sceGeEdramGetAddr:jr ra
click "go" for 5 times,you can get the following screen,the icon likely catch from this screen.

[daniel229]

Maho Shojo Lyrical Nanoha A's Portable missing saveicon because of age 6 Decimating FBO.
it create FBO in the beginning of the battle

58:46:412 idle0        I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 001eb800 : 256 x 272 x 3

and it download it to memory after battle.

59:52:709 user_main    W[G3D]: Common\FramebufferCommon.cpp:534 Memcpy fbo download 041eb800 -> 045eb800

[hrydgard]

Time to revisit this, I really want to kill off these additional rendering modes and only have non-buffered/buffered left.

@daniel229 what's the status of Maho Shojo? And if that's the only remaining problem, I think losing save icons in that game is worth getting rid of these confusing options.

[unknownbrackets]

Any remaining issues here? I think there's a good chance #8757 helped that game and might've helped others.

-[Unknown]