Ys Seven minimap broken

[Krude]

Searched for it, but didn't get any results on wherther this was already mentioned. In Ys 7, the minimap in the upper right corner does not work. It's supposed to show a local part of the overall map you can view with Select. It's blank, though. Tested on Win7 x64 with PPSSPP 7.6 1214 g5335416.

[solarmystic]

Confirmed with 0.7.6-1214-g5335416. A minor issue, but an annoying one nonetheless.

Also, another issue to add for this mostly playable game:-

Game doesn't feeel like 60 FPS even though the VPS counter shows 60 VPS all the time in certain areas of the game, especially open areas. It feels like the game is internally rendering @ 20 VPS even though it's showing 60 VPS.

The best place to test this phenomenon is in the main capital city where you start the game in.

Head to the market district (where you can access the weapon and item shops).

The game will feel sluggish, yet the VPS counter is still showing 60 VPS.

Add this game to list of games that do not feel like 60 VPS (like Metal Gear Portable Ops) despite what the counter is displaying. I forgot which issue page it was, I think @unknownbrackets started it somewhere on github for those games.

[unknownbrackets]

I'm relatively certain that this game renders at 30 fps on purpose, at least from the way it calls syscalls. You should probably compare with an actual PSP.

-[Unknown]

[rpgadvocate]

Hexyz Force exhibits the same behavior (minimap broken, overall map working).

[solarmystic]

@unknownbrackets

Which it does, most of the time.

When it internally dips even below 30 fps is when it becomes really sluggish. Just an observation, not that it's game breaking or anything, but I'm fairly sure the game doesn't chug on a real PSP while in the capital city.

[Krude]

Adding to what solarmystic says, i've noticed some "stuttering" in some intensive scenes in the big city, too. I've played through the whole game on a PSP, and that never happens on real hardware.

[ghost]

This problem is fixed by https://github.com/hrydgard/ppsspp/pull/2463. However the speed is pretty slow with this option.

[papel]

The last optimizations made it playable with minimap without speed problems on an old PC. I think this issue may be closed.

[dbz400]

Good to hear the minimap finally show up here .Please close it .

[papel]

@arnastia Despite the better speed, I noticed new small bugs after the changes https://github.com/hrydgard/ppsspp/pull/2621. I used v0.8.1-326-g25392cd.

There is no problem with the minimap. Now the transparency of the big map (when I press select) disappeared, but it is not important.

And if the game screen area does not fill the window entirely and I save the game, the screenshot of the save icon will include the black parts that are not part of the game screen area.

This picture is a screenshot I got with F12. Screenshots with F12 also include these black parts, but this was happening previously in v0.8.1-232-g676c000.

[solarmystic]

@papel

You need to make sure FramebuffersCPUConvert = True along with FramebufferstoMem = True in the ppsspp.ini, to get the proper functionality again in the latest builds. I just discovered this when I made my issue report (that I've close since I realised what had to be done)

https://github.com/hrydgard/ppsspp/issues/2641

[arnastia]

Yeah, I still haven't debugged this on an ATI/AMD, so if it did work it would have been a wild shot. It seems people also aren't enabling FramebuffersCPUConvert manually, so I'll default it to true, since it should work on both major vendors and performance is pretty much the same (sometimes better?), at least on my system. The more important FramebuffersToMem already has a UI settings menu option, Skip Updating PSP Memory, on the first page of graphics settings, reversed, so you need to disable it to enable my fix.

As for the window resizing bug. Didn't even realize you could resize the window like that, but should be an easy fix.

[papel]

@solarmystic @arnastia

I enabled FramebuffersCPUConvert too, but the bugs in Ys Seven continue. My problems with Ys Seven are different from #2641. But with FramebuffersCPUConvert disabled, I have no problems with Soul Calibur and Trails in the Sky.

My card is Nvidia.

[arnastia]

@papel Oh, this was on an Nvidia? Which model?

[papel]

Geforce 9600 GT

[arnastia]

@papel I fixed the window resizing bug and pushed the fix online to my fork. That one would probably have happened with every card, BTW, so nice job spotting it.

As for the map transparency problem, can you post a screenshot? Preferably with the fix I just uploaded. If you can't compile it yourself, I compiled a 32-bit version you can get here:

[scratch that]

EDIT: Ok, nevermind. I found my copy of Ys Seven and just tested this. It solves the problems for screenshots, but seems to introduce other problems. My big map also has no transparency, so I'll check that too.

[solarmystic]

@arnastia

Does FramebuffersCPUConvert = True by itself do anything? Or is it just a performance sucker when compared to FramebuffersCPUConvert = False.

I always thought it was meant to be used together with FramebufferstoMem = True otherwise it won't do anything of significance.

Or am I wrong about this?

[arnastia]

@solarmystic You are correct, FramebuffersToMem and a version compiled for OpenGL devices (such as the Windows version) are both needed for it to actually do anything.

FramebuffersCPUConvert is also not necessary on OpenGL ES devices because CPU conversion is pretty much the only way to get pixel format conversion on those. But since I don't have one of those, I haven't tested yet.

EDIT: As for its performance. I thought it would be a huge hit, but on most occasions seems to perform slightly better. Only tested Danganronpa though, and that one is a rather light game on this fix.

[papel]

FramebuffersToMem is enabled, but this is the same as if I disable FramebuffersToMem.

If the game screen area does not fill the window entirely, I get this problem. It does not happen if I disable FramebuffersToMem. I do not know if it was fixed with the new changes.

If I enable FramebuffersToMem and see the big map, it will not have transparency. If I disable FramebuffersToMem after seeing the map and see the map again, the transparency will work, but it will show the place where I was when I saw the map when FramebuffersToMem was enabled. In the screenshot, the background image is not of Ancient Tree, it is of Shannoa Village. If I change the size of the window, no problem will happen.

[papel]

The first area of Flame Sanctum is broken in recent versions (v0.8.1-540).

It works in version v0.8.1-232-g676c000. The same version in which the transparency in big map works and minimap does not flicker. It is dark when FramebuffersToMem is disabled.

The second area does not require FramebuffersToMem.

This is a video of Flame Sanctum on real PSP: http://www.youtube.com/watch?v=5ZvBHiLx3ko

When FramebuffersToMem is disabled during the game, the old data is kept in memory and it is shown in wrong place ant time. An example is to save after disabling FramebuffersToMem, the icon will show the picture of the last time that FramebuffersToMem was enabled. It would be good to clean this data after disabling FramebuffersToMem during the game. The default data is black screen. But I think it cannot be done easily, because we do not know where the data is in memory. Maybe a solution is possible. After disabling FramebuffersToMem, at the next time a read from framebuffer is done, PPSSPP should read "black" instead of framebuffer data and then stop reading. It would write "black" screen to the memory.

[arnastia]

@papel Is there any point in writing the screen to black? It's easily done, just didn't see any point in zeroing back the VRAM if the hack's disabled.

What's happening to the map in Ys Seven is the following.

Every frame with the map Ys Seven draws the main scene with the characters to a framebuffer (which will be the display framebuffer), then draws some other framebuffers, and then draws the map on top of the same framebuffer it drew the main scene on. It copies the originally drawn scene to RAM and then draws the map on this framebuffer. So why doesn't the transparency work with the new version of the hack?

The first version of the hack read a framebuffer to the VRAM whenever the currently being-rendered-to framebuffer was to be switched, or whenever a framebuffer was displayed. Amongst the performance friendly ways to do it this is probably the best in that it's the closest to how the PSP behaves (not that it's truly close at all, since the data is always there on the PSP). But on the second version of the hack I now copy each framebuffer's content to memory at the beginning of each frame instead. This change has to do with another issue.

To attempt to make the code portable to Android/OpenGL ES devices as well as attempt to improve performance somewhat on OpenGL devices, I switched from duplicating-and-resizing framebuffers with glBlitFramebuffers (only available on OpenGL) to drawing a screen aligned quad with the source framebuffer's texture on the destination framebuffer, so that I had a flipped and resized framebuffer ready for reading. But it turns out using a framebuffer as a texture to render to another framebuffer mid-frame caused some visual glitches in Danganronpa on undrawn areas that should just show up as black. So I moved the reading code to the start of the next frame when framebuffers weren't being drawn to, and that fixed it. This, however, is bad for Ys Seven because the game expects the contents of a framebuffer drawn in that frame to be in memory mid-frame. Instead, because the last change to that framebuffer in a frame draws the map, the VRAM ends up having only the map data and not the main game scene, and it draws the map blended with last frame's version of the map.

Now, as I said Ys Seven copies the data from the VRAM to RAM mid-frame to use as a background to blend into the map, and it does that with a block transfer, so I can detect it and read the framebuffer at that point to memory, and the map will blend. There's just one last problem.

One of the tradeoffs made for performance in the last version was to only update memory every three frames. It would introduce a small lag, but since most games seemed to use this hack for minimal stuff and the performance gain was reasonable, maybe that wasn't so bad. But if I only update memory every three frames then only every three frames will the map have a blended background. That ghosting you took a screenshot of is most likely also caused by this tweak. In that dungeon the game must be blending something to the background from VRAM; you'll get similar ghosting if you open the map and move it around. This unfortunately means this 3-frame trick is no good, or at least the number of frames needs to be tweak-able.

What I was trying to do is maintain a snapshot of the memory state of a framebuffer at each point it's switched to in a frame, so that I could copy that snapshot to memory whenever I could detect it would be needed (such as a block transfer from VRAM to RAM) and thus avoid having to update the memory every frame, but if there's noticeable ghosting in gameplay heavy parts of the game, then there's probably not much point in doing this anyway since it won't fix that. It'll hurt performance, but I guess I'll have to update memory every frame.

As for the minimap being a different size, glad it's fixed, but I think I was doing something wrong anyway, and I had also fixed it a different way by adjusting the viewport/projection matrix to use the dimensions of the target, smaller framebuffer. The way I was doing it originally worked for Danganronpa because Danganronpa doesn't draw framebuffers of a different aspect ration than the PSP's. Ys Seven and many other games do, but I never tested them before releasing the second version.

TL; DR: Pretty sure I know why that happens, I can fix it, but it'll hurt performance a little.

[papel]

Due to the tradeoff between accuracy and performance, new options could be created, for instance, an option to update the memory after each one or three frames. It may not be good if the emulator had too many options. Other games have problems related to framebuffer and the problems are present in older versions. The solution may also worsen the speed.

The idea of zeroing the data is to avoid strange images. If FramebuffersToMem is enabled and I disable it during the game, the wrong data will be shown. When the game is started with disabled FramebuffersToMem, this problem does not happen, because there is no image in memory. The memory should be zeroed only once after disabling FramebuffersToMem during the game.

This example shows ghosts of the moment I disabled FramebuffersToMem.

In this example below, FramebuffersToMem was enabled. I opened the game menu, disabled FramebuffersToMem, closed the game menu and got this image.

[arnastia]

@papel Whoa, neat effect. But yeah, I guess it's reason enough to empty it out. Should be easy to do, so I'll probably add it to my next pull request.

As for an option to control the update's frameskip, it can also be done. I didn't do it at first because yes, it would be yet another option to tweak a specific hack.

[papel]

Other problems appeared in https://github.com/hrydgard/ppsspp/issues/2774, but they were fixed.

@arnastia @raven02 According to https://github.com/hrydgard/ppsspp/pull/2786, it seems that some changes are needed before merging Arnastia's patch. I would like to test the patch. I tried to pull it to here, but it has conflict when I tried to merge it.

[dbz400]

Just some catchup on the softGPU on this game , it renders those effect pretty good .

[papel]

@hrydgard All bugs in Ys Seven that were reported here are fixed finally.

@raven02 Thank you.

There are two bugs that I reported here that are not specific to Ys Seven. It seems that arnastia fixed both problems, but the patch was not merged.

I moved the first bug to https://github.com/hrydgard/ppsspp/issues/3130.

The second problem happens when "read from framebuffers" is enabled and during the game and then it is disabled without restarting the game (https://github.com/hrydgard/ppsspp/issues/2156#issuecomment-20848911). Images from the past are shown at wrong times, because there is garbage data that was not cleaned. A reason to disable it during the game is when the speed is low.

[dbz400]

Basically , there should be flame on those enemies body and we are missing it . If depthwrite set always TRUE , the flame renders on the enemies as shown below however the lava is not rendered correctly . Not too sure what is the issue.

[dbz400]

Cross-checking the softgpu to see how it can render this scene correctly .We seems to be lacking the apply stencil with depth testing in GLES (may be i'm wrong)

            if ((gstate.isDepthTestEnabled() && !gstate.isModeThrough()) || gstate.isModeClear()) {
                // TODO: Verify that stencil op indeed needs to be applied here even if stencil testing is disabled
                if (!DepthTestPassed(p.x, p.y, z)) {
                    ApplyStencilOp(gstate.getStencilOpZFail(), p.x, p.y);
                    continue;
                } else {
                    ApplyStencilOp(gstate.getStencilOpZPass(), p.x, p.y);
                }

                if (gstate.isModeClear() && gstate.isClearModeDepthWriteEnabled())
                    SetPixelDepth(p.x, p.y, z);
                else if (!gstate.isModeClear() && gstate.isDepthWriteEnabled())
                    SetPixelDepth(p.x, p.y, z);
            }

[dbz400]

However i don't know how to port it to GLES unfornaturely ......

If i comment out out the following apply stencil with depthtestpassed , GLES and softgpu show exactly same bug

            if (!DepthTestPassed(p.x, p.y, z)) {
                ApplyStencilOp(gstate.getStencilOpZFail(), p.x, p.y);
                continue;
            } else {
                ApplyStencilOp(gstate.getStencilOpZPass(), p.x, p.y);
            }

[dbz400]

GLES

SoftGPU

[dbz400]

or may be @neobrain can help for our GLES ?

[neobrain]

If I understand you correctly (I haven't read the whole issue), you need to be able to control at which point in the host gpu pipeline the stencil value should be written, right?

If that's the case: Good luck implementing that in OpenGL, it won't work :p

[dbz400]

Humm let me check if jpcsp GL engine renders this one correctly or not .

[dbz400]

Alright .JPCSP renders it okay in GL

[unknownbrackets]

http://report.ppsspp.org/logs/game/ULUS10551_1.00

Possibly broken list processing/bug: CALL to illegal address 00042699 - ignoring! data=042699 JUMP to illegal address 05bcf80c - ignoring! data=bcf80c Unsupported logic op enabled: c3a98a Unsupported logic op: bbaf4d

Unsupported features: Unsupported alphatest mask: 88 (maybe softgpu implements this, not sure.) sceDmacMemcpy(): FBO blit?

Any of these could be related, and most will affect softgpu as well as gles.

-[Unknown]

[dbz400]

Humm then it is surprising that softgpu renders it correctly but i think it implemented correct depth/stencil testing as i tested those games we have depth issue from GLES , all good in softgpu .

Game list with depth issues in GLES

• Saint Seiya Omega
• Phastasy Star
• Ys Seven
• Gundam Age Universe

[dbz400]

I think this one can be closed .Mini map at least shown correctly under framebuffer to memory mode.

[unknownbrackets]

It's probably fixable everywhere, may even just be a stencil issue.

-[Unknown]

[dbz400]

The lava should be rendered correctly now .Thanks for @unknownbrackets depth clear commit :)

[dbz400]

All issues resolved .Please close.

[unknownbrackets]

It works on Android too?

-[Unknown]

[hrydgard]

Not likely.

[unknownbrackets]

The minimap does seem to work fine now, seems like a block transfer issue, probably working due to the motogp fix. Didn't check carefully.

So the only remaining issue is the flames on devices that don't support blitting the depthbuffer, right? If yes, maybe we should centralize those issues (including Jeanne d'Arc.)

-[Unknown]

[dbz400]

The minimap only works in framebuffer to memory mode though.It would be good if later we can make the map visible in buffered rendering mode.

[unknownbrackets]

Hmm I always have that setting disabled. Maybe I accidentally left it enabled looking at another bug.

-[Unknown]

[unknownbrackets]

Definitely shows a map for me in buffered rendering. Is there more to it?

-[Unknown]

[dbz400]

Looks like this one on the right hand corner ?

[unknownbrackets]

Yes. So it still doesn't show for you? Maybe it's only certain areas. I'm in a desert.

-[Unknown]

[dbz400]

Any screenshot ? There should be a map elsewhere ,

[unknownbrackets]

Both small and large work okay.

-[Unknown]

[dbz400]

If you change to framebuffer to memory mode , the small map should be different and very detail with pathway.