[GH-ISSUE #3046] God of war's graphics issue

kerem commented

2026-03-17 21:14:52 +03:00

Owner

Originally created by @arcade1977 on GitHub (Aug 4, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/3046

981~1067:

Originally created by @arcade1977 on GitHub (Aug 4, 2013). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/3046 981~1067:

kerem closed this issue

2026-03-17 21:14:57 +03:00

kerem commented

2026-03-17 21:15:03 +03:00

Author

Owner

@arcade1977 commented on GitHub (Aug 4, 2013):

I don't know why can not upload pictures:(

Please look it:
http://tieba.baidu.com/p/2507244709

@arcade1977 commented on GitHub (Aug 4, 2013): I don't know why can not upload pictures:( Please look it: http://tieba.baidu.com/p/2507244709

kerem commented

2026-03-17 21:15:08 +03:00

Author

Owner

@arcade1977 commented on GitHub (Aug 4, 2013):

@unknownbrackets ,can you fix god of war's graphics issue since 981 ( 974 still OK,but 981 is destroyed) ?

@arcade1977 commented on GitHub (Aug 4, 2013): @unknownbrackets ,can you fix god of war's graphics issue since 981 ( 974 still OK,but 981 is destroyed) ?

kerem commented

2026-03-17 21:15:13 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Aug 4, 2013):

I don't have this game, but I think #3029 may work around it for now.

-[Unknown]

@unknownbrackets commented on GitHub (Aug 4, 2013): I don't have this game, but I think #3029 may work around it for now. -[Unknown]

kerem commented

2026-03-17 21:15:18 +03:00

Author

Owner

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

I have retested that scene and confrim working okay with #3029

@dbz400 commented on GitHub (Aug 4, 2013): I have retested that scene and confrim working okay with #3029 ![screen00044](https://f.cloud.github.com/assets/3000282/906810/77698fea-fce1-11e2-835c-423e821bc2de.jpg)

kerem commented

2026-03-17 21:15:23 +03:00

Author

Owner

@arcade1977 commented on GitHub (Aug 9, 2013):

At 0.81.1167, this problem appeared again:(

@arcade1977 commented on GitHub (Aug 9, 2013): At 0.81.1167, this problem appeared again:(

kerem commented

2026-03-17 21:15:28 +03:00

Author

Owner

@arcade1977 commented on GitHub (Aug 9, 2013):

http://tieba.baidu.com/p/2520154867

@arcade1977 commented on GitHub (Aug 9, 2013): http://tieba.baidu.com/p/2520154867

kerem commented

2026-03-17 21:15:33 +03:00

Author

Owner

@arcade1977 commented on GitHub (Aug 9, 2013):

好像不是 #3082 的问题，1165 战神就有这个问题了，但是1152是正常的，我正在测试到底是哪个版本开始破坏它的

@arcade1977 commented on GitHub (Aug 9, 2013): 好像不是 #3082 的问题，1165 战神就有这个问题了，但是1152是正常的，我正在测试到底是哪个版本开始破坏它的

kerem commented

2026-03-17 21:15:38 +03:00

Author

Owner

@arcade1977 commented on GitHub (Aug 9, 2013):

OK，找到把战神破坏的版本了，是v0.8.1-1158

@arcade1977 commented on GitHub (Aug 9, 2013): OK，找到把战神破坏的版本了，是v0.8.1-1158

kerem commented

2026-03-17 21:15:44 +03:00

Author

Owner

@hrydgard commented on GitHub (Aug 9, 2013):

English in reports please, at least in addition to the Chinese.

@hrydgard commented on GitHub (Aug 9, 2013): English in reports please, at least in addition to the Chinese.

kerem commented

2026-03-17 21:15:49 +03:00

Author

Owner

@dbz400 commented on GitHub (Aug 10, 2013):

@hrydgard , they're mentioning the broken commit is git 1158

[Rename gpuStats.numFrames to numVBlanks. Switch to using numFlips for things like cache expirations.]

@dbz400 commented on GitHub (Aug 10, 2013): @hrydgard , they're mentioning the broken commit is git 1158 [Rename gpuStats.numFrames to numVBlanks. Switch to using numFlips for things like cache expirations.]

kerem commented

2026-03-17 21:15:54 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Aug 10, 2013):

Please reopen if this isn't fully fixed. Thanks @raven02.

-[Unknown]

@unknownbrackets commented on GitHub (Aug 10, 2013): Please reopen if this isn't fully fixed. Thanks @raven02. -[Unknown]

kerem commented

2026-03-17 21:15:59 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 1, 2013):

Same issue happened again since i changed from invalid to valid

        } else if ((entry->addr - address) / entry->bufw < framebuffer->height) {
            WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address);
            // TODO: Keep track of the y offset.
            AttachFramebufferValid(entry, framebuffer);

@dbz400 commented on GitHub (Sep 1, 2013): Same issue happened again since i changed from invalid to valid ``` } else if ((entry->addr - address) / entry->bufw < framebuffer->height) { WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address); // TODO: Keep track of the y offset. AttachFramebufferValid(entry, framebuffer); ```

kerem commented

2026-03-17 21:16:04 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 1, 2013):

@unknownbrackets , just wonder if MAX_SUBAREA_Y_OFFSET related to (entry->addr - address) / entry->bufw

@dbz400 commented on GitHub (Sep 1, 2013): @unknownbrackets , just wonder if MAX_SUBAREA_Y_OFFSET related to (entry->addr - address) / entry->bufw

kerem commented

2026-03-17 21:16:09 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 1, 2013):

@raven02: you have to think of all of this as MEMORY. Everything goes back to memory.

Let's use easy small numbers to make things simple to explain. My memory goes from 0 to 1000. Framebuffers are 200 bytes.

So let's say I do what's normal, and create two framebuffers: one at 0 and the other at 200. What I'm doing is essentially "allocating" the space from 0-199 for fb 1, and 200-399 for fb 2, right? These are the buffers I show on the screen.

Now suppose I draw a texture. I start this texture at 20. 20 is INSIDE 0-199.

If we assume this theoretical display uses a stride/width of 20, then the texture actually starts 1 pixel lower than the start of the framebuffer, right? If I say I want the texture starting at 20, and ending just before 80, then really I'm asking for this:

+-------------------------+
|  fb row 1 (0 - 19)      |
|  fb row 1 (20 - 39)     |   <-- texture starts here
|  fb row 1 (40 - 59)     |   <-- texture includes this line
|  fb row 1 (60 - 79)     |   <-- texture ends after this line
|  fb row 1 (80 - 99)     |
|  fb row 1 (100 - 119)   |
|  fb row 1 (120 - 139)   |
|  fb row 1 (140 - 159)   |
|  fb row 1 (160 - 179)   |
|  fb row 1 (180 - 199)   |
+-------------------------+

In other words, the texture is actually only 3px high, unlike my normal 10px high framebuffers (these are all simple numbers.)

So back to the formula and original question:

(entry->addr - address) / entry->bufw

= (texture address - framebuffer address) / stride

= (20 - 0) / 20
= 20/20
= 1

This tells me how many pixels (rows) below the start of the framebuffer the texture starts at.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 1, 2013): @raven02: you have to think of all of this as MEMORY. Everything goes back to memory. Let's use easy small numbers to make things simple to explain. My memory goes from 0 to 1000. Framebuffers are 200 bytes. So let's say I do what's normal, and create two framebuffers: one at 0 and the other at 200. What I'm doing is essentially "allocating" the space from 0-199 for fb 1, and 200-399 for fb 2, right? These are the buffers I show on the screen. Now suppose I draw a texture. I start this texture at 20. 20 is INSIDE 0-199. If we assume this theoretical display uses a stride/width of 20, then the texture actually starts 1 pixel lower than the start of the framebuffer, right? If I say I want the texture starting at 20, and ending just before 80, then really I'm asking for this: ``` +-------------------------+ | fb row 1 (0 - 19) | | fb row 1 (20 - 39) | <-- texture starts here | fb row 1 (40 - 59) | <-- texture includes this line | fb row 1 (60 - 79) | <-- texture ends after this line | fb row 1 (80 - 99) | | fb row 1 (100 - 119) | | fb row 1 (120 - 139) | | fb row 1 (140 - 159) | | fb row 1 (160 - 179) | | fb row 1 (180 - 199) | +-------------------------+ ``` In other words, the texture is actually only 3px high, unlike my normal 10px high framebuffers (these are all simple numbers.) So back to the formula and original question: ``` (entry->addr - address) / entry->bufw = (texture address - framebuffer address) / stride = (20 - 0) / 20 = 20/20 = 1 ``` This tells me how many pixels (rows) below the start of the framebuffer the texture starts at. -[Unknown]

kerem commented

2026-03-17 21:16:14 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 1, 2013):

Humm it complicated than that i imagaine originally :)

So MAX_SUBAREA_Y_OFFSET = 32 means max 32 pixels below the start of framebuffer ?

@dbz400 commented on GitHub (Sep 1, 2013): Humm it complicated than that i imagaine originally :) So MAX_SUBAREA_Y_OFFSET = 32 means max 32 pixels below the start of framebuffer ?

kerem commented

2026-03-17 21:16:19 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 1, 2013):

Yes. The reason for it is that if I allowed large numbers (e.g. anything within the buffer), we got glitches in a lot of places. SAO in particular.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 1, 2013): Yes. The reason for it is that if I allowed large numbers (e.g. anything within the buffer), we got glitches in a lot of places. SAO in particular. -[Unknown]

kerem commented

2026-03-17 21:16:24 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 1, 2013):

Alright . In God of War , it keep tracek its offset like this

            // TODO: Keep track of the y offset.
            INFO_LOG(HLE,"offset=%i", (entry->addr - address) / entry->bufw);

30:09:212 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=16
30:09:212 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=18
30:09:212 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=19
30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2
30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3
30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2
30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3
30:09:216 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=16
30:09:216 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=18
30:09:216 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=19
30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2
30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3
30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2
30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3

@dbz400 commented on GitHub (Sep 1, 2013): Alright . In God of War , it keep tracek its offset like this ``` // TODO: Keep track of the y offset. INFO_LOG(HLE,"offset=%i", (entry->addr - address) / entry->bufw); ``` 30:09:212 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=16 30:09:212 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=18 30:09:212 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=19 30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2 30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3 30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2 30:09:215 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3 30:09:216 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=16 30:09:216 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=18 30:09:216 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=19 30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2 30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3 30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=2 30:09:226 user_main I[HLE]: GLES\TextureCache.cpp:219 offset=3

kerem commented

2026-03-17 21:16:29 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 1, 2013):

However the max offset above is 19 which is still smaller than MAX_SUBAREA_Y_OFFSET but generate following black texture

@dbz400 commented on GitHub (Sep 1, 2013): However the max offset above is 19 which is still smaller than MAX_SUBAREA_Y_OFFSET but generate following black texture ![screen00065](https://f.cloud.github.com/assets/3000282/1064194/01bd0300-1319-11e3-80b3-f7e89c870e99.jpg)

kerem commented

2026-03-17 21:16:34 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Really strange. What are the texture heights and framebuffer heights for these cases? That's how I compared for other games.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Really strange. What are the texture heights and framebuffer heights for these cases? That's how I compared for other games. -[Unknown]

kerem commented

2026-03-17 21:16:40 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

        } else if ((entry->addr - address) / entry->bufw < framebuffer->height) {
            WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address);
            // TODO: Keep track of the y offset.
            // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online
            INFO_LOG(HLE,"texture height = %i , framebuffer height=%i", entry->bufw , framebuffer->height);
            AttachFramebufferValid(entry, framebuffer);

@dbz400 commented on GitHub (Sep 2, 2013): ``` } else if ((entry->addr - address) / entry->bufw < framebuffer->height) { WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address); // TODO: Keep track of the y offset. // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online INFO_LOG(HLE,"texture height = %i , framebuffer height=%i", entry->bufw , framebuffer->height); AttachFramebufferValid(entry, framebuffer); ```

kerem commented

2026-03-17 21:16:45 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

46:11:645 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272
46:11:647 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272
46:11:647 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272
46:11:647 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272

@dbz400 commented on GitHub (Sep 2, 2013): 46:11:645 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272 46:11:647 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272 46:11:647 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272 46:11:647 user_main I[HLE]: GLES\TextureCache.cpp:226 texture height = 512 , framebuffer height=272

kerem commented

2026-03-17 21:16:50 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

I checked Tactic Orge and SOA which use subarea offset texture , texture height are 256 and 128 which is smaller than framebuffer height

@dbz400 commented on GitHub (Sep 2, 2013): I checked Tactic Orge and SOA which use subarea offset texture , texture height are 256 and 128 which is smaller than framebuffer height

kerem commented

2026-03-17 21:16:55 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Make sure you're checking the initial intro battle against the guy in red. That's where it has a ton of effects.

Just delete / rename savedata to see it.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Make sure you're checking the initial intro battle against the guy in red. That's where it has a ton of effects. Just delete / rename savedata to see it. -[Unknown]

kerem commented

2026-03-17 21:17:00 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

Yep , just checked it .It is that battle scene against those guy in red.

This one line fixes the God of War issue here while still maintains all stuffs in Tactic Orge and SOA

} else if ((entry->addr - address) / entry->bufw < framebuffer->height && entry->bufw < framebuffer->height) {

@dbz400 commented on GitHub (Sep 2, 2013): Yep , just checked it .It is that battle scene against those guy in red. ![screen00008](https://f.cloud.github.com/assets/3000282/1069358/c9fb9f38-1414-11e3-8d34-1ab098747f14.jpg) This one line fixes the God of War issue here while still maintains all stuffs in Tactic Orge and SOA } else if ((entry->addr - address) / entry->bufw < framebuffer->height && entry->bufw < framebuffer->height) {

kerem commented

2026-03-17 21:17:05 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Okay, but that's obviously pure hackery, right? To be fair, limiting the height at all is hackery, but the bufw isn't really related to the height at all...

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Okay, but that's obviously pure hackery, right? To be fair, limiting the height at all is hackery, but the bufw isn't really related to the height at all... -[Unknown]

kerem commented

2026-03-17 21:17:10 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

Yep , however texture height is defintely bigger than that of framebuffer height in GOW so it explains the black textures?

@dbz400 commented on GitHub (Sep 2, 2013): Yep , however texture height is defintely bigger than that of framebuffer height in GOW so it explains the black textures?

kerem commented

2026-03-17 21:17:15 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

To be clear (fun ascii art time again):

+------------------------------+
|                              |
|                              |  <-- texture starts here
|                              |  <-- texture ends here
|              FB              |
|                              |
|                              |
|                              |
+------------------------------+
          <-- bufw -->

In this example, we subtract the texture start memory address from the framebuffer address, and now we have how many bytes into the framebuffer the texture starts at (entry->addr - address).

The only reason to divide by bufw is to determine the y value (regardless of width) to compare it to the framebuffer height and make sure it's not outside the framebuffer. That check in other words is verifying that this is not happening:

+------------------------------+
|            SMALL FB          |
+------------------------------+
                                  <-- texture starts here

That said, as I write this, I wonder if it's not taking into account the bits per pixel correctly... bufw is not bytes, it's pixels.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): To be clear (fun ascii art time again): ``` +------------------------------+ | | | | <-- texture starts here | | <-- texture ends here | FB | | | | | | | +------------------------------+ <-- bufw --> ``` In this example, we subtract the texture start memory address from the framebuffer address, and now we have how many bytes into the framebuffer the texture starts at `(entry->addr - address)`. The only reason to divide by `bufw` is to determine the y value (regardless of width) to compare it to the framebuffer height and make sure it's not outside the framebuffer. That check in other words is verifying that this is not happening: ``` +------------------------------+ | SMALL FB | +------------------------------+ <-- texture starts here ``` That said, as I write this, I wonder if it's not taking into account the bits per pixel correctly... bufw is not bytes, it's pixels. -[Unknown]

kerem commented

2026-03-17 21:17:20 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

Basically , I did feel strange when i first try to check the value of "(entry->addr - address) / entry->bufw" (at that moment i don't know it is pixel) is always return very small number when compare to framebuffer height

@dbz400 commented on GitHub (Sep 2, 2013): Basically , I did feel strange when i first try to check the value of "(entry->addr - address) / entry->bufw" (at that moment i don't know it is pixel) is always return very small number when compare to framebuffer height

kerem commented

2026-03-17 21:17:25 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

bitsPerPixel[gstate.getTextureFormat()] should be the bits, so the correct divisor is probably:

u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8;

Or similar.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): `bitsPerPixel[gstate.getTextureFormat()]` should be the bits, so the correct divisor is probably: ``` c++ u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8; ``` Or similar. -[Unknown]

kerem commented

2026-03-17 21:17:30 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

Something like this to check ?

} else if ((entry->addr - address) / bufwBytes < framebuffer->height) {

@dbz400 commented on GitHub (Sep 2, 2013): Something like this to check ? } else if ((entry->addr - address) / bufwBytes < framebuffer->height) {

kerem commented

2026-03-17 21:17:36 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Yeah... does that help at all?

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Yeah... does that help at all? -[Unknown]

kerem commented

2026-03-17 21:17:41 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

Humm didn't help ....

    if (framebuffer->fb_stride == entry->bufw && compatFormat) {
        u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8;
        u32 offset = (entry->addr - address) / bufwBytes;
        if (framebuffer->format != entry->format) {
            WARN_LOG_REPORT_ONCE(diffFormat2, HLE, "Render to texture with different formats %d != %d at %08x", entry->format, framebuffer->format, address);
            // TODO: Use an FBO to translate the palette?
            // Affected game List : DBZ VS Tag , 3rd birthday 
            AttachFramebufferValid(entry, framebuffer);
        } else if (offset < framebuffer->height) {
            WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address);
            // TODO: Keep track of the y offset.
            // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online
            INFO_LOG(HLE,"offset=%i, fbheight=%i", offset, framebuffer->height);
            AttachFramebufferValid(entry, framebuffer);
        }
    }

@dbz400 commented on GitHub (Sep 2, 2013): Humm didn't help .... ``` if (framebuffer->fb_stride == entry->bufw && compatFormat) { u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8; u32 offset = (entry->addr - address) / bufwBytes; if (framebuffer->format != entry->format) { WARN_LOG_REPORT_ONCE(diffFormat2, HLE, "Render to texture with different formats %d != %d at %08x", entry->format, framebuffer->format, address); // TODO: Use an FBO to translate the palette? // Affected game List : DBZ VS Tag , 3rd birthday AttachFramebufferValid(entry, framebuffer); } else if (offset < framebuffer->height) { WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address); // TODO: Keep track of the y offset. // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online INFO_LOG(HLE,"offset=%i, fbheight=%i", offset, framebuffer->height); AttachFramebufferValid(entry, framebuffer); } } ```

kerem commented

2026-03-17 21:17:46 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

I did one observation .For Tactic Orge and SOA , offset is value of 2 and (6,2,8,11,13) respectively . However in , GOW , offset is (0,4) which has 0 offset

@dbz400 commented on GitHub (Sep 2, 2013): I did one observation .For Tactic Orge and SOA , offset is value of 2 and (6,2,8,11,13) respectively . However in , GOW , offset is (0,4) which has 0 offset

kerem commented

2026-03-17 21:17:51 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Hmm, well if offset is 0, it should be an exact match. If that's the case, and framebuffer->format == entry->format how is it even getting there?

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Hmm, well if offset is 0, it should be an exact match. If that's the case, and `framebuffer->format == entry->format` how is it even getting there? -[Unknown]

kerem commented

2026-03-17 21:17:56 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

Just tried something but not too sure if this makes sense but it works for all .

    if (framebuffer->fb_stride == entry->bufw && compatFormat) {
        u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8;
        u32 fbBytes =  bitsPerPixel[framebuffer->format] * framebuffer->height / 8;
        if (framebuffer->format != entry->format) {
            WARN_LOG_REPORT_ONCE(diffFormat2, HLE, "Render to texture with different formats %d != %d at %08x", entry->format, framebuffer->format, address);
            // TODO: Use an FBO to translate the palette?
            // Affected game List : DBZ VS Tag , 3rd birthday 
            AttachFramebufferValid(entry, framebuffer);
        } else if (bufwBytes < fbBytes) {
            WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address);
            // TODO: Keep track of the y offset.
            // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online
            AttachFramebufferValid(entry, framebuffer);
        }
    }

@dbz400 commented on GitHub (Sep 2, 2013): Just tried something but not too sure if this makes sense but it works for all . ``` if (framebuffer->fb_stride == entry->bufw && compatFormat) { u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8; u32 fbBytes = bitsPerPixel[framebuffer->format] * framebuffer->height / 8; if (framebuffer->format != entry->format) { WARN_LOG_REPORT_ONCE(diffFormat2, HLE, "Render to texture with different formats %d != %d at %08x", entry->format, framebuffer->format, address); // TODO: Use an FBO to translate the palette? // Affected game List : DBZ VS Tag , 3rd birthday AttachFramebufferValid(entry, framebuffer); } else if (bufwBytes < fbBytes) { WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address); // TODO: Keep track of the y offset. // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online AttachFramebufferValid(entry, framebuffer); } } ```

kerem commented

2026-03-17 21:18:01 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Hmm, what that means essentially is that you are disabling it for non-clut types, e.g. these:

            || (framebuffer->format == GE_FORMAT_8888 && entry->format == GE_TFMT_CLUT32)
            || (framebuffer->format != GE_FORMAT_8888 && entry->format == GE_TFMT_CLUT16);

It'd be better to just replace bufwBytes < fbBytes with framebuffer->format == entry->format. But I think the height check still should be there, without it there was some game I was getting a definitely wrong texture pulled in (it may have been SAO.)

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Hmm, what that means essentially is that you are disabling it for non-clut types, e.g. these: ``` c++ || (framebuffer->format == GE_FORMAT_8888 && entry->format == GE_TFMT_CLUT32) || (framebuffer->format != GE_FORMAT_8888 && entry->format == GE_TFMT_CLUT16); ``` It'd be better to just replace `bufwBytes < fbBytes` with `framebuffer->format == entry->format`. But I think the height check still should be there, without it there was some game I was getting a definitely wrong texture pulled in (it may have been SAO.) -[Unknown]

kerem commented

2026-03-17 21:18:06 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

This one includes height check and format check as well. All 3 titles are working good as well .

if (framebuffer->fb_stride == entry->bufw && compatFormat) {
    u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8;
    u32 fbBytes =  bitsPerPixel[framebuffer->format] * framebuffer->height / 8;
    if (framebuffer->format != entry->format) {
        WARN_LOG_REPORT_ONCE(diffFormat2, HLE, "Render to texture with different formats %d != %d at %08x", entry->format, framebuffer->format, address);
        // TODO: Use an FBO to translate the palette?
        // Affected game List : DBZ VS Tag , 3rd birthday 
        AttachFramebufferValid(entry, framebuffer);
    } else if (bufwBytes < fbBytes && framebuffer->format == entry->format) {
        WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address);
        // TODO: Keep track of the y offset.
        // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online
        AttachFramebufferValid(entry, framebuffer);
    }
}

@dbz400 commented on GitHub (Sep 2, 2013): This one includes height check and format check as well. All 3 titles are working good as well . ``` if (framebuffer->fb_stride == entry->bufw && compatFormat) { u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8; u32 fbBytes = bitsPerPixel[framebuffer->format] * framebuffer->height / 8; if (framebuffer->format != entry->format) { WARN_LOG_REPORT_ONCE(diffFormat2, HLE, "Render to texture with different formats %d != %d at %08x", entry->format, framebuffer->format, address); // TODO: Use an FBO to translate the palette? // Affected game List : DBZ VS Tag , 3rd birthday AttachFramebufferValid(entry, framebuffer); } else if (bufwBytes < fbBytes && framebuffer->format == entry->format) { WARN_LOG_REPORT_ONCE(subarea, HLE, "Render to area containing texture at %08x", address); // TODO: Keep track of the y offset. // Affected game List : God of War Ghost of Sparta , Tactic Orge , Sword Art Online AttachFramebufferValid(entry, framebuffer); } } ```

kerem commented

2026-03-17 21:18:11 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Well, bufwBytes < fbBytes isn't a height check. It's a width check. Since there's already framebuffer->fb_stride == entry->bufw, it literally ONLY checks that there's no clut being used (or the same depth of clut is being used.)

It'd be better to add back the height check.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Well, `bufwBytes < fbBytes` isn't a height check. It's a width check. Since there's already `framebuffer->fb_stride == entry->bufw`, it literally ONLY checks that there's no clut being used (or the same depth of clut is being used.) It'd be better to add back the height check. -[Unknown]

kerem commented

2026-03-17 21:18:16 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 2, 2013):

To be precise changes as follow (somehow still cannot make GOW happy though)

if ((entry->addr - address) / bufwBytes < framebuffer->height && framebuffer->format == entry->format) {

@dbz400 commented on GitHub (Sep 2, 2013): To be precise changes as follow (somehow still cannot make GOW happy though) if ((entry->addr - address) / bufwBytes < framebuffer->height && framebuffer->format == entry->format) {

kerem commented

2026-03-17 21:18:21 +03:00

Author

Owner

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

I do think GOW here somehow incorrectly fall into the subarea render texture .It should be a exact match .

@dbz400 commented on GitHub (Sep 3, 2013): I do think GOW here somehow incorrectly fall into the subarea render texture .It should be a exact match .

kerem commented

2026-03-17 21:18:26 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 3, 2013):

I hadn't realized you had height in the "fbBytes", so now I just don't even understand what the logic behind that compare even was, sorry. Can you explain what you're trying to do with an ascii box?

-[Unknown]

@unknownbrackets commented on GitHub (Sep 3, 2013): I hadn't realized you had height in the "fbBytes", so now I just don't even understand what the logic behind that compare even was, sorry. Can you explain what you're trying to do with an ascii box? -[Unknown]

kerem commented

2026-03-17 21:18:31 +03:00

Author

Owner

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

I think my logic mostly get wrong at the beginning.Originally i just want to compare them Bytes by Bytes rather than pixel so derived something wrong below.

u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8;
u32 fbBytes =  bitsPerPixel[framebuffer->format] * framebuffer->height / 8;

@dbz400 commented on GitHub (Sep 3, 2013): I think my logic mostly get wrong at the beginning.Originally i just want to compare them Bytes by Bytes rather than pixel so derived something wrong below. ``` u32 bufwBytes = bitsPerPixel[entry->format] * entry->bufw / 8; u32 fbBytes = bitsPerPixel[framebuffer->format] * framebuffer->height / 8; ```

kerem commented

2026-03-17 21:18:37 +03:00

Author

Owner

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

I think more likely to be this one for a valid width check.

u32 fbBytes = bitsPerPixel[framebuffer->format] * framebuffer->fb_stride / 8;

@dbz400 commented on GitHub (Sep 3, 2013): I think more likely to be this one for a valid width check. u32 fbBytes = bitsPerPixel[framebuffer->format] \* framebuffer->fb_stride / 8;

kerem commented

2026-03-17 21:18:42 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 8, 2013):

So are the graphics okay in this game now?

-[Unknown]

@unknownbrackets commented on GitHub (Sep 8, 2013): So are the graphics okay in this game now? -[Unknown]

kerem commented

2026-03-17 21:18:47 +03:00

Author

Owner

@dbz400 commented on GitHub (Sep 8, 2013):

@unknownbrackets , the graphics all look okay now in-game .I think can be closed :)

@dbz400 commented on GitHub (Sep 8, 2013): @unknownbrackets , the graphics all look okay now in-game .I think can be closed :)

kerem referenced this issue

2026-03-18 00:16:54 +03:00

[GH-ISSUE #3647] Jeanne D'Arc hanging on new game loading screen on linux amd64 #1505

Rows
Columns

[GH-ISSUE #3046] God of war's graphics issue #1253