mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #2159] Missing background : Romance Of Three Kingdom 9 PK #768
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#768
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dbz400 on GitHub (Jun 9, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/2159
This missing background never worked before in any build .Just for record.
@dbz400 commented on GitHub (Jun 9, 2013):
This is the frame dump log
http://pastebin.com/6yGjzVG2
Already tried to disable alpha/color test but seems not helping
@unknownbrackets commented on GitHub (Jun 9, 2013):
Sometimes you have to hit it more than once, if the game is frameskipping. That log doesn't have any GE commands in it...
-[Unknown]
@dbz400 commented on GitHub (Jun 9, 2013):
@unknownbrackets Arr .yes , hit twice works oka now . Since it is pretty big in size, i cannot put it in pastebin.
(rename it from jpg to zip is ok)
@dbz400 commented on GitHub (Jun 18, 2013):
@unknownbrackets , wondering anything we can try to change and test it out to see if we can fix this black BG .
@unknownbrackets commented on GitHub (Jun 18, 2013):
Does the hack I posted at the top of #2308 improve it at all?
-[Unknown]
@dbz400 commented on GitHub (Jun 18, 2013):
Unfornaturely not , it didn't help in this black BG .
@dbz400 commented on GitHub (Jun 29, 2013):
@hrydgard / @unknownbrackets , tried to take the follow changes, the background reappears but fonts missing .Any suggestion changes ?
@cv47 commented on GitHub (Jun 29, 2013):
WRITE(p, " gl_Position = u_proj_through * vec4(a_position.xy, 1.0, 0.0);\n");
Which game can fix or broke by change this code?
@hrydgard commented on GitHub (Jun 29, 2013):
@raven02 , that is surely wrong, because in the w coordinate, we stash the fog depth. Multiplying the fog depth with a column of the projection matrix is just nonsense, so what works, works by accident.
@cv47 , that throws away depth information so if that fixes something it's also by accident.
We are probably missing something else when it comes to Z stuff.. for example we don't implement MINZ and MAXZ, I don't really know how they are supposed to work.
@dbz400 commented on GitHub (Jun 29, 2013):
@cv47 , it somehow fix the fog effect in Sword Art Online but i think it works by accident .
BTW, what is your test fix to make both background and fonts show correctly?
@hrydgard , i see. It did break other games :(
@dbz400 commented on GitHub (Jul 1, 2013):
@hrydgard , would it be vertex decoder issue ? i try something else in DEC_FLOAT_3 or comment out memcpy(pos, f, 12);, the background appears .....
@dbz400 commented on GitHub (Jul 29, 2013):
Alright .Just test this out on the upcoming softGPU , it seems to render all correctly and no missing background . Wondering where should we start to compare the code difference ?
@sraphy commented on GitHub (Sep 16, 2013):
@raven02 I‘m trying to fix this bug, but I get the same problem as you,
may I ask you what did you do to get both background and font show up ?
if (gstate.isModeThrough()) {
WRITE(p, " gl_Position = u_proj_through * vec4(a_position.xyz, 1.0);\n");
}
if (***) {
WRITE(p, " gl_Position = u_proj * vec4(a_position.xyz, 0.0);\n");
}
else {
WRITE(p, " gl_Position = u_proj * vec4(a_position.xyz, 1.0);\n");
}
@unknownbrackets commented on GitHub (Sep 16, 2013):
@raven02 my suggestion for comparing with the softgpu is to attempt to make the softgpu look like what you see in gles. But, that is not really easy either...
What you want to do is to identify things. It'd be good to identify what vertex types, values, and state it's using when drawing the background, and the same things for the fonts. DEBUG_TEXTURES was my hack to find these things, but we really need to get around to porting/using/creating the GE debugger...
Once you have that, I would try to test different scenarios to see what it's doing, and what's correct.
-[Unknown]
@dbz400 commented on GitHub (Sep 17, 2013):
@unknownbrackets , yep , i'll follow your suggest approach to see if i can find out the difference .
@sraphy , that one with both background and font show up is from softGPU
@dbz400 commented on GitHub (Sep 23, 2013):
I'm playing around then new GE debugger and found out interesting stuff for this game however not too sure what it means
@dbz400 commented on GitHub (Sep 23, 2013):
I have pressed around 30 times that 'Break' button to get that and the missing background showup
@unknownbrackets commented on GitHub (Sep 23, 2013):
That means it's drawing the background somewhere (e.g. to a different FBO.)
-[Unknown]
@dbz400 commented on GitHub (Sep 23, 2013):
I see. Most likely draw to depth buffer as i seen this log ?
27:04:037 user_main W[SCEGE]: GLES\Framebuffer.cpp:610 FBO sharing existing depthbuffer (unsupported), 00088000/00110000 and 00000000/00110000
@unknownbrackets commented on GitHub (Sep 23, 2013):
Well, it's possible. I added those warnings to get a feel for where it is possible and where it's not.
-[Unknown]
@dbz400 commented on GitHub (Sep 23, 2013):
I see.
@dbz400 commented on GitHub (Nov 26, 2013):
Further checking on this missing background , it may be related to wrong pos?
@dbz400 commented on GitHub (Nov 26, 2013):
softgpu renders well though .
@dbz400 commented on GitHub (Jan 19, 2014):
Just tested this again with "Vertex arrays enabled when there's no data passed for them"
Still black in background
@daniel229 commented on GitHub (Jan 19, 2014):
if these games have the same issue, both are missing background.Danball Senki W and Gundam AGE.
software rendering looks good.
Danball Senki W
Gundam AGE is still not good in software mode.
@dbz400 commented on GitHub (Jan 19, 2014):
In Gundam AGE, it suppose to have background in your screenshot?
@dbz400 commented on GitHub (Jan 19, 2014):
For Danball Senki W, i think the background is only able to show using framebuffer to memory like 3rd birthday
Framebuffer to memory or softgpu
Buffered rendering
@dbz400 commented on GitHub (Jan 19, 2014):
@daniel229 , looks like it has background .I found it in a youtube
@daniel229 commented on GitHub (Jan 19, 2014):
Framebuffer to memory does not help Danball Senki W
Gundam AGE have a background in jpcsp
@dbz400 commented on GitHub (Jan 19, 2014):
I see. Thanks. Looks like we are still missing something ....
@daniel229 commented on GitHub (Jan 19, 2014):
Actually, Gundam AGE shows background in software mode,but too dark,look at the top right corner.
@dbz400 commented on GitHub (Jan 19, 2014):
I seen you are using 0.9.6-470 ?
@daniel229 commented on GitHub (Jan 19, 2014):
Don't know what 's wrong with git.
@unknownbrackets commented on GitHub (Jan 19, 2014):
Interesting. What does the GE debugger look like right before it draws that top right thing?
Also - if you are using a savestate, there are times when softgpu will try to render from memory previously rendered to by GLES. Might double check it going all the way in softgpu (I know how painful this is, speed wise...)
-[Unknown]
@daniel229 commented on GitHub (Jan 19, 2014):
I don't using savestate.
I think this is drawing the background.
next the corner thing is showup
The game have terrible graphic in software mode.
this is the title.
@unknownbrackets commented on GitHub (Jan 19, 2014):
Hmm, wonder if it's using beziers. So I guess 0x040cc000 was not drawn correctly...
-[Unknown]
@daniel229 commented on GitHub (Jan 19, 2014):
How to know if it's using beziers.
@dbz400 commented on GitHub (Jan 19, 2014):
I noramlly goto case GE_CMD_BEZIER: (GLES_GPU.cpp)to add something like this to see if it is using bezier
NOTICE_LOG(HLE,"Beizer is used");
@daniel229 commented on GitHub (Jan 19, 2014):
Thanks, @raven02 ,I tried it,that game seems to not use Beizer.
@dbz400 commented on GitHub (Mar 24, 2014):
Regarding this game - Romance Of Three Kingdom 9 PK , missing background .I tried to compare the value return from GLES and softgpu
GLES: framebufferptr : 000888000
softgpu : framebufferptr : 000000000
-GLES
-softgpu
@dbz400 commented on GitHub (Mar 24, 2014):
Offset addr and vertex addr also different .Does it matter ?
@unknownbrackets commented on GitHub (Mar 24, 2014):
Those are just different frames. Framebufptr is gonna alternate, and offset/vertex are going to differ by where the vertex data and list are.
-[Unknown]
@unknownbrackets commented on GitHub (Jun 7, 2014):
Does this look any better these days with "simulate block transfer"?
-[Unknown]
@daniel229 commented on GitHub (Jun 7, 2014):
Nothing change with "simulate block transfer"
@dbz400 commented on GitHub (Jun 7, 2014):
Interesting when i load state , i can see the visible background appear in 1 sec then become black again
@unknownbrackets commented on GitHub (Jun 7, 2014):
Okay, that implies there's a framebuffer there but it's black. So then the question is, what's it doing with this framebuffer?
What does it log after the load state? It should create some FBOs, one of them is probably this scene. Maybe the game is doing its own custom memcpy or something.
-[Unknown]
@dbz400 commented on GitHub (Jun 7, 2014):
Here it is
25:42:558 user_main I[SCEGE]: GLES\Framebuffer.cpp:787 Resizing FBO for 00000000 : 480 x 272 x 3
25:42:560 user_main I[SCEGE]: GLES\Framebuffer.cpp:931 Creating FBO for 00000000 : 480 x 272 x 3
25:42:561 user_main I[G3D]: GLES\ShaderManager.cpp:146 Linked shader: vs 25 fs 36
25:42:608 user_main I[SCEGE]: GLES\Framebuffer.cpp:787 Resizing FBO for 00088000 : 480 x 272 x 3
25:42:610 user_main I[SCEGE]: GLES\Framebuffer.cpp:931 Creating FBO for 00088000 : 480 x 272 x 3
25:42:610 user_main W[SCEGE]: GLES\Framebuffer.cpp:966 FBO reusing depthbuffer, 00088000/00110000 and 00000000/00110000
@unknownbrackets commented on GitHub (Jun 7, 2014):
So those are the only two FBOs? Hmm. And it renders to both if you use the GE debugger?
-[Unknown]
@dbz400 commented on GitHub (Jun 7, 2014):
Yes only this two FBOs .It mainly render to the 0x0000000 one.
@unknownbrackets commented on GitHub (Jun 7, 2014):
What does it render to the other? What if you set a breakpoint on 04088000 for size 00088000?
-[Unknown]
@dbz400 commented on GitHub (Jun 8, 2014):
Let me try
@daniel229 commented on GitHub (Aug 26, 2014):
set a breakpoint on 04088000 for size 00088000,it did not catch anything.
@daniel229 commented on GitHub (Aug 26, 2014):
It render to 00000000 and 00088000 in turn frame by frame.
first frame to 00000000
second 00088000
third 00000000
four 00088000
.
.
.
.
.
@daniel229 commented on GitHub (Nov 5, 2015):
Still no change in v1.1.1-215-gd2701d7
@unknownbrackets commented on GitHub (Nov 5, 2015):
Hrm. If you save state / load state does it still display something?
When loading state, it loads whatever is in RAM behind the framebuffers. That's why it implies to me that it has drawn something to RAM and the framebuffers are just black. But if breakpoints don't trip...
We did fix some missing breakpoint checks, though. Can you double check if they don't trip now? Make sure to set the breakpoints before entering the scene, or else pan the view. It may only redraw when there's a change (possibly...)
-[Unknown]
@daniel229 commented on GitHub (Nov 5, 2015):
save state it still displays the same screen,load state it display a blackscreen then the same bug screen. I set speed to 5%.
From entering to the scene,it's drawing the cloud,and than nothing more than later.
@unknownbrackets commented on GitHub (Nov 5, 2015):
And no hits on the memory breakpoint either?
Software rendering works right? Maybe @raven02's savestate was from softgpu and that's why it worked for a second. Hmm.
-[Unknown]
@daniel229 commented on GitHub (Nov 5, 2015):
breakpoint which address?
@unknownbrackets commented on GitHub (Nov 5, 2015):
04000000 with size 0x110000.
-[Unknown]
@daniel229 commented on GitHub (Nov 5, 2015):
Not hit.
@sum2012 commented on GitHub (Dec 4, 2015):
update the log to v1.1.1-340-g01669cb
https://gist.github.com/sum2012/0860d89bb54d08dbd39e
@unknownbrackets yes,it need soft gpu for work
@unknownbrackets commented on GitHub (Jan 3, 2016):
I've gotten some GE debugger related info on this. Dumping my observations from that data here:
Apparently, the game draws everything fine, until some point when it draws something on the framebuffer with blending. This is when the framebuffer goes black.
This particular draw seems weird. It seems it's drawing lines using rectangles, but:
The last thing is apparently the kicker. By hacking it to avoid this last rectangle, the game seems to draw fine. It's not a block transfer issue at all, then, but instead a clipping one.
On the PSP, per my earlier tests, anything drawn outside the 0,0 - 4096,4096 window coords (translated/scaled via the viewport) gets clipped entirely. Therefore a draw of 8000,4000 should simply be skipped outright. It's accidental and incorrect that it's even drawn.
IMHO, this is a bug in the game, though. Assuming I'm understanding correctly.
-[Unknown]
@unknownbrackets commented on GitHub (Sep 19, 2018):
I expect this to work now - on all backends - now that #11393 is merged. How's it look now?
-[Unknown]
@sum2012 commented on GitHub (Sep 23, 2018):
v1.6.3-497-gead4946fd Win 7 64 bit
Opengl fixed.
Directx 9 fixed.
Directx 11 fixed.
@unknownbrackets commented on GitHub (Sep 23, 2018):
Awesome - I'm going to assume Vulkan is fixed too and close this. Thanks for verifying.
-[Unknown]