[GH-ISSUE #238] Hardware T&L issues (textures/wrong lighting) #67

Closed
opened 2026-03-17 03:26:26 +03:00 by kerem · 27 comments
Owner

Originally created by @dbz400 on GitHub (Dec 23, 2012).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/238

Tested few games with hardware T&L , most of them are working prefectly and fast except few issues below

1 . Missing textures ( Saint Seyia Omega )

1

2

  1. Incorrect lighting (FF type-0)

4

5

  1. Screen flickering ( Saint Seyia Omega )

3

1

Originally created by @dbz400 on GitHub (Dec 23, 2012). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/238 Tested few games with hardware T&L , most of them are working prefectly and fast except few issues below 1 . Missing textures ( Saint Seyia Omega ) ![1](https://f.cloud.github.com/assets/3000282/29017/da50321c-4d19-11e2-8b37-207c4a65acaa.jpg) ![2](https://f.cloud.github.com/assets/3000282/29023/c474bc14-4d1a-11e2-95f2-d1ceed351844.jpg) 1. Incorrect lighting (FF type-0) ![4](https://f.cloud.github.com/assets/3000282/29021/47767a22-4d1a-11e2-8765-06fded10a089.jpg) ![5](https://f.cloud.github.com/assets/3000282/29024/c8c32ad0-4d1a-11e2-9791-8e315083a7eb.jpg) 1. Screen flickering ( Saint Seyia Omega ) ![3](https://f.cloud.github.com/assets/3000282/29020/447c673c-4d1a-11e2-8c9c-b515d6c7920b.jpg) ![1](https://f.cloud.github.com/assets/3000282/29025/cc991002-4d1a-11e2-9479-316c35456c2b.jpg)
kerem closed this issue 2026-03-17 03:26:41 +03:00
Author
Owner

@hrydgard commented on GitHub (Dec 23, 2012):

Thanks for testing! Will look into these sometime after Christmas.

<!-- gh-comment-id:11647942 --> @hrydgard commented on GitHub (Dec 23, 2012): Thanks for testing! Will look into these sometime after Christmas.
Author
Owner

@dbz400 commented on GitHub (Dec 23, 2012):

Sure . everyone are hard working on ppsspp :)

<!-- gh-comment-id:11647974 --> @dbz400 commented on GitHub (Dec 23, 2012): Sure . everyone are hard working on ppsspp :)
Author
Owner

@sum2012 commented on GitHub (Dec 26, 2012):

NBA2K5 -USA -UCUS98607
I use Emucr PPSSPP Git (2012/12/26) Windows x86 to test
Need press Z on the black screen first
2
3

<!-- gh-comment-id:11688473 --> @sum2012 commented on GitHub (Dec 26, 2012): NBA2K5 -USA -UCUS98607 I use Emucr PPSSPP Git (2012/12/26) Windows x86 to test Need press Z on the black screen first ![2](https://f.cloud.github.com/assets/2177532/31300/60c42866-4f73-11e2-8fe9-ed4034a62902.jpg) ![3](https://f.cloud.github.com/assets/2177532/31302/6bdef41a-4f73-11e2-9328-708a22d5d8f7.jpg)
Author
Owner

@sum2012 commented on GitHub (Dec 26, 2012):

I do not how to output log file from log windows

<!-- gh-comment-id:11688558 --> @sum2012 commented on GitHub (Dec 26, 2012): I do not how to output log file from log windows
Author
Owner

@unknownbrackets commented on GitHub (Dec 26, 2012):

@sum2012 there are two ways:

  1. Use the command line. Start: PPSSPPWindows.exe --log=logsareawesome.txt
  2. Create a "User" folder and "User\Logs" folder in the same directory as PPSSPPWindows.exe. It will automatically create a log file inside there.

-[Unknown]

<!-- gh-comment-id:11690235 --> @unknownbrackets commented on GitHub (Dec 26, 2012): @sum2012 there are two ways: 1. Use the command line. Start: `PPSSPPWindows.exe --log=logsareawesome.txt` 2. Create a "User" folder and "User\Logs" folder in the same directory as PPSSPPWindows.exe. It will automatically create a log file inside there. -[Unknown]
Author
Owner

@hrydgard commented on GitHub (Dec 26, 2012):

Does NBA work with hardware transform turned off?

<!-- gh-comment-id:11690538 --> @hrydgard commented on GitHub (Dec 26, 2012): Does NBA work with hardware transform turned off?
Author
Owner

@sum2012 commented on GitHub (Dec 26, 2012):

@ unknownbrackets
Thanks,I see the PPSSPPWindows.exe before.But the useage do not mention need add logsareawesome.txt.
And the create folder method do not mention in readme.md (Should rename readme.md to readme.txt in window version)
The log
http://www.mediafire.com/?kok2x307iv3bo22
@hrydgard
Already hardware transform turned off

<!-- gh-comment-id:11694848 --> @sum2012 commented on GitHub (Dec 26, 2012): @ unknownbrackets Thanks,I see the PPSSPPWindows.exe before.But the useage do not mention need add logsareawesome.txt. And the create folder method do not mention in readme.md (Should rename readme.md to readme.txt in window version) The log http://www.mediafire.com/?kok2x307iv3bo22 @hrydgard Already hardware transform turned off
Author
Owner

@dbz400 commented on GitHub (Dec 31, 2012):

One more title screen bug in Valkyria Chronicles 2

With HW transform on
1

With HW transform off
1

<!-- gh-comment-id:11777275 --> @dbz400 commented on GitHub (Dec 31, 2012): One more title screen bug in Valkyria Chronicles 2 With HW transform on ![1](https://f.cloud.github.com/assets/3000282/36566/51f1e020-534d-11e2-8a4e-dee88fa671c4.jpg) With HW transform off ![1](https://f.cloud.github.com/assets/3000282/36562/0cedcf7a-534d-11e2-84f2-fd1a6dc8c4f2.jpg)
Author
Owner

@unknownbrackets commented on GitHub (Dec 31, 2012):

The colors are also off, I think, but seems to be in both cases. Same happens in Senjou no Valkyria 3 (alpha effects all wrong in mission select, etc.)

Hardware transform OFF on the left, ON on the right:

snv3-hw-title
snv3-hw-options
snv3-hw-dialog
snv3-hw-mission-select

Note: blue for the unselected tab "Battle" on the options dialog is incorrect in both cases.

-[Unknown]

<!-- gh-comment-id:11781634 --> @unknownbrackets commented on GitHub (Dec 31, 2012): The colors are also off, I think, but seems to be in both cases. Same happens in Senjou no Valkyria 3 (alpha effects all wrong in mission select, etc.) Hardware transform OFF on the left, ON on the right: ![snv3-hw-title](https://f.cloud.github.com/assets/191233/36815/bf853bae-5376-11e2-9a93-062e0c1cae88.png) ![snv3-hw-options](https://f.cloud.github.com/assets/191233/36816/c345a5bc-5376-11e2-8adc-9d18b537b709.png) ![snv3-hw-dialog](https://f.cloud.github.com/assets/191233/36817/c584cf92-5376-11e2-9184-30bcc4e41b58.png) ![snv3-hw-mission-select](https://f.cloud.github.com/assets/191233/36818/c7ac5a7e-5376-11e2-9298-7eb14fce605f.png) Note: blue for the unselected tab "Battle" on the options dialog is incorrect in both cases. -[Unknown]
Author
Owner

@hrydgard commented on GitHub (Dec 31, 2012):

Yeah, there's definitely some differences in alpha channel handling. I'll look at it next year ;)

<!-- gh-comment-id:11781655 --> @hrydgard commented on GitHub (Dec 31, 2012): Yeah, there's definitely some differences in alpha channel handling. I'll look at it next year ;)
Author
Owner

@unknownbrackets commented on GitHub (Dec 31, 2012):

I know, figured more samples was good though. I can get a dump of the display list (next year) if you want, too.

-[Unknown]

<!-- gh-comment-id:11781679 --> @unknownbrackets commented on GitHub (Dec 31, 2012): I know, figured more samples was good though. I can get a dump of the display list (next year) if you want, too. -[Unknown]
Author
Owner

@hrydgard commented on GitHub (Dec 31, 2012):

Definitely, more examples of differences is always good.

Don't think I'll need DL dumps for this, but I'll let you know if I do.

<!-- gh-comment-id:11781704 --> @hrydgard commented on GitHub (Dec 31, 2012): Definitely, more examples of differences is always good. Don't think I'll need DL dumps for this, but I'll let you know if I do.
Author
Owner

@hrydgard commented on GitHub (Dec 31, 2012):

BTW about the colors, red/blue confusion is really common because an RGB value might as well be RRGGBB as BBGGRR and neither the PSP nor OpenGL is really fully consistent about it :P It can sometimes be a trial/error matter to fix...

<!-- gh-comment-id:11781819 --> @hrydgard commented on GitHub (Dec 31, 2012): BTW about the colors, red/blue confusion is really common because an RGB value might as well be RRGGBB as BBGGRR and neither the PSP nor OpenGL is really fully consistent about it :P It can sometimes be a trial/error matter to fix...
Author
Owner

@unknownbrackets commented on GitHub (Dec 31, 2012):

Well, actually, it should be blue - it's just too bright (in both cases), for example on the options highlights/buttons.

Also, the VC2 logo should be grey not blue in raven02's shot. Anyway, it's still pretty close.

-[Unknown]

<!-- gh-comment-id:11782018 --> @unknownbrackets commented on GitHub (Dec 31, 2012): Well, actually, it should be blue - it's just too bright (in both cases), for example on the options highlights/buttons. Also, the VC2 logo should be grey not blue in raven02's shot. Anyway, it's still pretty close. -[Unknown]
Author
Owner

@sum2012 commented on GitHub (Jan 1, 2013):

NBA2K5 broken ( Press Z still black screen) at EmuCR-ppsspp-20121229-x86
last work in EmuCR-ppsspp-20121227-x86
EmuCR-ppsspp-20121229-x86 log
http://www.mediafire.com/?8adzpiwqxl4p5my

<!-- gh-comment-id:11789644 --> @sum2012 commented on GitHub (Jan 1, 2013): NBA2K5 broken ( Press Z still black screen) at EmuCR-ppsspp-20121229-x86 last work in EmuCR-ppsspp-20121227-x86 EmuCR-ppsspp-20121229-x86 log http://www.mediafire.com/?8adzpiwqxl4p5my
Author
Owner

@dbz400 commented on GitHub (Jan 4, 2013):

One more - Super Robot Taisen OG Saga - Masou Kishin II

w/ SW T&L (Correct one)
2

w/ HW T&L
1

<!-- gh-comment-id:11904513 --> @dbz400 commented on GitHub (Jan 4, 2013): One more - Super Robot Taisen OG Saga - Masou Kishin II w/ SW T&L (Correct one) ![2](https://f.cloud.github.com/assets/3000282/44497/fc0a271e-56c4-11e2-9dd6-bc014c19764a.jpg) w/ HW T&L ![1](https://f.cloud.github.com/assets/3000282/44496/f8e6e680-56c4-11e2-89cf-0e826ed44f52.jpg)
Author
Owner

@unknownbrackets commented on GitHub (Jan 11, 2013):

Another good one: Final Fantasy 1. Right now, you have to hammer buttons during the intro (suspect #393), but then once you get into the game, a random (and cycling) assortment of tiles are black with hardware transform on.

-[Unknown]

<!-- gh-comment-id:12134721 --> @unknownbrackets commented on GitHub (Jan 11, 2013): Another good one: Final Fantasy 1. Right now, you have to hammer buttons during the intro (suspect #393), but then once you get into the game, a random (and cycling) assortment of tiles are black with hardware transform on. -[Unknown]
Author
Owner

@unknownbrackets commented on GitHub (Jan 12, 2013):

I messed around a bit and found that if I do this (not always having alpha be 1.0 for ambient), it fixes some alpha issues, but I don't think it's right:

            const char *alpha = hasColor ? "a_color0.a" : "1.0";
            WRITE(p, "  v_color0 = clamp(lightSum0 + u_ambient * vec4(%s, %s) + vec4(u_matemissive, 0.0), 0.0, 1.0);\n", ambient, alpha);

It seemed like u_matambientalpha.a was the more correct value, but that does not fix it... I'm not entirely sure where a_color0 is coming from, though (but it's used when lighting is not enabled)?

-[Unknown]

<!-- gh-comment-id:12182759 --> @unknownbrackets commented on GitHub (Jan 12, 2013): I messed around a bit and found that if I do this (not always having alpha be 1.0 for ambient), it fixes some alpha issues, but I don't think it's right: ``` const char *alpha = hasColor ? "a_color0.a" : "1.0"; WRITE(p, " v_color0 = clamp(lightSum0 + u_ambient * vec4(%s, %s) + vec4(u_matemissive, 0.0), 0.0, 1.0);\n", ambient, alpha); ``` It seemed like `u_matambientalpha.a` was the more correct value, but that does not fix it... I'm not entirely sure where `a_color0` is coming from, though (but it's used when lighting is not enabled)? -[Unknown]
Author
Owner

@hrydgard commented on GitHub (Jan 12, 2013):

a_color0 is the vertex color passed in by the game.

The fix does indeed look a little dubious :)
I think this must be sorted by experimenting on the PSP or simply even more trial and error :P

<!-- gh-comment-id:12185079 --> @hrydgard commented on GitHub (Jan 12, 2013): a_color0 is the vertex color passed in by the game. The fix does indeed look a little dubious :) I think this must be sorted by experimenting on the PSP or simply even more trial and error :P
Author
Owner

@dbz400 commented on GitHub (Jan 13, 2013):

Would this be more consistent ? just my 2 cents and tested okay for Senjou no Valkyria 3

    if (gstate.lightingEnable & 1) {
        // Lighting does affect color 
        if (hasColor) 
            WRITE(p, "  v_color0 = clamp(lightSum0 + u_ambient * vec4(%s, a_color0.a) + vec4(u_matemissive, 0.0), 0.0, 1.0);\n", ambient);
        else 
            WRITE(p, "  v_color0 = clamp(lightSum0 + u_ambient * vec4(%s, u_matambientalpha.a) + vec4(u_matemissive, 0.0), 0.0, 1.0);\n", ambient);
    } else {
        // Lighting doesn't affect color.
        if (hasColor) {
            WRITE(p, "  v_color0 = a_color0;\n");
        } else {
            WRITE(p, "  v_color0 = u_matambientalpha;\n");
<!-- gh-comment-id:12189368 --> @dbz400 commented on GitHub (Jan 13, 2013): Would this be more consistent ? just my 2 cents and tested okay for Senjou no Valkyria 3 ``` if (gstate.lightingEnable & 1) { // Lighting does affect color if (hasColor) WRITE(p, " v_color0 = clamp(lightSum0 + u_ambient * vec4(%s, a_color0.a) + vec4(u_matemissive, 0.0), 0.0, 1.0);\n", ambient); else WRITE(p, " v_color0 = clamp(lightSum0 + u_ambient * vec4(%s, u_matambientalpha.a) + vec4(u_matemissive, 0.0), 0.0, 1.0);\n", ambient); } else { // Lighting doesn't affect color. if (hasColor) { WRITE(p, " v_color0 = a_color0;\n"); } else { WRITE(p, " v_color0 = u_matambientalpha;\n"); ```
Author
Owner

@dbz400 commented on GitHub (Jan 13, 2013):

Just tested this approach from @unknownbrackets , fixed Saint Seiya Omega and Super Robot Taisen OG Saga - Masou Kishin II

<!-- gh-comment-id:12189435 --> @dbz400 commented on GitHub (Jan 13, 2013): Just tested this approach from @unknownbrackets , fixed Saint Seiya Omega and Super Robot Taisen OG Saga - Masou Kishin II
Author
Owner

@unknownbrackets commented on GitHub (Jan 13, 2013):

Here's a less dubious version of the same thing:

github.com/unknownbrackets/ppsspp@2c39bc445c

My goal was to match this code in the software transform / lighting:

            if (reader.hasColor0()) {
                reader.ReadColor0(unlitColor);
            } else {
                unlitColor[0] = (gstate.materialambient & 0xFF) / 255.f;
                unlitColor[1] = ((gstate.materialambient >> 8)  & 0xFF) / 255.f;
                unlitColor[2] = ((gstate.materialambient >> 16) & 0xFF) / 255.f;
                unlitColor[3] = (gstate.materialalpha & 0xFF) / 255.f;
            }

Which sets unlitColor to include the alpha of a_color0 / materialambientalpha (if I understand correctly.) Then the logic in Light() does this:

    const Color4 *ambient;
    if (materialUpdate_ & 1)
        ambient = &in;
    else
        ambient = &materialAmbient;

In other words, if (materialUpdate_ & 1) && reader.hasColor0(), it uses color0 which I assume is a_color0. If only (materialUpdate_ & 1), it uses materialambientalpha, and otherwise it uses materialambient with a fixed 1.0 alpha, based on here:

    materialAmbient.GetFromRGB(gstate.materialambient);
    materialAmbient.a = 1.0f;

Ultimately, the result is preserving a_color0.a. That said, I don't think this is actually correct. In Senjou no Valkyria 3, it fixes all the other issues mentioned above, but it makes in game look worse: (included JPCSP since an empty fourth spot was ugly, just for comparison... also, the game's screenshot feature produces poor quality jpegs, sorry):

snv3-ingame
(the change above makes hardware and software look the same.)

So... I guess they're both wrong. Bugger. Time to work on headless screenshots.

-[Unknown]

<!-- gh-comment-id:12190271 --> @unknownbrackets commented on GitHub (Jan 13, 2013): Here's a less dubious version of the same thing: https://github.com/unknownbrackets/ppsspp/commit/2c39bc445ccca95be7419b53ebe5bd542de48338 My goal was to match this code in the software transform / lighting: ``` if (reader.hasColor0()) { reader.ReadColor0(unlitColor); } else { unlitColor[0] = (gstate.materialambient & 0xFF) / 255.f; unlitColor[1] = ((gstate.materialambient >> 8) & 0xFF) / 255.f; unlitColor[2] = ((gstate.materialambient >> 16) & 0xFF) / 255.f; unlitColor[3] = (gstate.materialalpha & 0xFF) / 255.f; } ``` Which sets unlitColor to include the alpha of a_color0 / materialambientalpha (if I understand correctly.) Then the logic in `Light()` does this: ``` const Color4 *ambient; if (materialUpdate_ & 1) ambient = &in; else ambient = &materialAmbient; ``` In other words, if `(materialUpdate_ & 1) && reader.hasColor0()`, it uses color0 which I assume is a_color0. If only `(materialUpdate_ & 1)`, it uses materialambientalpha, and otherwise it uses materialambient with a fixed 1.0 alpha, based on here: ``` materialAmbient.GetFromRGB(gstate.materialambient); materialAmbient.a = 1.0f; ``` Ultimately, the result is preserving a_color0.a. That said, I don't think this is actually correct. In Senjou no Valkyria 3, it fixes all the other issues mentioned above, but it makes in game look worse: (included JPCSP since an empty fourth spot was ugly, just for comparison... also, the game's screenshot feature produces poor quality jpegs, sorry): ![snv3-ingame](https://f.cloud.github.com/assets/191233/62677/21f367ce-5d4b-11e2-9aad-a56220610e15.png) (the change above makes hardware and software look the same.) So... I guess they're both wrong. Bugger. Time to work on headless screenshots. -[Unknown]
Author
Owner

@dbz400 commented on GitHub (Jan 31, 2013):

@hrydgard , just wonder in this case , do we still need to shift 8 and 16 for color alpha and double ?

    if (gstate.textureMapEnable & 1) {
        id->d[0] |= 1 << 1;
        id->d[0] |= (gstate.texfunc & 0x7) << 2;
        id->d[0] |= ((gstate.texfunc & 0x100) >> 8) << 5; // rgb or rgba
        id->d[0] |= ((gstate.texfunc & 0x10000) >> 16) << 6;    // color double
    }

or may be ?

    if (gstate.textureMapEnable & 1) {
        id->d[0] |= 1 << 1;
        id->d[0] |= (gstate.texfunc & 0x7) << 2;
        id->d[0] |= ((gstate.texfunc  >> 8) & 0x1) << 5; // rgb or rgba
        id->d[0] |= ((gstate.texfunc  >> 16) & 0x1) << 6;   // color double
    }
<!-- gh-comment-id:12949050 --> @dbz400 commented on GitHub (Jan 31, 2013): @hrydgard , just wonder in this case , do we still need to shift 8 and 16 for color alpha and double ? ``` if (gstate.textureMapEnable & 1) { id->d[0] |= 1 << 1; id->d[0] |= (gstate.texfunc & 0x7) << 2; id->d[0] |= ((gstate.texfunc & 0x100) >> 8) << 5; // rgb or rgba id->d[0] |= ((gstate.texfunc & 0x10000) >> 16) << 6; // color double } ``` or may be ? ``` if (gstate.textureMapEnable & 1) { id->d[0] |= 1 << 1; id->d[0] |= (gstate.texfunc & 0x7) << 2; id->d[0] |= ((gstate.texfunc >> 8) & 0x1) << 5; // rgb or rgba id->d[0] |= ((gstate.texfunc >> 16) & 0x1) << 6; // color double } ```
Author
Owner

@hrydgard commented on GitHub (Jan 31, 2013):

No, that would break things..

The important bits in texfunc are 0x10000, 0x100 and 0x3 (so, of the 24 bits: 0000000A 0000000B 000000CC).

What we do here is to collapse them into ABCC and put those four active bits after each other in the shader ID as ABCC00.

<!-- gh-comment-id:12950202 --> @hrydgard commented on GitHub (Jan 31, 2013): No, that would break things.. The important bits in texfunc are 0x10000, 0x100 and 0x3 (so, of the 24 bits: 0000000A 0000000B 000000CC). What we do here is to collapse them into ABCC and put those four active bits after each other in the shader ID as ABCC00.
Author
Owner

@dbz400 commented on GitHub (Jan 31, 2013):

I see. thanks for explanation to me as i'm trying to get rid of the following graphic bugs ( the 3 dark lines) , it appears throughout the game when spell . Besides, i think the blue fire in the pic may be wrong stencil , not quite sure .

1

<!-- gh-comment-id:12950746 --> @dbz400 commented on GitHub (Jan 31, 2013): I see. thanks for explanation to me as i'm trying to get rid of the following graphic bugs ( the 3 dark lines) , it appears throughout the game when spell . Besides, i think the blue fire in the pic may be wrong stencil , not quite sure . ![1](https://f.cloud.github.com/assets/3000282/115130/128d3554-6bc3-11e2-951e-e1b7973db532.jpg)
Author
Owner

@dbz400 commented on GitHub (Feb 3, 2013):

Last Ranker , HW mode seems to render incorrectly :( Will compare their SW/HW logic to see if can find a proper fix.

[HW]
1

[SW]
2

<!-- gh-comment-id:13054051 --> @dbz400 commented on GitHub (Feb 3, 2013): Last Ranker , HW mode seems to render incorrectly :( Will compare their SW/HW logic to see if can find a proper fix. [HW] ![1](https://f.cloud.github.com/assets/3000282/122279/f45a1588-6e43-11e2-90ba-93652894187f.jpg) [SW] ![2](https://f.cloud.github.com/assets/3000282/122280/f6513ff6-6e43-11e2-8d96-843690ccec23.jpg)
Author
Owner

@dbz400 commented on GitHub (Feb 4, 2013):

fe40a27 fixed Rast Ranker Alpha blending

<!-- gh-comment-id:13079165 --> @dbz400 commented on GitHub (Feb 4, 2013): fe40a27 fixed Rast Ranker Alpha blending
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ppsspp#67
No description provided.