Danganronpa bug

[CPkmn]

I tried a search in the issues here to see if anyone reported this yet, but it seems no one did.

While playing Danganronpa (both the demo and the full release) in PPSSPP I noticed objects are not interactable. This basically makes the game unplayable since the requires object interaction on many occasions. I notice the same issue on JPCSP, however the software rendering mode in JPCSP works with the objects (and has since at least revision 2450, the first software rendering public release; https://code.google.com/p/jpcsp/source/detail?r=2450). Unfortunately I can't check earlier releases' software rendering modes since I don't know how to compile JPCSP.

I'll attach a picture of what PPSSPP and JPCSP (in software rendering mode) get when hovering over a should-be-interactable object.

(JPCSP in software rendering mode)

(PPSSPP)

[Kratata]

I don't know how to add Arnastia's fix (have AMD, bug with the objects switching places, can't get out of the room) Is there any way I can patch it (or something)? I'm not really good with computers...

[HermitCrap]

@Kratata, you have to wait. It may even be in vain, the fastest way to play the game now is to play with a real PSP which I intend to do so if there's still no fix by this week since my national exams are starting soon.

[fagoatse]

its possible that amd lied about their opengl specs or you guys are using some ancient cards/drivers.

[HermitCrap]

Nope, if AMD is really lying, it would crash immediately like Intel GPUs. So it's just that it's not optimized. HD7870 Must Edition PCS+ with Catalyst 13.4 and this still happens?

[lKomus]

ATI Mobility HD Radeon 5850 with 13.6 Beta 2 Catalyst drivers, so not a problem of old drivers.

[arnastia]

Can anyone who has that problem post a screenshot of the load screen from the main menu? I don't have an ATI/AMD card to test this, but that should give me an idea of what's happening since the background is supposed to be a blended screenshot of the main menu background.

Not the best place to ask this, but I'm getting rather frustrated. I'm working on a version that draws a screen aligned quad textured with a framebuffer (this one is displayed) onto a different framebuffer (this one isn't) to try to make a portable version of the fix (but maybe the problem on ATI is glReadPixels not converting formats?). Everything should be offscreen, but I'm having some problems, namely something like:

That ceiling's supposed to be mostly black (as in, the game probably doesn't draw a ceiling).

[HermitCrap]

"Can anyone who has that problem post a screenshot of the load screen from the main menu?" I don't understand what you mean by this? Mainmenu as in inside the game or PPSSPP Main Menu. The problem with AMD cards is that the doors and objects are wrongly mapped. So even if we select the lint roller for example, it goes to the notebook, selecting the drawer under the notebook however take us to the lint roller. It works fine on my GT525M laptop and not when I use my HD7870 Myst Edition PCS+ Desktop. Both computers render the ceiling correctly.

[arnastia]

From Danganronpa's main menu go to load game and screenshot the save/load screen, like this:

And the ceiling problem is on a version I'm working on, not the one online (trying to find someone more knowledgeable on OpenGL than me, which shouldn't be hard at all).

[HermitCrap]

Something like this? Oh, the first video which is the Spike logo, Monobear & a girl is shown, the video seems to be stuttering a lot even with stuttering buffering. It is in 60FPS and I need to let it to go up to 900+FPS for it to play at a normal speed.

[lKomus]

There : Using 3x render resolution by the way.

@HermitCrap : yes, the log console seems to spam something with scePsmfPlayer judging from the log console but it's another issue. (Wait don't tell me, we saved at the exact same time with the exact same stats oO)

[HermitCrap]

@lKomus, I use your save file as I don't want to spoil the game. I already accidentally spoil myself with who the mastermind is T.T Don't wanna spoil again.

[CPkmn]

@IKomus my PSMF player doesn't spam the log with any of Danganronpa's videos. I'm using my own PSMF player so it's probably/likely different, but I'm curious about what the one you guys have does. Can you post a picture of the log?

[HermitCrap]

This is the screen shot from all the way at the bottom. The spamming starts from 23:44:200 until 24:50:628.

[arnastia]

The colors seem correct, so it's probably a format/type conversion problem. One of Danganronpa's framebuffers is 16-bit, the other(s) 32-bit. The version I'm working on should fix that, but I haven't tested that portion yet since my card seems to convert formats correctly.

[HermitCrap]

Can you upload it on Mediafire and let AMD Users try? I have problem building the program since yesterday.

[arnastia]

Since I can't find anyone with an AMD willing to test this, guess I'll have to. Really want to know if that ghosting is an Nvidia problem or something wrong with my code.

The code is too messy to push right now (made some changes to submodules too), so you'll have to trust me on this one (32-bit version since that should work on both):

https://dl.dropboxusercontent.com/u/3475202/PPSSPPWindows-fbtm-wip.zip

I'll see to cleaning up the code meanwhile and pushing a commit to my fork.

PS: If someone has any idea about how that ghosting came to be, I could use some help and am on IRC.

[HermitCrap]

Will try it tomorrow since it's like 2 o'clock midnight here.

[Kratata]

^ dl and tried to play with the one u gave Arnastia, but the cursor thingy won't interact :O same problem as in the first post, I have AMD :(

[lKomus]

Downloaded it, unfortunately it doesn't detect my save so I have to restart everything, but I can examine things. I'll let you know once I go to Chapter 1 and if I go pass my room.

Though something to note, the framerate is really fast when I "fast forward" the emulator, don't know what you did to your code but it's great :o

EDIT : Unfortunately it has the ceiling bug : Though when there is text, the graphical glitch disappears :

EDIT 2: So now I am in my room and no luck, it still examines the lint roller instead of my drawer. At least the performance seems way better than last time judging how fast turbo mode was.

[arnastia]

@Kratata First of all thanks for testing it. I'm assuming you have FramebuffersToMem = True under the [Graphics] separator on your ppsspp.ini. If you do and you still can't interact with anything, that could mean AMD cards really don't respect anything other than 32-bit RGB 8-8-8-8, so the 16-bit framebuffer Danganronpa uses is being read wrong.

Ideally glReadPixels should grab the requested components (RGB or RGBA) kept by the framebuffer and convert them to the correct format (BGR 5-6-5, ABGR 1-5-5-5, etc), but standards wise they basically only have to respect RGBA 8-8-8-8 (which usually means hardly any extra work at all for the GPU). I believe this is the case with at least OpenGL ES, so for Android the same thing probably needs to be done.

Look at older comments here and check your load screen; if you can see the main menu background from the load screen then that's what is happening and I'll need to convert the pixels on the CPU, which would probably come with a noticeable hit to performance.

I'll try to write a manual conversion tomorrow and push it to Github since I won't be able to work on this during the weekend.

@lKomus Didn't see your comment. So you can examine with that version? The ceiling problem should be noticeable on most ceilings and some open doors, including the first classroom (basically, what should be completely black areas). If possible tell me if you can notice any glitch when passing your cursor through those or walking the corridors.

[lKomus]

Well, as I said the problem is not solved since I still can't examine my drawer.

If you need further testing with someone always here, I'm available tomorrow evening GMT+1

EDIT : Now that I think about it, I know that modern ATI cards (HD 4x series) does not support Z-Buffer 16 bits in DirectX resulting in black squares all over the screen if the games uses that when you play in 16-bit mode. Maybe it's the same here.

[JohnJohnson55]

A8-3820 here, interacting with stuff in the first room (classroom) works for me. However, my room is still broken: clicking on the drawers examines the roller, clicking the roller examines the notepad, the doors and windows are completely vertical despite being on slanted surfaces, and furniture is not where their shadows indicate they are.

First screenshot is with FramebuffersToMem = True, second is with FramebuffersToMem = False. Third screenshot show the issues with the doors and windows.

[HermitCrap]

@JohnJohnson55, by AMD, we mean AMD GPU, not CPU. If you're using an AMD GPU, then it's a problem with the drivers which doesn't have a fix st the moment. Go play it on a Nvidia Computer and it should work correctly.

[supervamp78]

So i get this bug where when i try to load my save(I'm near the part right after the first night and you first wake up),the loading monokuma stops half way and it freezes and doesn't continue when i click to the x button to get out of the emulator i get this.

https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-prn1/1014871_438618572912594_781202422_o.jpg I can start a new game and it works fine but i have no idea if it was just something i did to the save or if it will always crash when i get to that point and save and then try to load. I got my log file and put it on 4shared.

http://www.4shared.com/file/6d4_VB3e/ppsspp.html?

[Dotty]

@HermitCrap That's an APU. He's likely using the HD 6410D built into it and referring to that. http://en.wikipedia.org/wiki/List_of_AMD_Accelerated_Processing_Unit_microprocessors

[HermitCrap]

Oh, my bad. I saw FX-8320. Still, the HD6410D still isn't gonna help.

[arnastia]

So I had access to an ATI during the weekend (Mobility Radeon HD5165, somewhat old card) and I think I may have finally fixed both the AMD problem (pixel formats incorrectly converted during read) and the ceiling problem (framebuffer being read at a bad time, I guess?), all while making the code somewhat faster on OpenGL devices using PBOs. I still want to test on a more recent AMD card, but it's working on both that ATI Mobility Radeon HD5165 and my Nvidia GTX570.

I also wrote code that should also work on OpenGL ES 2.0 devices, but because OpenGL ES neither has PBOs nor offers any guarantee that glReadPixels is able to return pixels in any format other than RGBA 8888, the hit to performance should be devastating for non-32-bit textures, since I not only have to synchronously read them, I also have to convert pixel formats on the CPU. I haven't tested this because I don't have access to any OpenGL ES device, and am not sure how reliable the android emulator is on this.

I'll do some cleanup to the code and push it to my fork later today. I'll also make it public for anyone who wants to compile and test (completely forgot about that). Once I can test the code on both a recent AMD and an OpenGL ES device (and fix any bugs that might show up), I'll make a pull request again.

[lKomus]

Nice work, can't wait to see it go live.

[arnastia]

I merged the commits from ppsspp's main repository, which I hadn't done in about a week, and now Danganronpa's videos seem to have slowed down to a crawl (from 60 to 0, 1 FPS). Tested another game (Ys Seven), but videos played fine there.

Anyway, the code is up for grabs:

https://github.com/arnastia/ppsspp

Would especially appreciate testers with AMD cards or Android. If on an AMD you still can't select the correct objects (but the square to select stuff still appears if you move the cursor around) and are willing to be a guinea pig show up on IRC since I doubt I'll have access to another ATI for at least the next few days.

PS: Weirdly, reading textures as BGRA8888 and doing the conversion on the CPU seems to work better for my card. If you want to try it on yours, you can set CPUConvert = True to have pixel format conversion be done on the CPU.

[solarmystic]

thanks @arnastia

Will test your solution on my Legacy ATI card (Mobility Radeon 4670)

[unknownbrackets]

@arnastia something similar happened for FF4 (see #2577), but it may also depend on settings. Can you try running a git bisect to see which commit it started in?

I think this option will probably always be needed by this game. There are probably many ways to improve performance in general:

1. When using glReadPixels(), the following are probably equivalent, and we can both guess which one is slower:

   u8 *buf = malloc(large_size);
   glReadPixels(..., buf);
   Memory::Memcpy(fb_address, buf, large_size);
   free(buf);
   
   glReadPixels(..., Memory::GetPointer(fb_address));

   Similarly with ConvertFromRGBA8888():

   u8 *processed = malloc(size);
   ConvertFromRGBA8888(processed, buffer, ...);
   Memory::Memcpy(fb_address, processed, size);
   free(processed);
   
   ConvertFromRGBA8888(Memory::GetPointer(fb_address), buffer, ...);

   fb_address is just an unmapped pointer. It points to real memory when offset by Memory::base or Memory::GetPointer(), and Memory::Memcpy() just does a memcpy() after mapping it. Copying to a buffer beforehand is just going to make it slower, and allocating and deallocating isn't free either. I had actually made a commit that reduced this buffering which significantly improved performance with this setting on.

2. Would a "frameskip" for this copy be acceptable? In other words, only copying on e.g. every 3rd frame, swapping PBOs or calling glReadPixels() at that point. I can definitely see that being faster, and probably the small amount of latency (50ms) would be fairly acceptable?
3. I wonder if doing the color conversion with 32-bits (like TextureCache::ConvertColors() does) would make it faster. There are also other options to improve it (parallelizing it and / or using SSE/NEON, both of which apply to ConvertColors() also.)

For the setting, I suggest FramebufferCPUConvert or something, it's kinda generic as just "cpu convert".

-[Unknown]

[arnastia]

Ok, first of all, thanks to @solarmystic for helping me debug this.

Second, unfortunately the fix isn't quite there yet, but with CPUConvert = True you should be able to play the game (at little more cost performance-wise), so for now everyone with either an AMD or Nvidia should have no problems (both should be able use CPUConvert if needed).

EDIT: @unknownbrackets Ah, never realized game addresses were being mapped 1:1. If so, then yes, that should help performance. I'll change and test that in a bit.

[solarmystic]

Yep I can confirm what @arnastia has just mentioned.

Using his build with FramebufferstoMem= True in conjunction with CPUConvert = True works out for my aging Radeon 4670 card.

I can get past that room in the beginning of Chapter 1 and head to the cafeteria.

You'll have to compile a build from his repo for now though using some form of git and Visual Studio.

EDIT:-

The performance hit from having those double whammies isn't as bad as I feared, even on my aging machine. Turbo in the game still yields around 160+ VPS even in 3D heavy situations (like in the hallways and big rooms like the cafeteria)

[unknownbrackets]

Oh, and is the slow video also present in the demo version? Is it easy to get to?

-[Unknown]

[Reversalf]

@arnastia How do I use your build though?

[solarmystic]

@unknownbrackets

If by slow video, you mean the introductory video before the titlescreen, then yes, the video is playing at only 1-5 FPS, even at full speed (Speed = 60)

[arnastia]

You clone it, compile it, set FramebuffersToMem = True and CPUConvert = True and play. I'd compile and put a build up but I'm trying some stuff first, including @unknownbrackets suggestions.

A pseudo-frameskip, is already being done with PBOs; when a framebuffer is to be saved to memory, glReadPixels is called to fill a PBO, and the result of the previous call to glReadPixels (from another framebuffer/PBO) is received and memcpy'ed to memory. I'll probably separate this from ReadFramebuffersToMem so that framebuffers aren't reliant on other framebuffers being drawn to actually have their memory commited. (EDIT: After reading your comment better, don't really know how noticeable it would be. I'll try it now.)

CPUConvert (will probably change to FramebuffersCPUConvert as suggested) does conversion from 32-bit to 16-bit; I'm reading textures as 32-bit since they are being drawn as 32-bit and that is nicer on modern GPUs (not sure?), so I can't really use the same trick as ConvertColors unless I use 64-bit integers. But, it seems for now that AMDs don't play that nicely with *_REV types, and without those to switch alpha around I'll probably need to do the same kind of processing on the CPU, and at that point doing it 32-bit would probably help.

And no, while the demo does have a video, it's a different one and seems to play fine.

[lKomus]

In your old test build you gave, the video was not slow. Also the slow video glitch was not present in some older PPSSPP builds but I can't remember when it started to screw up. If you go in turbo mode you can see it's going a bit faster and I think someone mentioned he had to go at 900% speed to make the video go at normal speed.

[unknownbrackets]

Well, I meant, skipping an entire frame of memory updates, not just buffering the PBOs. For example, if (gpuStats.numFrames % 3 == 0) ReadFramebufferToMemory(); etc. This would only update VRAM 33% as often, although it would spike every third frame.

Oh, right, it's changing the width. My bad.

-[Unknown]

[HermitCrap]

Since the Intro movie only lags in the latest builds, I think it's got something to do with other Pull request at the same time. Will try the AMD fix when it's release since I can't build it.

[unknownbrackets]

If you want to test a few git builds from the downloads page to see which one caused the slowdown it would help. I'm hoping it's the same issue as FF4, but there's no guarantee.

-[Unknown]

[HermitCrap]

Shall try it out when I'm free.

[l3illyl3ob]

I have a Radeon HD 6870, and the problem appears to be fixed in the test build, so it's working for somewhat newer cards as well.

[solarmystic]

@l3illyl3ob

Thanks for the report, thats nice to hear that it's working for modern AMD cards too.

[lKomus]

@unknownbrackets So I tested builds from Orbis to narrow down where the slowdown happens and it happens between the official 0.8.1 and the 0.8.1-8 build when it used a ringbuffer instead of a huge buffer for videos. Official 0.8.1 doesn't have the problem but 0.8.1-8 do. I don't know how to compile so I can't be more precise.

[arnastia]

@unknownbrackets Yeah, my bad, I read your comment wrong.

Anyway, calling it only every third frame gains us some ~300 VPS, and gameplay-wise the change isn't all that noticeable in Danganronpa, but this is a very static game, other than the trials which I haven't tested yet. Those have minigames of sorts and some of them are timing dependent. I don't know if they require this fix (someone said somewhere they didn't, and I haven't gotten there yet, so I never checked), but if they do it may be preferable to do it every frame. Maybe I should add an option to specify the number of frames to skip updating memory?

For now I pushed a new commit online, changed CPUConvert to FramebuffersCPUConvert, had framebuffers update memory only every third frame provided they were used within those 3 frames, made use of Memory::GetPointer() and some other miscellaneous changes.

As for a git bisect, didn't have the time to do it yesterday, and now shouldn't be needed anymore since pull request #2587 fixes the problem.

I'll try to remember my SSE classes and write some code to convert pixel formats with those when I have some more time.

[lKomus]

@arnastia I can confirm the Class Trial doesn't use FramebuffertoMem, you can test that by downloading the demo on the translation site since you can go to the Class Trial directly from the start.

[NewDCD]

Howdy folks. I heard you needed testers for your builds, so I went ahead and did some experimentation on my end.

Currently, I've tested the Danganrompa demo in two different places. Firstly, my personal home computer, with the following specs:

AMD Phenom II X4 955 @3.2GHz (stock speed) 2GB DDR2 RAM AMD Radeon HD 6750 running at stock speeds. ppsspp build v0.8.1-218-g4202e28 x86

So far, by changing FramebufferstoMem to True in the .ini, object detection seems to work fine:

So no problems in that front, it would seem.

It gets more interesting in my Nexus 7, rocking Android 4.1.2 and Superuser access (ppsspp build v0.8.1-201-g6c3f63b). I used Superuser to access the ppsspp directory within Android/data/data and edited the .ini there as well.

The emulator wouldn't detect objects this time. Additionally, whenever Buffered Rendering was active, Speed would take a pretty nasty hit, averaging the 50's range. Which is strange, considering I tested Knights in the Nightmare with Buffered Rendering on the official Build 0.8.0 with buffered rendering and it ran smooth as butter.

In any case, I'd be glad to help with anything I can, despite my currently-pitiful knowledge about programming. If you guys have a new Android build that fixes those problems, I can test it immediately.

[lKomus]

Object detection is not a problem in the demo, maybe you'll get the wrong items examined but you can finish the demo fine. But in the full game, you'll get stuck very early in the game because you must examine everything in a room and there's one single item you can't examine preventing from progressing further in the game.

[solarmystic]

@lKomus

Yep. Which is what the CPUConvert function when used together with the FramebufferstoMem function fixes in @arnastia's experimental build.