Star Ocean First Departure Character invisible.

[danielcastilhos]

The character are invisible.

[Nezarn]

Turn off buffered rendering (game still not playable, lightblue screen at worldmap.)

[dbz400]

@danielcastilhos , have you tried turn on/off the HW transform ?

[danielcastilhos]

Yes but nothing happened and i tried turning off buffered rendering but the game don't start.

[dbz400]

Humm . will take a look .

[unknownbrackets]

http://forums.ppsspp.org/showthread.php?tid=1783&pid=17593#pid17593

I tried logging the mask, but when I look at the display list it doesn't even use the colortest in the first scene where the character is missing. It does use the stencil test, though.

If I disable the stencil test, the character shows up, but I have no idea what a stencil test is, heh...

        if (false&&gstate.isStencilTestEnabled()) {
            glstate.stencilTest.enable();
            glstate.stencilFunc.set(ztests[gstate.stenciltest & 0x7],  // func
                (gstate.stenciltest >> 8) & 0xFF,  // ref
                (gstate.stenciltest >> 16) & 0xFF);  // mask
            glstate.stencilOp.set(stencilOps[gstate.stencilop & 0x7],  // stencil fail
                stencilOps[(gstate.stencilop >> 8) & 0x7],  // depth fail
                stencilOps[(gstate.stencilop >> 16) & 0x7]); // depth pass
        } else {
            glstate.stencilTest.disable();
        }

-[Unknown]

[hrydgard]

Oh, it's most likely using the stencil test to hide the character behind various things like walls and the cupboard. And since the PSP can write to the stencil buffer by writing to alpha while that just doesn't happen on the PC, that failing might be what's going on...

[unknownbrackets]

Ah, that's probable. You're spot on about the hiding the character bit, that's exactly what it's trying to do.

-[Unknown]

[hrydgard]

I think that writing alpha to the stencil buffer, for the 1 bit stencil case, can be "solved" by rendering everything three times - once normally, second time with alpha test set to <= 128 and stencil set to write 0, third time with alpha test set to >= 128 and stencil set to write 1 (unless other stencil settings are specified.. hmm).

However that would be just horribly slow.

Can possibly also do it as two full screen passes if we can detect the transition between intentionally writing to the stencil buffer using alpha, and using the results. Which sounds tricky, and there's no guarantee there's just a single such transition per frame.

Or just forget about it and implement a software renderer that does things like the real PSP, and use that for games like this...

[unknownbrackets]

Since I was just looking at JPCSP's shader to see if they used rounding, I notice that they do this by doing a texture lookup on the framebuffer texture:

http://code.google.com/p/jpcsp/source/browse/trunk/src/jpcsp/graphics/shader.frag

But AFAICT we can't do that in OpenGL ES.

-[Unknown]

[hrydgard]

It's not allowed in the standard and it for sure won't work on PowerVR due to the tiled architecture, but I know that Tegra does allow it anyway, as does at least nVidia on PC, probably AMD too these days. No idea about Intel.

[hrydgard]

Oh yeah, that shader also reminds me what the popolocrois transparency issue might be about. The PSP has some special blend modes that double the alpha value before computing the blend, like ALPHA_DOUBLE_SOURCE_ALPHA (constant from JPCSP's shader, we have some different name). Should check if that is used.

Those we can't emulate directly but we can fake by pre-doubling alpha in the shader etc. This will not write the correct value to destination alpha but it should be fine in most cases.

[dbz400]

The character should be somehow visible now in buffered rendering mode .

[unknownbrackets]

Only because it's now wrong and ignoring the stencil test entirely (like buffered rendering off did before.)

-[Unknown]

[dbz400]

i see. It is pretty bad. Will take a look how softgpu renders it.

[unknownbrackets]

I haven't been able to understand when/where it's writing the stencil. I'm worried it may be pixel poking or something?

-[Unknown]

[hrydgard]

Could very well be, which would be nasty...

I guess we simply need to speed up the software backend to make that playable, I presume it works there?

[unknownbrackets]

No, it doesn't actually work there either, but it's because it always writes alpha over the stencil I assume.

-[Unknown]

[unknownbrackets]

Okay, so the func that writes the stencil is at 0x08861628. It writes it directly, by expanding a u8 into the stencil.

It updates this every time the screen pans, but not every frame.

Also, this game and quite a few others are actually using memset mostly when playing videos to clear the screen.

-[Unknown]

[hrydgard]

Looks like we can do some fun stuff with function replacement then. Although regarding the memset, most games are able to reach fullspeed when only playing videos even on weak devices so at most that would be a small battery savings.

What values does it write to the stencil? Is it 0 and 1 or 0 and 255 or a range of values? If it's only two, we can set it at any upscaled resolution using texturing and alpha test combined with various stencil settings (can do more as well but more complicated). Although if glDrawPixels with the GL_STENCIL_INDEX format is available and works with glPixelZoom, that would also do the trick. I would guess that this would be one of the least tested paths in GPU drivers though...

[hrydgard]

Argh, glDrawPixels is not available at all on OpenGL ES. So texturing tricks it is.

[unknownbrackets]

Yeah, although replacing funcs like this (which seems specific to a particular game) feels a bit like the road to perdition. I bet we could do the same for Danganronpa though.

Well, the memset, we currently don't apply to fbos. It might fix issues where games show garbage for a moment after playing a video or something, not sure what the memset is for.

The values it writes include: 0, 0x47, 0x8D-0x9C, 0xA1, 0xB0, 0xB2, etc. So, just a variety of them. It uses an 8888 FBO.

-[Unknown]

[hrydgard]

Well yeah, but we have the excuse that there's always the software plugin for correct emulation :) Since there are so few games that do this, doing a few special case hacks is almost excusable imho.

Ugh, that's unfortunate that it's that many values. Wonder if we need all of them. Otherwise this might only work on desktop...

[unknownbrackets]

So, not using glDrawPixels, the options I can think of are:

1. Do a full pass with texturing + discard for each possible value.
2. Try to reduce that with creative use of glStencilMask and glStencilOp. Seems like it could be reduced some but not sure. Would be complicated...
3. Detect rectangles in the stencil data, and convert these to vertices. Zero stencil first, then use INCR assuming it reliably increments twice on overlap (with blending and zero alpha, of course.)
4. Upload only the most common N values from the stencil data, e.g. dither it somehow.

The former two seem GPU intensive, the latter CPU intensive. Hmmph...

Edit: actually, 2 may not be so bad. Just do it bit by bit. So 8 total passes for 8888.

-[Unknown]

[hrydgard]

Where GL_ARB_shader_stencil_export is unavailable (which may or may not be faster than glDrawPixels), I like option 3 actually, if all values are actually needed. I think it might be good enough to have the CPU detect horizontal stripes on each line, probably not necessary to deal with the 2nd dimension, there's only 272 lines at most on screen so you probably won't generate ridiculous amounts of 1-pixel-high rects to fill if it's reasonably regular (of course, this blows up with a pattern of 0, 255, 0, 255 and similar...).

[unknownbrackets]

So probably one zero pass/glClear/something + vertices to fill line by line (I like this method) vs. up to 8 full passes, I'm guessing the pixel fill rate will get in the way of the latter. Then again, if some bits are not used they could be optimized out...

-[Unknown]

[hrydgard]

Come to think of it, you might have to burn quite a bit of fillrate even in method 3 if there's lots of value 255 and other high values, as your INCR only increases by 1...

Another thought: If two or more subsequent screen lines have identical stencil you can merge them trivially.

Might be possible to combine method 1 and 3, with a few passes of method 1 approximating and then refining with method 3... Plenty of gnarly code to write though.

[hrydgard]

Also if you have N different values total in the stencil you can do it in N drawcalls with no overdraw (minimal fillrate burn), if you use SET stead of INCR, and simply generate strips that cover the places on the screen with that value, setting the ref value for each draw. 255 drawcalls isn't good for mobile though so if all values are present this is probably a bad option.

[unknownbrackets]

It has nice beautiful gradients where objects are, looks almost like a depth buffer. So there are a ton of values.

In fact, I would say they are using it as a depth buffer, and since it's using 2d drawing for the background, they probably just did not know the vram mirror trick to write to the depth buffer (they even have one which has all the same value.)

-[Unknown]

[unknownbrackets]

This works with default settings now.

-[Unknown]

[LingodRu486]

Hi guys, this issue is showing up again on default settings for windows v1.5.4

My specs:

_Operating System: Windows 10 Pro 64-bit (10.0, Build 16299) (16299.rs3release.170928-1534) System Manufacturer: LENOVO System Model: 4236TKG Processor: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (4 CPUs), ~2.5GHz Memory: 8192MB RAM Available OS Memory: 8076MB RAM Page File: 3487MB used, 5868MB available DirectX Version: DirectX 12 DX Setup Parameters: Not found User DPI Setting: 96 DPI (100 percent) System DPI Setting: 96 DPI (100 percent) DWM DPI Scaling: Disabled Miracast: Not Available Microsoft Graphics Hybrid: Not Supported Card name: Intel(R) HD Graphics 3000

Is there a setting I can test? Or something I'm doing wrong?

If you need additional information from my PC or settings just let me know.

Thanks. LingodRu486

[hrydgard]

@LingodRu486 Really? This should be fixed on all backends. Make sure you have updated graphics drivers.

Also, try the latest build from https://buildbot.orphis.net/ppsspp/ .

[unknownbrackets]

It's not always working properly on some drivers, but that's a new bug: #10634

-[Unknown]

[LingodRu486]

@hrydgard Thanks for the reply.

I manage to get it working, but I did a couple of tests first.

Here are the tests I did:

Tested the issue with all versions available at https://www.ppsspp.org/downloads.html for windows. No change.

My graphic card drivers were up to date but I did a clean install of them anyway. No Change.

Changed Rendering Mode from OpenGl to Direct3D 9 on latest version of PPSSPP. It worked

My Settings

I have been testing both Final Fantasy Dissidia and Star Ocean First Departure. I have no issues running FFD with Open GL

I tested SOFD until I was able to leave the initial town and there were just minor slowdowns and music interruptions.

Maybe the issue is my computer somehow but unfortunately I have no other machine to test this in.

@unknownbrackets Thanks for the reply, but it seems to be a separate issue

Anyway I'll take this chance to thank you both for all the awesome work you did and still do with this project. Already have a Gold version on my android account and I'll try to help whenever I get a chance to.

Best of luck to you both on all your projects and if you need me to provide any more info I'll be happy too.