Blazing Souls Accelate(ULUS10527) missing sprites(probably whole layer)

[DarkD]

ppsspp v0.9.5(official release and checked up to 757).
It looks like this:

And it should be:

Second image is made with Software rendering enabled, though it's unplayable with such low speed that present in SW rendering mode.
It seems same issue is in Blade Dancer(ULUS10124).

[dbz400]

Did you try turn on or off the HW T&L ?

[DarkD]

Nothing helps it, tried to enable/disable every option.

[dbz400]

Wondering if it is depth test issue

[unknownbrackets]

Has this improved? How does it look in the software renderer?

-[Unknown]

[vsub]

I can't try(I'm not home) it but I tried it before with old rev and everything was visible in software renderer
http://forums.ppsspp.org/showthread.php?tid=1384&pid=58075#pid58075

[unknownbrackets]

Okay, that's good to know. So it's probably something to do with buffer copying or something. Could be fixed like Blade Dancer was now.

By the way, is the game good? How does it compare to other tactical rpgs?

-[Unknown]

[vsub]

I can't really say...I'm not big fan of trpg but the game is not bad.

[unknownbrackets]

Has this improved with the recent depth changes?

-[Unknown]

[DarkD]

v0.9.7.1-11-g3dea6fd, no luck

[dbz400]

Yep , this is screenshot
-GLES

-SoftGPU

[DarkD]

So had any clues on fixing this appeared or problem professionally evades being fixed?
Every time I download new build I'm checking, so I know it's not solved yet, the only thing changed(for this game) is that somewhere between 333 and 401 of 0.9.8 video intro and cutscene from perfect became slow, choking.
I know you have tons of different stuff to care with more priority, just wanted to know if you're close to fixing this issue, thanks.

[unknownbrackets]

Has this improved with all the block transfer and etc. changes recently?

-[Unknown]

[DarkD]

Can't see any changes on 0.9.8-1088. Tried all rendering modes with and without "Simulate Block Transfer" option with everything else default.

[vsub]

Still not visible(0.9.9-41 x86 tried with different settings)but in software mode looks either better or the same than before.

[DarkD]

If it helps anything, here's how it looks on DX9:

v0.9.9.1-790 and situation is same as before on OGL.

[zackdreaver]

I have the same problem with d3d9 backend, is there any fix yet?
My current ppsspp build is : ppsspp-v0.9.9.1-1316-gfd1a748-windows-x86

http://s3.postimg.org/52szrrpyr/Blazing_Souls_Accelate_USA.jpg
http://s3.postimg.org/wii29d06r/Blazing_Souls_Accelate_USAA.jpg

[daniel229]

Still not fixed in v1.0.1-857-g08b340f,also have rotation issue,similar to #6736

OpenGL

software rendering

[LunaMoo]

Maybe interesting, or maybe not ~ I was just messing around to make cwcheat hack for this by inverting camera angle as that somewhat works, but from what I noticed this game weirdly seems to have two views from the top and two from the bottom.

Can be easily seen without any hacks by changing the camera position using select button on the first stage after cutscene, default clearly shows the bottom view, higher camera angle will have a z fighting between top and the bottom view and the top camera will show map as it should look(althrough also inverted since it's on the opposite side of the circle to proper "front").

To put it simply it kind of looks like our pi is actually 1/2 pi in hardware mode making this game abusing lots of trigonometry completely crazy;p. Not sure what actually happens, on a side note even after inverting the camera via cwc hack I had to also double the height of characters since they apparently also used some trigonometric functions and were half the size of what software mode shows/how it should look like.

[hrydgard]

There's no trigonometry in rendering at all (all that is done by the game itself first and converted to matrices), just linear matrix operations, so I highly doubt that explanation as it renders alright in software mode... seems more likely to be some mistaken y-flip of the framebuffer data in combination with a bunch of other issues :P

[LunaMoo]

Yeah sorry I'm a scrub when it comes to understanding graphic rendering.:X
When you say "mistaken y-flip and bunch of other issues" it almost sounds easy easy enough to try finding it, but I will pass, no idea how to even start.

For me it's probably easier to mess in game code, breaking stuff is easier than fixing I guess, in the end brings similar results:

althrough I didn't even finished that yet, reading through vfpu instructions is very confusing for me, maybe because most of them start from same letter heh, have to take longer breaks to keep at least partial sanity.;p

[LunaMoo]

This could be closed or renamed, everything works fine, althrough special effects, in general transparent stuff is broken appearing black or gray + some extra artifacts when slow effects are activated.

Disabling slow effects seems to fix it, not really sure what exactly get's broken there. Some of the artifacts that show with it seems like trash data, they're also appearing differently with/without simulate block transfer and while simulate block transfer is activated loading a savestate makes some of them completely black, while pausing/resuming game makes them transparent gray. Weird thing:].

[hrydgard]

Huh, that's really strange.. Well, the main issue is fixed, that has to be a separate one, please report :)

[unknownbrackets]

Could be a framebuf download we don't detect, that's the behavior we'd get. But yeah, new issue.

-[Unknown]

[CarlKenner]

Perhaps this was because you weren't flipping orthographic projection matrices correctly, only perspective matrices. Sorry, I fixed that in passing in PPSSPP VR a while ago, but I forgot to mention it. Orthographic matrices aren't super common because people can use Through matrices instead, but they still occur.

[hrydgard]

@CarlKenner Thanks, makes sense. I assume you mean that we didn't flip all y components of the matrices before while we now do, and this mostly happened to affect ortho matrices.

On a side note, it would be great to get some parts of PPSSPP VR merged into master. Currently not sure about the Oculus-specific stuff due to the GPL issue. I would argue that it would be in the spirit of GPL to allow it though..

[CarlKenner]

Oops, I'm wrong. You were flipping the W components for orthographic, but weren't flipping the Z components used in perspective projections. And also weren't flipping the components for pitch and roll. Anyway, yes, that's what I meant.

Currently PPSSPP VR is horribly broken from that last merge, with inverted head-tracking and inside-out objects, so I'll have to fix that. :-) It's also a bit of a mess and probably breaks other platforms. And I had to bring some missing features over from Dolphin, like default settings for games, but I'm not sure if I did it the best way. It's also not very optimised. And I'm using Visual Studio 2013 because I didn't have necessary lib files for 2015.

Because Oculus switched to a DLL system in Runtime 0.5, I can remove dependencies on the Oculus SDK and just load the DLL and functions at runtime using only my own code, if that will help. The DLL is now part of the operating system and a hardware driver, so GPL shouldn't care about it. And because Oculus removed Extend Desktop mode, there is simply no way to render to the Rift without using their official hardware drivers. I don't think it is any different from linking to XInput, DirectX, Visual Studio, or Windows DLLs. Currently I can build without the SDK and load the 0.5 DLL at runtime, but I still need to implement that for 0.6, 0.7, and 0.8.

I haven't finished implementing OpenVR, OSVR, or VR920 support yet.

[hrydgard]

@CarlKenner

Did have to invert culling, I assume that didn't carry over properly in your merge, that's why things are inside out.

As for fixed game-specific preset settings, which would be appropriate for carefully tuned VR settings, we now have assets/compat.ini which is currently mostly used to work around precision issues around the Z buffer. I think VR settings belong in that system, although perhaps we do want separate ini files per game..

I agree about the linking thing, that you could view Oculus as being part of the required OS to drive the hardware. It shouldn't really be an issue if we now can load the DLL fully dynamically like that.

[unknownbrackets]

I think we should merge in chunks, though, and try to keep it clean. I'm going to be against any hacks that don't have to be hacks.

-[Unknown]

[DarkD]

That's great game is playable now on OGL, thanks! Please don't forget fixing for DX backend too.

[hrydgard]

@unknownbrackets yes, of course.

[DarkD]

Just confirming that now it's fixed on DX backend too, yays! Somebody have lighting speed, for sure.

[CarlKenner]

Game-specific settings doesn't (necessarily) mean hacks. The most obvious example... every game needs a UnitsPerMetre setting, because that information is not present in the game itself as there is no such thing as scale in a game on a screen. But scale is a very important part of VR. The most common value is 1, but other values like 1000, 128, 100, 3.28, 2, etc. are also common, and if you don't get it right then Solid Snake will be more than a kilometre tall, for example.
Other things that are good to know per game are: how far away the HUD should be, what size and angle 2D screens should be, how much depth you should try to extract from 2D screens and HUDs, how 3D objects on the HUD should line up, etc. And sometimes in VR the camera needs to be moved forwards or back for a more comfortable view.
There are also hacks to work around features I haven't implemented properly in VR yet, like viewports, scissor rectangles, screenspace effects, correct z-buffer depth, etc.
And there are CWCheats to disable the game's view frustum culling function, and to make the game run at 60 FPS (although 75 or 90 would be better).

I don't think it was the inverted culling (although that could still be an issue, the background in Beats no longer seems to show up, although other uses of DrawPixels seem to work). I'm just totally abusing the projection matrices for VR, and flipping the matrix before I work my magic on it caused problems. Instead I added a FlipAxis function to the matrix utilities and flip the matrix just before I upload it, which is the correct place to apply it.

compat.ini didn't exist when I added the feature, so I copied Dolphins system and made a Sys/GameSettings folder with ini files named with their ID. Also some of the settings should be tweakable per game for user preference, and for games I haven't made defaults for yet. It also allows me to set default settings per game for other PPSSPP config settings, if needed.

[unknownbrackets]

I'm not a fan of a folder full of a thousand ini files for games that are all shipped with the software and tracking in the repo. It's an ugly system, and it breeds atrophy in maintenance.

And I personally don't want to be anywhere near an issue tracker that has to deal with users using locked cpu speeds and hacks that try to make games sorta run at 60 fps.

-[Unknown]

[hrydgard]

@unknownbrackets I totally agree that we should keep compatibility hacks to an absolute minimum (zbuffer we can't match, Dangan Ronpa, framebuffer reads (our Replacement.cpp is really a bunch of compatibility hacks), and very few other things).

However, VR profiles are different. These games are simply not made for VR at all, and there is no universal way to make them look good. So profiles with settings will be necessary, if we want any sort of plug-and-play capability for VR. These should not be hacks that makes things run, just things like scale factors, FOV changes etc.

But I'm not really sure anymore compat.ini is a good place - if the goal is to keep it super small and managable, that will be ruined by zillions of VR settings.

So we might simply add a /vr_profiles folder.

Again these will not affect how a game runs, it's only parameters for twisting the rendering to match VR goggles.

[unknownbrackets]

No, there are hacks in there like changing the CPU speed and etc. And nothing there convinced me that a repo-managed directory of a file for every single PSP game id makes any logical sense living within the codebase.

-[Unknown]

[hrydgard]

@unknownbrackets Oh, I'm not suggesting to merge all of CarlKenner's fork. And probably not for while, anyway - once it's more mature, we can start figuring out what makes sense. Don't worry.

And we can definitely host the ini files elsewhere, either by submodule or on our server.

[CarlKenner]

It should be obvious why there are "hacks" in there for changing the CPU speed. If the emulated CPU has to do more work per frame, which it might have to if we are rendering more objects that the user can now see but which used to be culled, then the CPU might need to run faster. So far that hasn't really been an issue though, I guess because the GPU or parts we replaced with HLE were the bottleneck, or the culling was more aggressive than it needed to be. Also if we are running at 60 FPS but the game was designed to run at 30 FPS, then the CPU might need to run faster.

"And nothing there convinced me that a repo-managed directory of a file for every single PSP game id makes any logical sense living within the codebase."

Well, it does make obvious logical sense, and it is what Dolphin has always done. It is certainly the kind of thing you want repo-managed.

There's nothing particularly ugly about it. And I don't see how atrophy is any more of an issue than it otherwise would be. Games inherently need specific settings for VR that have to be set manually for each game. I might not be able to create settings for every game, or keep the settings for every game up to date with changes to the emulator, but there's no getting around that fact with alternate methods either. I made it so it shows a number of stars in the bottom right corner of the game's icon to indicate whether it has been configured and tested in VR and how well it works if it has. But perhaps we should consider some way of storing when, or with which version, games were last tested in VR, to deal with atrophy. Git sort of does that, but only when changes need to be made. It may be a job for the wiki or forums though.

The only significant problem is that there is some redundancy. VRCheats, VRStateID, and VRIssues have to be region specific (I think) if I have found cheats (which takes more effort, so most games and regions won't have them). But the other settings should almost always be the same for every region. Dolphin used to just put up with the redundancy, but recently they made wildcard INI files that supported multiple regions. Unfortunately that won't work for us, because there is no commonality between gameids for the same game. So we should start thinking about other ways to eliminate that redundancy. Also, I'm currently saving every VR setting to the INI files, when I could perhaps just be saving which settings are different from the defaults.

"And I personally don't want to be anywhere near an issue tracker that has to deal with users using locked cpu speeds and hacks that try to make games sorta run at 60 fps."
Most people recognise that VR compatibility is a separate thing to normal compatibility. I think we should have a separate issue tracker for VR, or a separate tag for VR issues, or just some way of clearly indicating whether or not the issue is VR specific.