mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #1686] Danganronpa bug #544
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#544
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CPkmn on GitHub (May 5, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/1686
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)
@hrydgard commented on GitHub (May 5, 2013):
I bet it reads pixels using the CPU to figure out what's under the cursor, or something like that. Hard to emulate without readbacks at just the right moment or software rendering.
@CPkmn commented on GitHub (May 5, 2013):
I noticed something else interesting :
When you use software rendering in JPCSP, then switch out of software rendering, the objects are detectable.
This makes the graphics nicer, however every time a scene comes up this would need to be done (which would be annoying)
@sum2012 commented on GitHub (May 6, 2013):
@CPkmn
I have a post of this game
https://github.com/hrydgard/ppsspp/issues/844
edit:I don't need to enable software rendering.Leave all setting blank.I am using Nvidia card
@CPkmn commented on GitHub (May 12, 2013):
@sum2012 thanks. I did some testing after hearing that.
I noticed when changing some options, more specifically the "Save GE screen to Textures instead of Memory" needed to be turned off in order to emulate the cursor correctly (other options didn't affect the cursor issue). Would it be possible to save the GE screen to Memory in PPSSPP? Just curious.
@unknownbrackets commented on GitHub (May 12, 2013):
It may be possible using e.g. glReadPixels. That's #618. Doing it too often could cripple performance.
-[Unknown]
@HermitCrap commented on GitHub (Jun 24, 2013):
Is there a way to fix this? Or is it possible to make a beta version with the glReadPixels and test it out since the newer versions of PPSSPP is now pretty stable? The performance is also pretty good, maxed out settings getting 60VPS thought I disable them all as there are graphical glitches in some other games except for V-Sync to prevent tearing. I referring to turning off the "Save GE screen to Textures instead of Memory" for the beta inclusion of course.
@CPkmn commented on GitHub (Jun 24, 2013):
Actually there is something interesting about this case.
PPSSPP works for Danganronpa's Nonstop Debates (demo and full version), but not when investigating/exploring.
Yes, the GE screen->Memory (disabling save GE screen to Textures) seems to be the solution. I would work on implementing that, but I'm not exactly sure where it would go in PPSSPP's coding. I know where to find it in JPCSP's coding though.
Just started a nonstop debate in PPSSPP on the full version ~
(Don't mind the red square; I don't want to spoil who died since there will probably be many new players because the translation was very recently released)
@HermitCrap commented on GitHub (Jun 24, 2013):
LOL, I accidentally spoil myself with who the mastermind is even before I played the game when I was reading the player profiles on the wikia -_- Will take a look at the source and continue the talk in thread #618.
@ghost commented on GitHub (Jun 24, 2013):
For the Nonstop Debates, I think the game uses its own rectangular hitboxes. After all, it's possible for the user to fire the bullet at a small crevice in the middle of the text glyphs, and I believe that that counts as a hit.
@HermitCrap commented on GitHub (Jun 24, 2013):
I believe it's more like an entity. Like an enemy in a game that will interact with you unlike the investigation which uses "pixel detection" since it's part of the background. Since the words will move around in the debate unlike the items which stay in place like the background or doors etc thus being unable to interact as well. The only way to fix it is to implement #618.
@arnastia commented on GitHub (Jun 25, 2013):
I took a stab at this and I seemingly managed to fix the problem basically by calling glReadPixels whenever a framebuffer object was either displayed (in FramebufferManager::CopyDisplayToOutput()) or switched for a new one for rendering (in FramebufferManager::SetRenderFrameBuffer(); Danganronpa draws a certain FBO every frame but never actually displays it) and Memcpy'ing the results to the address the game expects them to be in. Since just calling glReadPixels won't yield the correct results when the user's playing in a larger render resolution, whenever needed I use a separate, native resolution FBO blit'd with glBlitFramebuffer to resize the render and get glReadPixels to return the correct data (well, likely not as correct as if it were originally rendered 1x, but at least for 2x linear filtering seems close enough).
While I didn't really try to measure it, I have a feeling this did have a slightly noticeable negative impact on performance (just doesn't seem to flow as nicely?). Framerate-wise the game seems completely playable, though I only tried it on a fairly decent desktop PC. Eitherway, this is a hackish fix, but should keep folks wanting to play the translation happy.
I didn't post this in #618 for now since though the end problem is the same, the approach I took is slightly different because Danganronpa doesn't call sceDmacMemcpy.
I'll get around to pushing the branch online tomorrow, since it's fairly late here right now.
Other than this, the game seems to have two other problems, that would probably be better off on different issues, but I'll just list them briefly here:
@HermitCrap commented on GitHub (Jun 25, 2013):
I believe the voice problem is an issue with the atrac3+ plugin as the sound in other games that require it sounds horrendous. This problem can be ignored for now until someone comes up with a better atrac3+ option since the Devs do not want to use the current plugin. The displayed message is fixed for me when I enable buffered rendering for some reason. I only get them when I fast forward it to unlimited, I would then have to rest the game for it to work. Looking forward to your build, I shall test them for you as well. Cheers! :)
@unknownbrackets commented on GitHub (Jun 25, 2013):
Copying to memory all the time is definitely gonna have a performance impact. I think we need to find a smarter method.
The gibberish is the texture cache. It corrects itself, and notes that those textures are "annoying." There might be options to improve its detection.
I think this game also uses that atrac context thing, so it will probably be helped when Sol Trigger et al are.
-[Unknown]
@CPkmn commented on GitHub (Jun 25, 2013):
@unknownbrackets The game does use _sceAtracGetContextAddress for its voices.
Interestingly, I notice some values JPCSP sets in memory during _sceAtracGetContextAddress that PPSSPP doesn't yet. I was thinking of getting around to checking them out soon, but I haven't missed any voices while playing the debates in the demo and full version so far (although the voice volume is a little lower than it should be - that might just be my problem though since I don't use the same sceAtrac as you guys anymore).
@HermitCrap commented on GitHub (Jun 25, 2013):
@CPkmn, Can you tell me how to get the custom sceAtrac you got? I think it's alright if it is soft as most Android device can't handle the extreme loudness of most game, Oreimo give my speaker tearing to the point I stop playing it. Playing it on the PC on the other hand is alright. Still, I rather have working sound than loud sound.
@unknownbrackets, I think it's alright to retain this idea for now right? At least for experimental PC builds since most texture in 3D games also save their Graphics to VRAM. I think it will only affect the performance on Android device. Since the above method only works ideally when on 1x Rendering Size, I believe the performance won't be too big. Maybe you could try implementing it and experiment with it? Since this can fix some games at the moment.
@hrydgard commented on GitHub (Jun 25, 2013):
If copying to memory every frame is what it takes, then we might just have to do it. It will probably make things unplayable on many mobile devices so we might have to do it as a per-game option, when I add support for that...
@fagoatse commented on GitHub (Jun 25, 2013):
It could be implemeneted as a hack. However, if this function is used extensively in many games, a multithreaded software renderer like in pcsx2 would solve majorty of gfx issues and would be fast enough on modern x86 cpus. Displaying at the native resolution only isnt much of drawback either as there are many 2D games or games that scale poorly(3D on 2D background etc).
@CPkmn commented on GitHub (Jun 25, 2013):
@HermitCrap I've been working on modifying things in my local copy for about a month now; you can't find it anywhere since I haven't released it, nor should you guys need my local copy since there is already a working version in the master.
I just prefer mine is all.
Anyways, what I mean by "I don't miss any voices" is all voices have played for me so far, and just about all of them play fully, but a select few cut off a few words early (but they do play).
Also, I tried implementing memory writes in _sceAtracGetContextAddress according to JPCSP but I didn't notice anything different.
@hrydgard commented on GitHub (Jun 25, 2013):
@fagoatse yes, adding a software renderer is also solution that will work, although that's a lot more work than glreadpixels and an extra fbo.
@HermitCrap commented on GitHub (Jun 25, 2013):
@CPkmn, For me, It's when I skip a dialogue, the voice just stop playing for the whole game until I reset even for the master version. I think you should consider implementing your copy as the main for the coming release :P Software rendering will make games like Dangan Ronpa work and not suffer so much for Android device. But I still think that implementing this for experimenting should be a good idea just for the PC and Super Duper High Sch... End Device! The best way to do this now is to either make a per-game option or a GE Profiler now.
@CPkmn commented on GitHub (Jun 25, 2013):
@HermitCrap you mean like if you press X in the middle of the sentence, no more voices will play? Anyways, I have no intention of committing my modifications of sceAtrac (at least, not the majority of them). Most of what I've done no longer applies to the master since I don't use Mai's AT3+ decoder.
@HermitCrap commented on GitHub (Jun 25, 2013):
@CPkmn, Yeah, that's what I meant. How did you get the sounds to work without the decoder? SoundSonic? Mai's AT3+ Decoder is pretty buggy. Seems like I just gotta wait for someone to make another from the source and not Whitebox Reverse Engineer it.
@CPkmn commented on GitHub (Jun 25, 2013):
@HermitCrap Mine works perfectly when I do that. I have a special trick for decoding my atrac3(+) sounds, but like I said, mine isn't the same as the master. Some of the methods I use have either been removed or have changed in the master while I was working on mine.
@HermitCrap commented on GitHub (Jun 25, 2013):
@CPkmn, can you upload your copy of the source to your PPSSPP Repository/fork or make a pull request to Hrydgard's repo? I your coding for the sound will be beneficial to the devs and users since Mai's decoder is rather unreliable.
@CPkmn commented on GitHub (Jun 25, 2013):
@HermitCrap You mean my version of sceAtrac, right? I can't pull request my copy of the game (and, well, it would be illegal if I did). The version I've been working on may be better for some things, but I only intended it to be personal - that is, the code doesn't contain comments (or, nothing besides the ones left originally) and is sorta messy. I'm not interested in having a lot of questions to answer if I was to send a pull request with it (and I'm sure there would be questions upon being reviewed). I don't see it as a priority since you guys already have a way to listen to sceAtrac music. :p
Also, I just added arnastia's fix to my local copy and I can confirm it works.
I don't notice any lag either.
@lKomus commented on GitHub (Jun 26, 2013):
Using PPSSPP 0.8.1-37 with framebuffer with memory on, I can examine items in Investigation Mode, but not all the items you examine are the right ones, like you want to examine the drawer but you end examining a lint roller.
This prevents progression very early in the game in chapter 1 where you must examine everything in your room, but no matter what you do, you can't examine your drawer.
Link for the save : http://www.mediafire.com/?mjzbhfdvrecycu2
@arnastia commented on GitHub (Jun 27, 2013):
Well, I know you can get past that because some people I compiled the code for before I even pushed it here had already got out of the room. I'm writing some changes to the code, but I tried your save right now and on my version I can examine the drawer.
What I'm guessing can happen is the blitting of the framebuffer to a smaller resolution giving edges weird values because of the filtering, which should only happen if you were playing at 2x or above render resolution. Try to either play at 1x render resolution when that happens or maybe just change the viewing angle or position of the cursor a little.
@Zindolence commented on GitHub (Jun 27, 2013):
I'm encountering the same problem as lKomus (as well as several other people from various forums).
I tried to play at 1x render resolution, then disabled every option in graphics save for buffered rendering (since it's required for your fix), and finally tried V-sync on. None of those worked, and I reloaded my save before each try. I deactivated anti-aliasing/anisotropic filtering/texture scaling as well.
On top of the room IKomus mentioned, I met another instance where the locations of items were wrongly swapped. In the prologue, after the first classroom, when you're in the hallway trying to enter the toilet doors will point to wrong locations. About the investigation part with the drawer sending you to the lint roller : changing the camera angle unfortunately doesn't help. I even tried to point the cursor everywhere on the screen, including blank spaces, but the game never seems to find the drawer.
I haven't gone further than chapter 1 but there might probably be other similar instances. The same bug happened on JPCSP as well, and temporarily switching to software rendering was the only solution.
If that is of any indication, I am using rev v0.8.1-41-ge440fa6 on Win8 64Bit, with an AMD HD7850 video card and an i3 3220 processor. I'm suspecting this bug might have to do with hardware since some people are unaffected.
@HermitCrap commented on GitHub (Jun 27, 2013):
@Zindolence, this problem seems to be with AMD cards though I'm not really sure. The only workaround is like what arnastia said, play the game in 1x resolution.
@Zindolence commented on GitHub (Jun 27, 2013):
As I mentioned, I tried that and it doesn't fix the problem. I even started a new game (with 1x render res without texture scaling) and skipped everything until the bugged parts to be absolutely sure.
@HermitCrap commented on GitHub (Jun 27, 2013):
I will try it on both AMD and Nvidia and confirm whether it's just a problem with AMD Cards.
@lKomus commented on GitHub (Jun 27, 2013):
I do have an AMD card, an ATI Mobility HD Radeon 5850M.
Still not working at 1x render resolution even by mixing some graphical options.
It's a shame if it's related to the AMD Drivers.
@HermitCrap commented on GitHub (Jun 27, 2013):
I don't know how you guys can even get to interact with the options but the newest few dev builds doesn't work for. Interaction doesn't work, have to rely on a build uploaded on the translation site in the comments. That worked for me, the translators think that it is related to AMD Cards.
@lKomus commented on GitHub (Jun 27, 2013):
You must set "FramebuffersToMem = True" in ppsspp.ini.
@solarmystic commented on GitHub (Jun 27, 2013):
@HermitCrap
Also. use your machine equipped with a NVIDIA card to try it out. AMD cards apparently have issues even with this fix. Crappy AMD OGL drivers are to blame.
@HermitCrap commented on GitHub (Jun 27, 2013):
@lKomus, so Hrydgard really add the option to turn it on like I requested. Was wondering why I can't find it :P
@solarmystic, am gonna try it now.
@HermitCrap commented on GitHub (Jun 27, 2013):
The game worked flawlessly on my Nvidia Machine, the doors are mapped correctly, lint roller to lint roller. Shall try it with my AMD Build later since my brother is using it now.
@HermitCrap commented on GitHub (Jun 27, 2013):
AMD Card have that issue. It appears that the bug where the items are switched all over the place only happens on an AMD Computer. There is no way to check if Android will work since you can't turn on buffering to memory.
@lKomus commented on GitHub (Jun 27, 2013):
I wonder if something like this can even be fixed for AMD cards, it's not the emulator's fault.
@HermitCrap commented on GitHub (Jun 27, 2013):
Then I guess people should get up and just get a PSP to play this game :P
@solarmystic commented on GitHub (Jun 27, 2013):
Add this game to a list of games unplayable on AMD's cards thanks to the their crappy OpenGL driver support.
That makes it 2 games now, this game and Final Fantasy IV The Complete Collection (BR OFF and still no text displayed, while NVIDIA cards get text displayed when BR is OFF https://github.com/hrydgard/ppsspp/issues/2018)
Perhaps I should make a new topic in the forums for this.
EDIT:- Tekken 6 is another one. Really horrible performance on AMD/ATI cards plus constant freezes when punches and kicks are connected with the opponent, unless you disable Hardware Transform.
That's right, turning Hardware Transform OFF in Tekken 6 actually improves performance(!) for AMD cards.
NVIDIA cards fly in that game, even with HT on.
@HermitCrap commented on GitHub (Jun 27, 2013):
It's not exactly unplayable, please do mention only AMD cards can't play it. I believe there is a way to fix it, and it is to edit the OpenGL itself or look for better driver support.
@HermitCrap commented on GitHub (Jun 27, 2013):
I believe the only way to fix this for now is to include DirectX support as an alternate renderer. Anyone think it's possible?
@solarmystic commented on GitHub (Jun 27, 2013):
@HermitCrap
There was a suggestion in the builds section of the forum to incorporate a DX Renderer.
http://forums.ppsspp.org/showthread.php?tid=2399
No one's stepped up to the plate as of yet. It seems to be on the lowest of priorities now, since it's only really useful on Windows, and this is pretty much a crossplatform emulator which is why OGL was used in the first place. (Since mobiles can only really use OGL ES at the moment.)
@HermitCrap commented on GitHub (Jun 27, 2013):
Yeah, but since OpenGL will give problems for AMD users which is also a significant amount of users and that frame buffering to memory doesn't work for Android. I think incorporating a DX Renderer as an alternative for PC will be a good move for PPSSPP Devs as it means it will eliminate some problems.
One question, if DirectX is not included. Why do we need DXSDK to compile the source? O.o
@solarmystic commented on GitHub (Jun 27, 2013):
@HermitCrap
Native 360 controller (Xinput) and Dinput support. Amongst other things, I think.
A DirectX redist and VC++ redist installation is pretty much mandatory to run the emulator in the first place for the end user..
@HermitCrap commented on GitHub (Jun 27, 2013):
@solarmystic, I saw this post in the forum "http://forums.ppsspp.org/showthread.php?tid=3289". Do you know how to install this "QindieGL"? I would like to try this and see if it works for me.
Ohhh... That explains it.
@lKomus commented on GitHub (Jun 27, 2013):
From the qIndieGL site it seems not all functions of OpenGL are supported including glReadPixels that is partially supported.
@fagoatse commented on GitHub (Jun 27, 2013):
I dont think any wrapper will work correctly. Has anybody tested intel's iGPUs such as hd 2000 and onwards? They are probably broken as well(unless intel got their shit together).
There's a universal solution in the works right now btw - https://github.com/neobrain/ppsspp/commits/softgpu
@HermitCrap commented on GitHub (Jun 27, 2013):
I believe what it does is that it "emulates" a GPU, I'm not really sure. But if it's really an universal solution, then we can consider it as a "software renderer" or he needs to support it for all GPU.
@Kratata commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
@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 commented on GitHub (Jun 27, 2013):
its possible that amd lied about their opengl specs or you guys are using some ancient cards/drivers.
@HermitCrap commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
ATI Mobility HD Radeon 5850 with 13.6 Beta 2 Catalyst drivers, so not a problem of old drivers.
@arnastia commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
"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 commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
@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 commented on GitHub (Jun 27, 2013):
@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 commented on GitHub (Jun 27, 2013):
This is the screen shot from all the way at the bottom. The spamming starts from 23:44:200 until 24:50:628.
@arnastia commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
Can you upload it on Mediafire and let AMD Users try? I have problem building the program since yesterday.
@arnastia commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
Will try it tomorrow since it's like 2 o'clock midnight here.
@Kratata commented on GitHub (Jun 27, 2013):
^ 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 commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
@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 commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 27, 2013):
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 commented on GitHub (Jun 30, 2013):
@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 commented on GitHub (Jun 30, 2013):
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 commented on GitHub (Jun 30, 2013):
@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 commented on GitHub (Jun 30, 2013):
Oh, my bad. I saw FX-8320. Still, the HD6410D still isn't gonna help.
@arnastia commented on GitHub (Jul 1, 2013):
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 commented on GitHub (Jul 1, 2013):
Nice work, can't wait to see it go live.
@arnastia commented on GitHub (Jul 1, 2013):
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 commented on GitHub (Jul 1, 2013):
thanks @arnastia
Will test your solution on my Legacy ATI card (Mobility Radeon 4670)
@unknownbrackets commented on GitHub (Jul 1, 2013):
@arnastia something similar happened for FF4 (see #2577), but it may also depend on settings. Can you try running a
git bisectto 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:
When using
glReadPixels(), the following are probably equivalent, and we can both guess which one is slower:Similarly with
ConvertFromRGBA8888():fb_addressis just an unmapped pointer. It points to real memory when offset byMemory::baseorMemory::GetPointer(), andMemory::Memcpy()just does amemcpy()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.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?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 toConvertColors()also.)For the setting, I suggest FramebufferCPUConvert or something, it's kinda generic as just "cpu convert".
-[Unknown]
@arnastia commented on GitHub (Jul 1, 2013):
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 commented on GitHub (Jul 1, 2013):
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 commented on GitHub (Jul 1, 2013):
Oh, and is the slow video also present in the demo version? Is it easy to get to?
-[Unknown]
@Reversalf commented on GitHub (Jul 1, 2013):
@arnastia How do I use your build though?
@solarmystic commented on GitHub (Jul 1, 2013):
@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 commented on GitHub (Jul 1, 2013):
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 commented on GitHub (Jul 1, 2013):
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 commented on GitHub (Jul 2, 2013):
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 commented on GitHub (Jul 2, 2013):
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 commented on GitHub (Jul 2, 2013):
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 commented on GitHub (Jul 2, 2013):
Shall try it out when I'm free.
@l3illyl3ob commented on GitHub (Jul 2, 2013):
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 commented on GitHub (Jul 2, 2013):
@l3illyl3ob
Thanks for the report, thats nice to hear that it's working for modern AMD cards too.
@lKomus commented on GitHub (Jul 2, 2013):
@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 commented on GitHub (Jul 2, 2013):
@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 commented on GitHub (Jul 2, 2013):
@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 commented on GitHub (Jul 2, 2013):
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 commented on GitHub (Jul 2, 2013):
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 commented on GitHub (Jul 3, 2013):
@lKomus
Yep. Which is what the CPUConvert function when used together with the FramebufferstoMem function fixes in @arnastia's experimental build.
@JustaPeriod commented on GitHub (Jul 3, 2013):
Another confirmation, the FramebuffersCPUConvert and FramebufferstoMem on AMD cards seems to fix previous issues reported. I have an AMD 6850. Investigating working fine.
@solarmystic commented on GitHub (Jul 3, 2013):
@Tittiez
Thanks for the confirmation. So that's 2 confirmed success stories so far. One on my legacy 4670 card and one on a much more modern 6870 card.
@Leacero commented on GitHub (Jul 3, 2013):
Can you post up a build of it that's already compiled? I'd like to test it, but I'm not sure how to clone/compile it on my own. I have a Radeon 5850.
@JustaPeriod commented on GitHub (Jul 3, 2013):
@Leacero Sure, give me a few minutes to upload.
@JustaPeriod commented on GitHub (Jul 3, 2013):
@Leacero I think this will do it:
https://docs.google.com/file/d/0B1myg_QircHaVXNJbTU1bms1NHM/edit?usp=sharing
Not sure if it works on other computers yet.
@lKomus commented on GitHub (Jul 3, 2013):
Tested with the build you uploaded and it works ! I can examine the drawers and finally continue.
Thanks to arnastia and Tittiez !
@Leacero commented on GitHub (Jul 3, 2013):
Thanks! So far it's working well, got past the initial roadblocks in Chapter 1. I'll keep playing and let you know if there are any other problems that come up. Again, I'm using a Radeon 5850.
@solarmystic commented on GitHub (Jul 3, 2013):
@arnastia
Judging from the replies, this does seem to be the magic fix we've been waiting for.
@jcw005 commented on GitHub (Jul 3, 2013):
Radeon 7950 here. Works perfectly so far (in all the formerly problematic areas). Fantastic job debugging this.
@arnastia commented on GitHub (Jul 3, 2013):
Well, good to know, but I didn't quite get if anyone got it working without CPUConvert/FramebuffersCPUConvert (meaning only FramebuffersToMem = True) on AMD/ATi.
As for Android, I'm still trying to find the sweet spot on that one (haven't made the pull request because of this). I think I have a pretty good idea about what I'm doing wrong, but it's hard to be sure when I don't have a single OpenGL ES device to test this on. Only test I did of the OpenGL ES version of the code was on my PC, and it worked, but if no objects were even detected then I have to try switching channels around some more.
@NewDCD commented on GitHub (Jul 3, 2013):
@arnastia To my understanding, the Nexus 7 has OpenGL ES, being an Android device. If you can compile a build for me, I can test if it work, since I have superuser access on the 7 and thus can edit the .ini files. Come tomorrow I could have a report for you.
@jcw005 commented on GitHub (Jul 3, 2013):
Edit: Sorry, turning off FramebuffersCPUConvert makes things stop working.*
@solarmystic commented on GitHub (Jul 3, 2013):
@arnastia
I assume all the positive responses are with FramebuffersCPUConvert = True and FramebufferstoMem = True.
The CPU conversion is still necessary with your provided build.
@alyosha-pushak commented on GitHub (Jul 3, 2013):
I switched to using the new build with FramebuffersCPUConvert, and something is broken that's wasn't broken before. However, I can confirm it's not the CPU convert fix that broke it, as it's also broken in the last PPSSPP build (8.1.220). In the 4th chapter, the game freezes when the corpse discovery announcement is about to be made, and it gets passed this on the old build I was using (8.1.74). I guess I can try isolate exactly when this broke. I've also run into problems like this I haven't seen anyone else reporting. For instance, at the start of the trial for chapter 1 and 3, after choosing "finish preperations" the game froze using 8.1.74. I've been using JPCSP to get passed these parts.
@solarmystic commented on GitHub (Jul 3, 2013):
@alyosha-pushak
It'd be very helpful if you provided a savefile made right before the freeze so that @arnastia and the rest of us can figure out what went wrong.
@alyosha-pushak commented on GitHub (Jul 3, 2013):
I've determined that it's not an issue with a particular build. The following behaviour appears to be consistent in any build passed 8.1.74:
Load game -> Load save -> get to corpse discovery announcement -> game freezes
Load game -> Load savestate -> get to corpse discovery announcement -> works ok
Load game -> Load savestate -> Load save -> get to corpse discovery announcement -> works ok
Because the 3rd path works ok and that's how I first tested it on 8.1.74, I thought it had something to do with the builds, but it does not. If anyone wants to test it, you can get the save file and save state here:
https://docs.google.com/file/d/0B_OtR-yWg6u_R1FaSEVHaVJLTEE/edit?usp=sharing
This will spoil who the victim is in chapter 4 is, if anyone is concerned about that.
@SonnyChilds commented on GitHub (Jul 3, 2013):
Trying to get this going, just installed what Tittiez compiled, trying to mash O back to his room.
It'd be great if anyone could post a savefile from just before that for those playtesting this OpenGL bug.
EDIT: I recovered the save files that I previously stupidly deleted. Will upload if anyone needs the post-Prologue save.
EDIT #2: So far so good, I'm on day 4, no problems yet.
EDIT #3: For what it's worth, I've got an AMD HD7750. Everything seems to be running borderline perfect now, with the exception of some of the cut-scenes slowing down, as arnastia described above. I'm beginning Chapter 2 right now, and by the way...thank you to everyone here for fixing this stuff. The game is fantastic.
@arnastia commented on GitHub (Jul 3, 2013):
Yeah, sorry, but issues with anything past free time chapter 2 and you'll have to wait for me to get there (assuming it's something I've been messing with). Needless to say, I really don't want to be spoiled on a game like this.
I'm however pretty sure you can finish the game on an Nvidia, at least with the old version of my fix, since I know people who actually have.
@JustaPeriod commented on GitHub (Jul 4, 2013):
Thought people might like to know, I experienced a crash at the the ballot. Luckily. I had a save state and only lost 2 minutes worth of work. The 2nd time I tried it didn't crash. I'd advise to make a savestate shortly before you know the ballot will be cast.
@lKomus commented on GitHub (Jul 4, 2013):
I finished Chapter 2 yesterday and had no crashes so far. Is this on chapter 4 ?
@bneundh commented on GitHub (Jul 4, 2013):
So I downloaded the one tittiez uploaded and I can't get past the first room .then I enabled buffered rendering but it lags very much .using windows 7. what gives ?
@HermitCrap commented on GitHub (Jul 4, 2013):
@bneundh, disable all other video options or simply get a better GPU.
@arnastia commented on GitHub (Jul 4, 2013):
Ok, so I pushed another try to my repository. Would appreciate it if anyone could test it on AMDs (with and without FramebuffersCPUConvert = True) and Android (FramebuffersCPUConvert changes nothing on this one).
If nothing's wrong with the AMD version I'll make a pull request later today. If the Android version still doesn't work, well, I'll probably only fix it when I can get my hands on a rooted Android device. I'll also look into doing things in SSE/NEON later.
Repository: https://github.com/arnastia/ppsspp
And a x86 build for those with AMD cards: https://dl.dropboxusercontent.com/u/3475202/PPSSPPWindows.zip
I'd post an Android build, but don't have the tools to compile it right now.
EDIT: PS, you still need FramebuffersToMem = True on both of them, and the slow video bug isn't fixed in these builds. Just use turbo/start to get past it.
@JustaPeriod commented on GitHub (Jul 4, 2013):
@arnastia I can't comment on the entire game, but I'm in my room right now just at the start of the 3rd Chapter with FramebuffersCPUConvert = False and I can still investigate things fine.
AMD 6850
I haven't tried it with my older build, but at least the newer build doesn't seem to need it for AMD GPUs. Good job!
@bneundh commented on GitHub (Jul 4, 2013):
now when I enabled buffered rendering it just freeze . I must have done something wrong ..
@JustaPeriod commented on GitHub (Jul 4, 2013):
Actually yeah, I found a few problems I haven't noticed before. I'll post them, hold on.
@JustaPeriod commented on GitHub (Jul 4, 2013):
I'm aiming at my door from a far away distance, yes? If I press X, it takes me into the BATH.
And another one:
If I press X right now on Kirigiri's room, it'll take me into MY room.
I should be too far away from the rooms I'm aiming at for that to even show up.
This is with FramebuffersCPUConvert = False
would you like to to test True as well?
@arnastia commented on GitHub (Jul 4, 2013):
Just to be clear, that's with FramebuffersCPUConvert = False, right? With FramebuffersCPUConvert enabled everything should still work.
If so then Nvidia and AMD probably interpret the type parameter in glReadPixels differently, and there isn't much I can do other than add an option to assume either AMD or Nvidia card (or is there some way to detect which card the user has?). Otherwise just keep FramebuffersCPUConvert enabled.
@unknownbrackets commented on GitHub (Jul 4, 2013):
@arnastia in the worst case, we can get the vendor and do something differently based on it. Should be no reason to ask the user if they are using AMD/ATI, since their video card can answer that question for us.
I wonder if anything is being returned in glGetError()?
-[Unknown]
@JustaPeriod commented on GitHub (Jul 4, 2013):
@arnastia Yes, that is with FramebuffersCPUConvert set to False. Setting it to True seems to fix the issue.
@Abalieno commented on GitHub (Jul 4, 2013):
Is it a known problem that texture filtering isn't working properly? It seems to get randomly deactivated, and sometimes you can reactivate by switching it off and back on.
I guess it's a side-effect of the fix.
@SkipXX commented on GitHub (Jul 6, 2013):
ok, i know this is the wrong place to ask, and if you can tell me where to ask stuff like that pls do, but anyway:
I would like to know how to build this projekt. I have basicly no real knowledge of C++ or programming, but i do know what building is for and so on... i've installed GitHub, Visual Studio and everything i need to have installed (i think, at least)...
now i only have the problem that the native library does not load... and i am not totally sure that i understood:
"First of all, after having checked out the source, don't forget to run:
git submodule update --init
in order to get the "native" library."
because it does not work
as far as i understand, i have to open a shell in the repositorie and then enter "git submodule update --init"
i did that and it looked like it worked but it didn't solve the problem, i still couldn't load "native" in Visual Studio (everything else works i think)
edit: Well, the thing is, i do not get an response from the command and nothing changes, but thanks, i hope i'll figure it out on my own anyway :P
@unknownbrackets commented on GitHub (Jul 6, 2013):
Better to ask stuff like this on the forum. Remember to run the command inside the directory you cloned ppsspp into. Post in Development (ideally with whatever error message or response from that command you're getting, etc.) and I'll look a bit later.
-[Unknown]
@khoin commented on GitHub (Jul 8, 2013):
I'm running PPSSPP on my Android 4.0.4. Is there any solutions to this? If there already is, can anyone link the comment?
Thanks,
(also, please @mention me)
@HermitCrap commented on GitHub (Jul 8, 2013):
You must root it if I'm not wrong. Use a computer instead, it's going to lag a lot anyway.
@khoin commented on GitHub (Jul 8, 2013):
@HermitCrap I doesn't lag much on my phone (not after I go change a lot of configurations to find out how to fix this issue (of course didn't work)). But it's always more enjoyable playing on consoles because using a PC to play games or watch movies always makes me feel unproductive and irritating :)
@NewDCD commented on GitHub (Jul 8, 2013):
If you have an Android PPSSPP Build with the fix integrated to the code, you need to root and then use an app like "Root Browser" to access the hidden app files within Android/Data/Data/PPSSPP. From there all you have to do is switch the pertaining values from "False" to "True" within ppsspp.ini with an Android text editor.
If you do have a compiled PPSSPP build with the CPUConvert fix, hook me up, will ya? My Comp has been pretty weird lately. RAM problems, maybe the connectors. Want to avoid using it much if I can help it.
--- Original Message ---
From: "potasmic" notifications@github.com
Sent: July 7, 2013 10:12 PM
To: "hrydgard/ppsspp" ppsspp@noreply.github.com
Cc: "NewDCD" diegoj10@hotmail.com
Subject: Re: [ppsspp] Danganronpa bug (#1686)
@HermitCrap I doesn't lag much on my phone (not after I go change a lot of configurations to find out how to fix this issue (of course didn't work)). But it's always more enjoyable playing on consoles because using a PC to play games or watch movies always makes me feel unproductive and irritating :)
Reply to this email directly or view it on GitHub:
https://github.com/hrydgard/ppsspp/issues/1686#issuecomment-20583731
@SonnyChilds commented on GitHub (Jul 8, 2013):
Alright, I've made it to Chapter 5 and cannot continue. I'd like to go into detail on where the crash is, but I don't want to give away spoilers. Basically, at a certain point of dialog, the screen fades to white and PPSSPP simply stops working.
Is there an error log that I can copy/paste here?
@MegaPear commented on GitHub (Jul 8, 2013):
Hey I'm experiencing a problem extremely similar to Kwazzi's. The only difference is that mine happens in chapter 6. (Not to be rude but are you sure it is chapter 5 kwazzi?)
So like kwazzi I am wondering if there is something I can post like a save file or error log.
@SonnyChilds commented on GitHub (Jul 8, 2013):
@MegaPear
Is it after Kirigiri says a line in the bath changing room? I might be mistaken on the chapter, it's happening during an exchange with Aoi.
@MegaPear commented on GitHub (Jul 8, 2013):
Yeah, that's when it happens.
@JustaPeriod commented on GitHub (Jul 8, 2013):
With me as well, after the flashback to Kirigiri's dialog in the bath, the screen fades to white and then the emulator crashes.
@peleides commented on GitHub (Jul 9, 2013):
If you're crashing in chapter 6 during a conversation with Aoi in the data processing room (specifically at the Kirigiri flashback) try turning off Hardware transform in the options menu.
Turning off hardware transform let me continue past that section.
@SonnyChilds commented on GitHub (Jul 9, 2013):
@peleides
Good call, thanks for the tip. Works perfectly.
@solarmystic commented on GitHub (Jul 9, 2013):
@peleides
Excellent advice. Will add that to my thread in the forums.
@HermitCrap commented on GitHub (Jul 9, 2013):
Just tried playing PPSSPP on my AMD Build, the performance hit is really big with FrameCPUConvert on. Since PPSSPP starts to stutter a lot when loading or when you open the ElectroID. Other than that, it works fine. System Specs: I5 - 4670K with HD 7870 PCS+ Must Edition. I suspect the stuttering have something to do with my slow hard drive but yeah.
@JustaPeriod commented on GitHub (Jul 9, 2013):
@HermitCrab it doubt its your cpu or gpu, because it runs full speed for me and I have a Phenom ii x4 955 and a 6850.
Are you sure you are using a dev build?
@dbz400 commented on GitHub (Jul 11, 2013):
humm that's mean only SW T&L works only in chapter 6 , just wonder any log during crash ? we may be able to debug it.
@hrydgard commented on GitHub (Jul 11, 2013):
Yeah that is weird, I don't know any other cases of HW T&L causing crashes...
@MB48 commented on GitHub (Jul 12, 2013):
I am using a version of PPSSPP posted earlier here. (Version by @Tittiez http://puu.sh/3B7qB.png)
I am at chapter 5, everything works perfectly fine thanks to that version. (Normal PPSSPP made it impossible to select objects with the crosshair)
HOWEVER, the game's screen fades to black, and then nothing happens anymore, making it impossible for me to continue playing this game.
When this happens (may contain spoilers, but I don't think so):
Monokuma act XVI, monokuma shows a video of another game. After the video ends, he says
"This is the era of ninja! Samurai are a thing of the past!"
"By the way, why didn't I get an offer?"
"I'll buy it anyway, though!"
"I'll buy -two- copies! grin"
(Screen fades to black)
"Diiiing doooong...
Diiiing doooong..."
(I press X, Screen fades from black to your room)
(after a second it fades from your room back to black)
(It stays like this forever, the buttons are completely unresponsive and nothing ever happens)
I use a radeon hd 6970. (ati)
I attached a .gif of the issue:
I hope someone knows how to fix this, I really don't want to stop playing here.
Oh and, good work you guys, thanks for all the effort.
EDIT:
@solarmystic right below me
This fixed the issue, thanks!
The game looks much better too!
@solarmystic commented on GitHub (Jul 12, 2013):
Have you tried using the latest normal PPSSPP builds on Orphis?
The latest ones support the hacks required for this game to select objects:-
http://buildbot.orphis.net/ppsspp/
Don't forget to set FramebufferstoMem = True and FramebuffersCPUConvert = True in the ppsspp.ini file.
AFAIK, these builds let you play normally until Chapter 6, where a certain sequence requires you to disable Hardware Transform for a short while until you get past it.
@MasamuneDate commented on GitHub (Jul 12, 2013):
Everytime I set FramebufferstoMem = True, the emulator crashes when I try to load Danganronpa
@feRfe commented on GitHub (Jul 13, 2013):
I'm playing Dangan Ronpa 2 the sequel now and the issue of being unable to interact with the environment/characters is back. Can't select anything to investigate... yet in the first game the issue is fixed. Does anyone know why and how to fix it?
@CPkmn commented on GitHub (Jul 13, 2013):
@feRfe maybe it requires depth and/or stencil to also be copied to memory (currently only colour is copied), although I haven't done any testing (it's just a guess).
or it might be your graphics card. if you have amd or ati there may be issues.
@feRfe commented on GitHub (Jul 13, 2013):
I can run the first game on the emulator just fine and I have a nvidia card
@yugioh5552 commented on GitHub (Jul 13, 2013):
can someone give me step by step directions on FramebufferstoMem = True and such.....
Edit: I found it but every time i use it ppsspp just crashes
@rendy911 commented on GitHub (Jul 16, 2013):
i have problem with SDR 2 can't interact object and character
how to fix it?
I have set the FramebufferstoMem and FramebuffersCPUConvert to True and buffered rendering on
@CPkmn commented on GitHub (Jul 16, 2013):
@rendy911 my build seems to work fine with interacting with objects and characters in SDR 2.
Not sure what's wrong with the official build though.
@feRfe commented on GitHub (Jul 16, 2013):
how can we usey our build then?
@Nezarn commented on GitHub (Jul 16, 2013):
@CPkmn if your build is better in x games then why dont you upload your source code so that ppsspp devs can see it and fix up the master ? :/
@rendy911 commented on GitHub (Jul 17, 2013):
@CPkmn what's your build?
@rendy911 commented on GitHub (Jul 17, 2013):
my build
@CPkmn commented on GitHub (Jul 18, 2013):
@rendy911 I use a custom build. Unfortunately it's overbright whenever the sun is around (ie on the beach and islands) but it detects people and objects to interact with.
@adhitiyad commented on GitHub (Jul 19, 2013):
I'm playing Danganronpa, now in Chapter 2 Class Trial
until suddenly this appears http://puu.sh/3BQ6a
I've tried to start over but now it always crashed here http://puu.sh/3BQAR
I have set the FramebufferstoMem and FramebuffersCPUConvert to True, but I set off the Buffered Rendering (F5) sometimes because it's laggy, I only used it in investigation.
Btw I use Nvidia and the latest version of PPSSPP (v0.8.1-549-g8eab028)
Do you guys know how to fix this?
Thanks before :)
@ghost commented on GitHub (Jul 20, 2013):
I've been trying to emulate Danganranpa on the latest version of PPSSPP but for some reason no matter what I try, the cursor still won't function properly, either that or it crashes upon startup. If its of any help, my GPU is something from intel; can't remember the specific name
@adhitiyad commented on GitHub (Jul 20, 2013):
I've post my problem here for a week (and repost it three times) and got exactly no response. What should I do? I really need to play this game.
@MB48 commented on GitHub (Aug 3, 2013):
Did anyone get this to work on Android?
On android it works with framebufferstomem, however this cauises the FPS to drop from 60 to 4, rednering it unplayable.
Any way to play this with "Buffered Rendering" enabled?
Talking about the cursor not being able to select objects.
@scraggles80 commented on GitHub (Aug 4, 2013):
@adhitiyad
if you really need to play it
play it on your psp
@woonie commented on GitHub (Aug 6, 2013):
I'm currently on v.0.8.1-125, playing SDGRP2. Both my friend and I couldn't select on this Hidden Monokuma:
as it would cause the desk to be selected instead.
I also face a problem selecting Togami's cottage as it would redirect me to Souda's instead.
Any possible fixes?
@bebis commented on GitHub (Aug 6, 2013):
Er, okay I go through the ppsspp.ini file and I can't find anything that says Framebufferstomem, is something wrong?
@lKomus commented on GitHub (Aug 6, 2013):
@bebis In the newer dev builds, this option is not in the .ini anymore, now you must go in the graphics settings of PPSSPP and either tick Read Framebuffers to Memory (CPU) or (GPU).
@bebis commented on GitHub (Aug 6, 2013):
@lKomus I'm not seeing anything that says that either, do i still need to do something before I go to settings am I missing something?
@lKomus commented on GitHub (Aug 6, 2013):
@bebis I think you've downloaded the official 0.8.1 version, to get the "Framebuffers to Memory" option you need to download a development build, you can find them at the bottom of the download page of the PPSSPP website.
Take the most recent one that you can download for your OS.
@bebis commented on GitHub (Aug 6, 2013):
@lKomus Alright, found that but whenever I try to load Dangan Ronpa it seems to crash immediately after (uugh sorry for asking so many questions)
@lKomus commented on GitHub (Aug 6, 2013):
Weird, that shouldn't happen. Maybe check that you downloaded the x64 build if you have a 64 bits Windows (right click on "Computer" and choose Properties to know if you have a 32 or 64 bits Windows).
Worst-case scenario you can wait for the official 0.9 version which should come out in one or two weeks if it's planned for Mid-August.
@ghost commented on GitHub (Aug 7, 2013):
Yeah, I think I have a problem similar to bebis'.
Right now, I'm using a computer with Windows XP, and it's happening with me.
Thing is, whenever I try using the latest format of PPSSPP, Dangan Ronpa starts - and you know this because of the music playing - it gives me a black screen and refuses to show me any images. When I tried going into the older versions of PPSSPP, like v0.8.1-430-g0019666 or v8.1-370-g87f6d14, instead of it giving me a black screen whenever I attempt to load Dangan Ronpa it'll just crash with a message popping up saying that it's not responding and that a problem has occurred.
My problem isn't about me even trying to get anywhere in the game, it's about me being able to even start the game itself.
@thedax commented on GitHub (Sep 25, 2013):
Should we close the issue, since the game is playable via Read FB to Memory (CPU/GPU)? Or should we keep it open in the hope that we won't need this hack one day?
@hrydgard commented on GitHub (Sep 26, 2013):
It will always require Read FB or softgpu. So closing.
@woonie commented on GitHub (Sep 26, 2013):
So um, is anyone able to help with my issue from 2 months ago? https://github.com/hrydgard/ppsspp/issues/1686#issuecomment-22171683
@lKomus commented on GitHub (Feb 28, 2017):
No.