hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.38k stars 2.19k forks source link

Digimon Adventure PSP NPJH-50686 line visible on the bottom of the game's screen #7470

Closed LPatamon closed 5 years ago

LPatamon commented 9 years ago

Hey there. For some time now there's something that is bothering me about this game on PPSSPP. Is not a thing that gets in the way of the gameplay (as in you can play fine), but I find it kinda interesting so I wanted to share it with you.

For some time now I have noticed that on the bottom of the game screen there is a line that appears as you can see on the following screenshots:

digimonadventureline

digimonadventureline2

This happens if you set the window size on x2 size or up with the rendering size set in auto, but I also tried to put the rendering set manual, as in windows size x2 and rendering size 2 which is same window resolution and internal resolution. On the videos the line is more noticeable as you can see on the first screenshot which is from Gatomon's warp digivolve sequence video (or FMV? I don't know which format they are n.nU), while on gameplay the line is seen only at certain positions. I mean when you have the character standing or moving on certain spots, usually when the camera makes a closer look (not full close up but that the characters look big due to the close view from the camera)

The only time that line doesn't appears is if you use de Windows size x1 and rendering size in auto or 1 and even so the line appears on windows size x1 and rendering size auto after you load your save file or start a new game and you see the intro (the characters outside of that small house they took cover from the snow) and you have to move the rendering size or go to full screen and return for that line to desappear (videos included), but it only works for windows size x1

I remember that on a previous issue (the one about the characters outlines that got solved with the block transfer option) this line had to do with the buffer size or something like that.

The line appears on both backends OpenGL and Direct3D9

I thought in open an issue so at least we can have a progress log for it. There's no hurry since it doesn't affects the gameplay at all, but I found interesting that this line appears at the bottom of the game screen. I attached a third screenshot below. This one is from a previous build of PPSSP after the outlines issue got fixed, but it works for this issue. The screenshots above are with the latest PPSSPP build from buildbot.

Thanks in advance :)

screen6

Extra info: The line on gameplay (as in when you can move the character) only appears if simulate block transfer is enabled. When this setting is disabled that line doesn't appears for gameplay, but it does appears for videos even with the block transfer setting disabled. This means that we have 2 different issues. One is the line on gameplay which seems to be related to simulate block transfer, and the line on de videos (digivolutions, some scenes, the Adventure anime opening) the game includes. Oddly enough both issues disappear in windows size x1 and rendering size 1 after a few tries. this not being the same for the rest of rendering size and windows sizes.

LunaMoo commented 9 years ago

It's a typical upscaling glitch, since texture scaling doesn't work on it, there's pretty much nothing you can do about it other than playing at x1 res or disabling block transfer and reloading the game from normal save, That will remove the low res 2D texture over 3D character models which is quite ugly and causes this issue, but also makes the celshading effect. Edit: forgot about other solution - you can force "nearest" for texture filtering, it'll also remove the line.

LPatamon commented 9 years ago

Yeah I noticed that with nearest on the texture filtering the line is removed, though the game gets kinda more pixelated. I'll try to mess with the postprocesing shader to see if that helps to get a less pixelated image n.n

By the way, disabling the blocktransfer one only removes the line on the gameplay, the line on the videos remains, oddly enough that one is removed with the texture filter setting on nearest.

Edit: Interesting. I noticed that the line doesn't appears on software rendering mode (the one that gives so slow speeds). Both gameplay and videos appear normal without that line.

Ah well. maybe that will be corrected as the emulation improvements for PPSSPP keep advancing n.n

LunaMoo commented 9 years ago

Software mode is x1 res as well hence it doesn't have a line there.

IMO best choice for this game is to disable the effect completely since it covers high res models with low res blurry texture just to make it's celshading:].

But if you love celshading soo much to live with low res characters, you can try this cw cheat hack I just made by playing with verticles: _C0 Verticle hack _L 0xE0120004 0x0016E874 _L 0x2016E874 0x0A200C00 _L 0x20003000 0x341B0110 _L 0x20003004 0x161B0008 _L 0x20003008 0xAF0C0004 _L 0x2000300C 0x341B0100 _L 0x20003010 0x14DB0005 _L 0x20003014 0x341B0010 _L 0x20003018 0x15DB0003 _L 0x20003020 0x0A25BA1F _L 0x20003024 0x34090001 _L 0x20003028 0x341B0100 _L 0x2000302C 0x161B0006 _L 0x20003030 0x341B0000 _L 0x20003034 0x14DB0004 _L 0x20003038 0x341B0100 _L 0x2000303C 0x15DB0002 _L 0x20003044 0x340E00FF _L 0x20003048 0x0A25BA1F _C0 Verticle hack [Disable] _L 0x2016E874 0xAF0C0004

This hack basically detects the texture by somewhat unique verticles and change UV map to take 1 pixel less from both textures avoiding the glitchy edges.:3

LPatamon commented 9 years ago

Well the line on gameplay doesn't affects much, si small and just in center area when the camera does a zoom, I mean that the characters look closer. But the one on the videos is a different thing, that one didn't go away disabling the block transfer thing.

I'll try the code and post the results here n.n

LunaMoo commented 9 years ago

I tested the hack a bit more myself, and while it looked fine in cutscenes I made it on, it looks pretty bad especially in the videos;p, so blah, idea of changing uv map can go to trash;p.

Probably the only way to fix it, would be to use some custom texture filtering which does would avoid messing up the edges in the first place, not sure if that's even possible through.

LPatamon commented 9 years ago

Yeah I tested the code too. it also affects the animation when going into battle mode. You know, that when you touch the enemy digimon that is wandering on the area, you see a sort of blurr animation to take you to the loading screen for battle mode. The normal effect is the blurring before the screen gets filled with the black hexagons till they fill the screen and gets you to the loading screen. But with the code enabled, the blurr gets a sort of stretching animation.

For now my workaround was what you said first, which is the texture filtering to nearest and also I set the texture scaling to auto, that reduced the pixeling on the textures (scenaries like ground, trees, sky) a lot, while the line isn't on the way. At least it is a better work around for now. Good thing that now we can add settings per game so I made this setting only for this game n.n

The custom texture filtering is a an interesting idea, but as you said, we don't know if that can get added.

Ah well. as I said is nothing that gets in the way of the gameplay, I just thought in comment about it since it has been like that since long ago. The videos had that line even before the block transfer feature was added. I'm talking since 2013 when the game became playable.

The other reason I keep the block transfer enabled is because is not only for the character outlines that this feature is needed, but also for other things on the game like the transparency effect when you enter to the slot selection menu when you're saving, or when you enter to the game menu (where you see status, use items, etc.)

The block transfer feature is also needed for the Digivice ver. portable to work correctly, since without it, the digivice's screen which is where you see the action appears all black.

But then again, before we didn't have the create settings for this game feature so we were stuck to a general setting that we had to be changing for each game we play. Now with the per game settings things are so easy since now settings can be saved per each game so it doesn't affect the rest of the games :)

LunaMoo commented 9 years ago

This is very broad issue affecting many games, so finding out a cheap workaround that would work fine for everyone would always be cool.

Problem is performance. xBRZ for example can hide this glitch, but it's set to not affect frequently changed textures like fmv's since it kills performance even on fairy beefy cpu's. I'm affraid adding some custom texture filtering could only be done with similar result.

LPatamon commented 9 years ago

I had the xBRZ option selected and it didn't hid the line on the videos nor on the gameplay. guess for this game the xBRZ didn't work maybe because of what you said that it is set to not affect frequently changed textures.

About performance yeah. Then again emulate the PSP isn't an easy thing and yet PPSSPP is quite a great emulator n.n

daniel229 commented 8 years ago

The texture drawn below the line wrongly since https://github.com/hrydgard/ppsspp/pull/8258

01

before 02

unknownbrackets commented 8 years ago

Is it affected by the addition of glPixelStorei(GL_PACK_ROW_LENGTH, w);, or some other part of the change? I don't see anything there I would expect to affect this behavior.

Anyway, the problem here is most likely it's under-estimating the height of the framebuffer in question. If you exit to the menu and come back, what are the sizes of the framebuffers?

You can also change this from DEBUG_LOG to NOTICE_LOG: https://github.com/hrydgard/ppsspp/blob/8e2557bafeba77c02d67deb3cb3aca27f439f581/GPU/Common/FramebufferCommon.cpp#L261

To see why it's picking those sizes...

-[Unknown]

daniel229 commented 8 years ago

Removing glPixelStorei(GL_PACK_ROW_LENGTH, w); not help it.

sizes of the framebuffers

02:52:683 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1963 Destroying FBO for 00000000 : 480 x 272 x 1
02:52:691 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1963 Destroying FBO for 00044000 : 480 x 272 x 1
02:52:747 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:417 Creating FBO for 00044000 : 480 x 272 x 1
02:52:780 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:417 Creating FBO for 00000000 : 480 x 272 x 1

NOTICE_LOG

18:08:442 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:469 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:472 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:476 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:503 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:506 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:510 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:535 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:538 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:542 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:569 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:572 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:575 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:602 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:605 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:608 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:635 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:638 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:642 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:669 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:672 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:675 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:703 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:706 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:710 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:736 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:739 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:743 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:769 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:772 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:776 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:802 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:805 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:809 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:836 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:839 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:843 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:868 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:871 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:875 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00044000
18:08:903 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:906 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04044000
18:08:910 idle0        N[G3D]: GLES\Framebuffer.cpp:1079 Displaying FBO 00000000
18:08:938 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
18:08:943 user_main    N[G3D]: GLES\Framebuffer.cpp:1775 Reading framebuffer to mem, bufSize = 557056, packed = 0000016822E17290, fb_address = 04000000
daniel229 commented 8 years ago

Revert https://github.com/unknownbrackets/ppsspp/commit/308a9481693fce0f59f738762002a5fa5ef4ef4e#diff-29313f9f6ed28d0e24e6dac4e0db8933R1754

daniel229 commented 8 years ago

Log agains,before is wrong.

51:40:778 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:810 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:40:811 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:811 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:844 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:40:844 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:844 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:876 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:40:877 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:877 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:911 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:40:911 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:911 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:944 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:40:944 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:944 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:977 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:40:977 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:40:977 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00044000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:41:011 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44088000 = 480x272
51:41:011 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
51:41:011 user_main    N[G3D]: Common\FramebufferCommon.cpp:261 Est: 00000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:44088000 = 480x272
daniel229 commented 8 years ago

pass y to glReadPixels,but in SafeGLReadPixels it set to 0.

unknownbrackets commented 8 years ago

D'oh. Thanks - 003d1ea.

It's interesting that there still seemed to be a (smaller) line there before. I guess then it's because it's using a 256 high read to do the first chunk. Might just have a small black line due to off-by-one rendering errors.

-[Unknown]

unknownbrackets commented 6 years ago

Does this still happen? If so, could you try exporting a GE debugger dump on PC?

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

LPatamon commented 5 years ago

It's been a while since I checked this thread. The line is gone now on normal gameplay, now it only appears on the videos.

Sorry I didn't check for replies till now. Let's just say that from 2017 till present, my life has been a wild ride with ups and downs and barely having time for myself x_x

I'm attaching the GE debugger file anyways, I recorded when the video started to play, maybe it can help.

At least on normal gameplay the line is gone so it is a great advance :)

NPJH50686_0001.zip

unknownbrackets commented 5 years ago

Hm, the game renders this in a kinda dumb way. It first draws the top 256 and then the bottom 16. It uses wrap S/T when it does this, and linear filtering.

This only happens when rendering at > 1x and is caused by linear filtering blending some wrapped pixels in. It "works" if you force nearest texture filtering or if you an upscaling post shader.

-[Unknown]

LPatamon commented 5 years ago

Hm, the game renders this in a kinda dumb way. It first draws the top 256 and then the bottom 16. It uses wrap S/T when it does this, and linear filtering.

This only happens when rendering at > 1x and is caused by linear filtering blending some wrapped pixels in. It "works" if you force nearest texture filtering or if you an upscaling post shader.

-[Unknown]

That's right. If I set resolution to 1x the line on the videos is gone, but if I leave it in auto, the line appears.

As I said, at least it is now only on the videos, on the normal gameplay that issue is fixed. My guess is that for gameplay that got fixed with the work in progress to remove the need to have the simulate block transfer option.

But since on videos is another thing, it wasn't covered by this work in progress to remove the simulate block transfer option that started on the pull request #11531.

But hey! The fact that you managed to remove the line on the normal gameplay (as in when you're in control of the character) is a huge improvement :)

LPatamon commented 5 years ago

Closing this issue since the line on the videos was fixed when issue #12186 was fixed. The line on the normal gameplay was fixed long ago so we can close this one as well. Thanks again for all the help and improvements on the emulator :)