[GH-ISSUE #5068] Star Wars Force Unleashed character model regression due to revision 9.6.340 #2129

New issue

Closed

opened 2026-03-18 07:37:16 +03:00 by kerem · 22 comments

kerem commented 2026-03-18 07:37:16 +03:00

Owner

Copy link

Originally created by @psennermann on GitHub (Jan 10, 2014).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/5068

In Star Wars Force Unleahed starting with PPSSPP 9.6.340 sometimes sprites partially disappear as you can see here:

Here's instead the correct behaviour of 9.6.338:

Originally created by @psennermann on GitHub (Jan 10, 2014). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/5068 In Star Wars Force Unleahed starting with PPSSPP 9.6.340 sometimes sprites partially disappear as you can see here:  Here's instead the correct behaviour of 9.6.338: 

kerem closed this issue 2026-03-18 07:37:22 +03:00

kerem commented 2026-03-18 07:37:29 +03:00

Author

Owner

Copy link

@psennermann commented on GitHub (Jan 10, 2014):

Forgot to write that it's on Windows XP 32-bit - Amd Hd4850

<!-- gh-comment-id:32046887 --> @psennermann commented on GitHub (Jan 10, 2014): Forgot to write that it's on Windows XP 32-bit - Amd Hd4850

kerem commented 2026-03-18 07:37:34 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (Jan 10, 2014):

Confirm on my NV system as well .

<!-- gh-comment-id:32059399 --> @dbz400 commented on GitHub (Jan 10, 2014): Confirm on my NV system as well . 

kerem commented 2026-03-18 07:37:39 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (Jan 24, 2014):

Just tested .It is still happening

<!-- gh-comment-id:33221155 --> @dbz400 commented on GitHub (Jan 24, 2014): Just tested .It is still happening

kerem commented 2026-03-18 07:37:44 +03:00

Author

Owner

Copy link

@hrydgard commented on GitHub (Jan 24, 2014):

Hm, those aren't sprites, those are 3D models as far as I can tell. Looks weird though, the shadow is properly occluded but still the rest isn't drawn right... Some bizarre depth or transparency problem.

<!-- gh-comment-id:33228613 --> @hrydgard commented on GitHub (Jan 24, 2014): Hm, those aren't sprites, those are 3D models as far as I can tell. Looks weird though, the shadow is properly occluded but still the rest isn't drawn right... Some bizarre depth or transparency problem.

kerem commented 2026-03-18 07:37:49 +03:00

Author

Owner

Copy link

@unknownbrackets commented on GitHub (Jan 24, 2014):

What are the buffers it's copying depth between? Just want to know their addresses and sizes. Can log them write where it does the blit.

-[Unknown]

<!-- gh-comment-id:33238579 --> @unknownbrackets commented on GitHub (Jan 24, 2014): What are the buffers it's copying depth between? Just want to know their addresses and sizes. Can log them write where it does the blit. -[Unknown]

kerem commented 2026-03-18 07:37:55 +03:00

Author

Owner

Copy link

@psennermann commented on GitHub (Jan 24, 2014):

You mean this?

20:49:984 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1597 Decimating FBO for 00164000 (128 x 128 x 0), age 6
20:50:687 System_GameT I[G3D]: GLES\ShaderManager.cpp:146 Linked shader: vs 70 fs 121
20:51:500 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:794 Creating FBO for 00164000 : 128 x 128 x 0
20:51:500 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:814 FBO reusing depthbuffer, 00164000/00110000 and 00000000/00110000

<!-- gh-comment-id:33249422 --> @psennermann commented on GitHub (Jan 24, 2014): You mean this? 20:49:984 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1597 Decimating FBO for 00164000 (128 x 128 x 0), age 6 20:50:687 System_GameT I[G3D]: GLES\ShaderManager.cpp:146 Linked shader: vs 70 fs 121 20:51:500 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:794 Creating FBO for 00164000 : 128 x 128 x 0 20:51:500 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:814 FBO reusing depthbuffer, 00164000/00110000 and 00000000/00110000

kerem commented 2026-03-18 07:38:00 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (Feb 5, 2014):

@unknownbrackets here it is

INFO_LOG(HLE,"source = %08x with size %i x %i , target = %08x with size %i x %i ", 
    sourceframebuffer->z_address, sourceframebuffer->renderWidth, sourceframebuffer->renderHeight , 
    targetframebuffer->z_address, targetframebuffer->renderWidth, targetframebuffer->renderHeight);

22:37:998 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:37:998 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:38:000 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544

<!-- gh-comment-id:34128593 --> @dbz400 commented on GitHub (Feb 5, 2014): @unknownbrackets here it is ``` INFO_LOG(HLE,"source = %08x with size %i x %i , target = %08x with size %i x %i ", sourceframebuffer->z_address, sourceframebuffer->renderWidth, sourceframebuffer->renderHeight , targetframebuffer->z_address, targetframebuffer->renderWidth, targetframebuffer->renderHeight); ``` 22:37:998 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256 22:37:998 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544 22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256 22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544 22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256 22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544 22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256 22:38:000 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544

kerem commented 2026-03-18 07:38:05 +03:00

Author

Owner

Copy link

@unknownbrackets commented on GitHub (Feb 5, 2014):

I thought it didn't blit when the sizes were different? So theoretically, it should not blit between any of those.

-[Unknown]

<!-- gh-comment-id:34129081 --> @unknownbrackets commented on GitHub (Feb 5, 2014): I thought it didn't blit when the sizes were different? So theoretically, it should not blit between any of those. -[Unknown]

kerem commented 2026-03-18 07:38:10 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (Feb 5, 2014):

Looks like the video is also stretched/duplicated somehow

<!-- gh-comment-id:34129089 --> @dbz400 commented on GitHub (Feb 5, 2014): Looks like the video is also stretched/duplicated somehow 

kerem commented 2026-03-18 07:38:15 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (Feb 5, 2014):

If remove linesize != 512 check fix it .This issue happened in other games as well .

<!-- gh-comment-id:34129153 --> @dbz400 commented on GitHub (Feb 5, 2014): If remove linesize != 512 check fix it .This issue happened in other games as well . 

kerem commented 2026-03-18 07:38:20 +03:00

Author

Owner

Copy link

@psennermann commented on GitHub (Mar 15, 2014):

If I may, i have a "simple" question: usually when it doesn't get found the exact revision that caused an issue, it is very difficult to find the origin of the problem, but in this case the revision that caused the issue has been spotted, so I wanted to ask if there is a particular reason why it is so complicated/takes so much time to fix this regression?
Thank you

<!-- gh-comment-id:37724814 --> @psennermann commented on GitHub (Mar 15, 2014): If I may, i have a "simple" question: usually when it doesn't get found the exact revision that caused an issue, it is very difficult to find the origin of the problem, but in this case the revision that caused the issue has been spotted, so I wanted to ask if there is a particular reason why it is so complicated/takes so much time to fix this regression? Thank you

kerem commented 2026-03-18 07:38:25 +03:00

Author

Owner

Copy link

@psennermann commented on GitHub (Apr 28, 2014):

Strange, I found out that just changing resolution on the fly fixes the "3d models diseappering" problem of the buffered rendering...

<!-- gh-comment-id:41577366 --> @psennermann commented on GitHub (Apr 28, 2014): Strange, I found out that just changing resolution on the fly fixes the "3d models diseappering" problem of the buffered rendering...

kerem commented 2026-03-18 07:38:30 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (Apr 29, 2014):

Originally i expect the video issue to be fixed as well that like Prince of Persia but apparently not

@psennermann , we can fix it but we know it break others at the same time.Probably need more testing and investigation before we can propertly fix it here.

<!-- gh-comment-id:41634896 --> @dbz400 commented on GitHub (Apr 29, 2014): Originally i expect the video issue to be fixed as well that like Prince of Persia but apparently not @psennermann , we can fix it but we know it break others at the same time.Probably need more testing and investigation before we can propertly fix it here.

kerem commented 2026-03-18 07:38:35 +03:00

Author

Owner

Copy link

@unknownbrackets commented on GitHub (Apr 29, 2014):

Is there another FBO that is created right before the video starts, but then isn't rendered to?

-[Unknown]

<!-- gh-comment-id:41637092 --> @unknownbrackets commented on GitHub (Apr 29, 2014): Is there another FBO that is created right before the video starts, but then isn't rendered to? -[Unknown]

kerem commented 2026-03-18 07:38:40 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (May 1, 2014):

@unknownbrackets , there are only two FBO created before the video start .

56:03:740 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:824 Creating FBO for 00154000 : 256 x 128 x 3
56:03:740 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:844 FBO reusing depthbuffer, 00154000/00110000 and 00000000/00110000
56:03:780 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:824 Creating FBO for 00164000 : 256 x 128 x 0
56:03:780 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:844 FBO reusing depthbuffer, 00164000/00110000 and 00000000/00110000

<!-- gh-comment-id:41885665 --> @dbz400 commented on GitHub (May 1, 2014): @unknownbrackets , there are only two FBO created before the video start . 56:03:740 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:824 Creating FBO for 00154000 : 256 x 128 x 3 56:03:740 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:844 FBO reusing depthbuffer, 00154000/00110000 and 00000000/00110000 56:03:780 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:824 Creating FBO for 00164000 : 256 x 128 x 0 56:03:780 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:844 FBO reusing depthbuffer, 00164000/00110000 and 00000000/00110000

kerem commented 2026-03-18 07:38:45 +03:00

Author

Owner

Copy link

@unknownbrackets commented on GitHub (May 1, 2014):

Well, they are both 256. So if it is writing the video buffer directly to either of those addresses, then it would probably assume the wrong width.

I guess we can change it to more specifically send the width of the framebuffer, from at least psmfplayer.

-[Unknown]

<!-- gh-comment-id:41885768 --> @unknownbrackets commented on GitHub (May 1, 2014): Well, they are both 256. So if it is writing the video buffer directly to either of those addresses, then it would probably assume the wrong width. I guess we can change it to more specifically send the width of the framebuffer, from at least psmfplayer. -[Unknown]

kerem commented 2026-03-18 07:38:50 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (May 1, 2014):

One interesting thing , if switching resolution let say from 2x -> 3x , the video will be correct .

<!-- gh-comment-id:41887182 --> @dbz400 commented on GitHub (May 1, 2014): One interesting thing , if switching resolution let say from 2x -> 3x , the video will be correct . 

kerem commented 2026-03-18 07:38:56 +03:00

Author

Owner

Copy link

@unknownbrackets commented on GitHub (May 1, 2014):

Switching resolution forces framebuffers to be deleted and recreated (it also makes the screen flicker.) Since nothing is recreating it, in this case, that makes it go away. But deleting it will cause problems for games that render e.g. subtitles on top of the video.

-[Unknown]

<!-- gh-comment-id:41887304 --> @unknownbrackets commented on GitHub (May 1, 2014): Switching resolution forces framebuffers to be deleted and recreated (it also makes the screen flicker.) Since nothing is recreating it, in this case, that makes it go away. But deleting it will cause problems for games that render e.g. subtitles on top of the video. -[Unknown]

kerem commented 2026-03-18 07:39:01 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (May 1, 2014):

Probably it is the vfb->stride get wrong when used in UpdateMemory()

     DrawPixels(Memory::GetPointer(addr | 0x04000000), vfb->format, vfb->fb_stride);

<!-- gh-comment-id:41887434 --> @dbz400 commented on GitHub (May 1, 2014): Probably it is the vfb->stride get wrong when used in UpdateMemory() ``` DrawPixels(Memory::GetPointer(addr | 0x04000000), vfb->format, vfb->fb_stride); ```

kerem commented 2026-03-18 07:39:06 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (May 1, 2014):

Force vfb->fb_stride to 512 fixed the video here therefore obviously it is the wrong width passing by

<!-- gh-comment-id:41887476 --> @dbz400 commented on GitHub (May 1, 2014): Force vfb->fb_stride to 512 fixed the video here therefore obviously it is the wrong width passing by

kerem commented 2026-03-18 07:39:11 +03:00

Author

Owner

Copy link

@unknownbrackets commented on GitHub (May 1, 2014):

That's what I said an hour ago.

-[Unknown]

<!-- gh-comment-id:41888083 --> @unknownbrackets commented on GitHub (May 1, 2014): That's what I said an hour ago. -[Unknown]

kerem commented 2026-03-18 07:39:16 +03:00

Author

Owner

Copy link

@dbz400 commented on GitHub (May 1, 2014):

Yep , i also checked videoData->frameWidth is 512 (psmf)

<!-- gh-comment-id:41888124 --> @dbz400 commented on GitHub (May 1, 2014): Yep , i also checked videoData->frameWidth is 512 (psmf)

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

dependabot/cargo/Tools/langtool/rustls-webpki-0.103.13

readme-1.20.4

https-linux-poc

more-minor-fixes

adhoc-view

minor-bbox-opt

more-cleanup

readme-fix

more-ui

v1.19.10-beta

adhoc-server-mode

morph-jit-work

add-vsync-event

viewport-rework

separate-portrait-config-work

ui-notification-work

lua-work

http-split-headers

v1.19.5-beta

matrix-opt

rewind-zstd

rework-audio-queues

psn-login-params

v1.19.3-commits

atrac-work

jit-ir-fixes

bump-android-sdk-version

themable-slider-colors

some-bbox-work

sum2012-half-skip

auto-log

more-smart-2d-filtering

ingame-network-ui

reject-icmp

atrac-forward-port

atrac-ctx-2-work

background-raster

defer-ge-cycles

test

parallel-loop-max-threads

ir-work-2

text-draw-refactor-3

avoid-strlen-memblockinfo

hotfixes-1.16.6

merge-drawcalls-same-output

frame-timing-new

lost-device-work

drawengine-reduce-buffer-binds

drawarrays-avoid-rebind

opengl-delayed-readback

minor-readback-refactors

nvda-support

vertex-format-remove-uv-flag

spirv-dumper

neon-opts

remove-hardware-skinning

ridge-racer-more-lens-flare

event-profiler

md5

maintainance_1.13

mali-stencil-test

interpreter-nan-check

sdl-vulkan-work

vfpu-dot-experiments

mipmap-slope

loco2-video-alt-fix

v1.20.3

v1.20.2

v1.20.1

v1.20

v1.19.3

v1.19.2

v1.19.1

v1.19

v1.18.1

v1.18

v1.17.1

v1.17

v1.16.6

v1.16.5

v1.16.4

v1.16.3

v1.16.2

v1.16.1

v1.16

v1.15.4

v1.15.3

v1.15.2

v1.15.1

v1.15

v1.14.4

v1.14.3

v1.14.2

v1.14.1

v1.14

v1.13.1b

v1.13.2

v1.13.1

v1.13

v1.12.3+

v1.12.3

v1.12.2

v1.12.1

v1.12

v1.11.3

v1.11.2

v1.11.1

v1.11

v1.10.3

v1.10.2

v1.10.1

v1.10

v1.9.3-950-g4debff114

v1.9.3-428-g2a0a64e0e

v1.9.4

v1.9.3-338-ga488fe17b

v1.9.3

v1.9.2

v1.9.1

v1.9

v1.8.0-698-g5c8ce9018

v1.8.0-550-gdc4e00f5d

v1.8.0-538-g3b29b13fe

v1.8.0-506-g30d7b7cb5

v1.8.0-477-g4510fb1e7

v1.8.0-409-g06e90a74a

v1.8.0-368-g73f8878c3

v1.8.0-260-gc0d5b4be7

v1.8.0-205-gf932de55b

v1.8.0-203-gb7ec62dae

v1.8.0

v1.7.5

v1.7.4

v1.7.3.1

v1.7.3

v1.7.2

v1.7.1-175-g631bc7840

v1.7.1

v1.7

v1.6.3-644-ga49df7d71

v1.6.3-605-g05b92c62b

v1.6.3-604-g7e6b227b4

v1.6.3-526-gcc7f8d561

v1.6.3-441-g3f79e3e24

v1.6.3

v1.6.2

v1.6.1

v1.6

v1.5.4-1041-ga16a7f0

v1.5.4-924-g65ba116

v1.5.4-492-gacfd919

v1.5.4-468-g2363ca6

v1.5.4-300-ge658e74

v1.5.4-267-g3b1b1bb

v1.5.4-232-gbe2984c

v1.5.4-204-gaa49c6d

v1.5.4-136-g8ac5fbc

v1.5.4

v1.5.3-71-g3ebd810

v1.5.3

v1.5.2

v1.5.1

v1.5

v1.4.2

v1.4.1

v1.4

v1.3

v1.2.2

v1.2.1

v1.2

v1.1.1

v1.1.0

v1.0.1

v1.0

v0.9.9.1

v0.9.9

v0.9.8

v0.9.7.2

v0.9.7.1

v0.9.7

v0.9.6

v0.9.5

v0.9.1

v0.9

v0.8.1

v0.8

v0.7.6

v0.7.5

v0.7

v0.6.1

v0.6

v0.5

v0.4

v0.31

v0.3.1

v0.3

Labels

Clear 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 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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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#2129

No description provided.