PGA Eropean Tour: gauge STILL not working properly
Closed this issue · 28 comments
There should be TWO white markers in the gauge. Both are fundamental for playing correctly this game. One of them is fixed, but the other one changes its position depending upon the power you want to use for your next swing.
In the Angrylion's screenshot we can see both markers, but with GLideN64, only the first marker -the fixed one- appears. The second one -the really useful- never appears, making this game playable but not enjoyable.
The second marker works, but only in LLE mode:
I'll try to find, why it doesn't work with HLE.
This game uses L3DEX2 ucode to draw the line marker
"RSP Gfx ucode L3DEX fifo 2.08 Yoshitaka Yasumoto 1999 Nintendo."
However, opcode of Line3D command is not that we expect. We expect
L3DEX2_LINE3D 0x08
I found that in the debug log:
0x0012AA10: CMD=0x05 W0=0x05020000 W1=0x00000000
UNKNOWN GBI COMMAND 0x05
That is line opcode is 0x05. If I change the opcode, it fixes the marker.
@olivieryuyu, do you remember other games, which use L3DEX2 ucode? Is it anomaly, or we had not-working ucode all that time?
Strange
Glover 2 intro uses RSP Gfx ucode L3DEX fifo 2.05 during its intro and the commands is 0x08.
oops it seems that gliden64 is incorrect with Glover2 !!
The lines should be black. IN HLE it is grey. The stick should be brown.
in LLE (teste with Mupenplus and PJ64). Confirmed in hardware.
Polaris Snocross uses L3DEX fifo 2.07. Command 0x08. it draws the line in the blue box on the top and low part of the screen.
@olivieryuyu, thanks!
I checked Glover2! Yes, the line command there is 0x08, as it should be.
However, it also uses S2DEX2 ucode, but with two unknown commands: 0xD7 and 0xD9. My log:
0x0022A418: CMD=0xD9 W0=0xD9C0F9FA W1=0x00000000
UNKNOWN GBI COMMAND 0xD9
0x0022A420: CMD=0xD9 W0=0xD9FFFFFF W1=0x00000400
UNKNOWN GBI COMMAND 0xD9
0x0022A428: CMD=0xD9 W0=0xD9FFFFFF W1=0x00220004
UNKNOWN GBI COMMAND 0xD9
0x0022A430: CMD=0xE3 W0=0xE3001A01 W1=0x00000010
gSPSetOtherMode_H( G_AD_NOTPATTERN | ) result: 00082c1f
0x0022A438: CMD=0xE3 W0=0xE3001201 W1=0x00002000
gSPSetOtherMode_H( G_TF_BILERP | ) result: 00082c1f
0x0022A440: CMD=0xD7 W0=0xD7000002 W1=0xFFFFFFFF
UNKNOWN GBI COMMAND 0xD7
Could you check, what these commands are?
I doubt that they affect color of the fishing rod, but it is bad to have unknown commands.
@olivieryuyu Regarding 0x05 line command in PGA Eropean Tour:
it seems that L3DEX2_LineW3D command is implemented incorrect.
wd parameter is calculated as
u32 wd = _SHIFTR( (w0 + 1), 0, 8 );
(w0 + 1) is very suspicious. Initially it was
u32 wd = _SHIFTR( w0, 0, 8 );
but I changed it to (w0 + 1) to fix lines in Glover 2. It was 10 years ago.
Total line width is calculated as 1.5 + wd * 0.5.
Currently wd can't be less than 1, so minimal line width is 2.
It makes the second marker look wider than it should be, in compare with GLideN64 LLE and Angrylion LLE.
Could you find, how that command actually should work?
i will have a look to both Glover 2 and PGA. This is going to be a hard work I think.
Glover 2:
D9 is the code for 0xC2 (SDEX v1) = 0x06 (SDEX v2). However there is no uObjTxtr data structure loaded, only uObjSprite.
DA is the code for 0xC4 (SDEX v1) = 0x08 (SDEX v2). However there is no uObjTxtr data structure loaded, only uObjSprite.
D7 with W1=0xFFFFFFFF clears the DMEM (all byte to 0x00) from the previous command where data was retrieved from RDRAM to DMEM.
I would not implement those commands because all of them leads to not display anything during the game. Potentially this is a left over of a debug feature using SDEX or a developer was playing with the microcode.
Let's not forget that Glover 2 was never published and this is only a prototype.
About PGA and command 0x05.
As per manual, L3DEX allows 1Triangle, 2Triangles, and 1Quadrangle of F3DEX microcodes to be displayed using wireframes.
Command 0x05 (G_TRI1) can be used for drawing lines of a triangles.
Actually the RSP code takes 2 vertices (v0,v1) and draw the line, then go to the next vertices (v1,v2) and draw the line and then go to the next vertices (v2, v0) and draw the line.
So CMD=0x05 W0=0x05020000 W1=0x00000000 should not be unknown by GlideN64.
0x5v0v1v2
You have 3 vertices here:
index in vertex buffer 02 (v0). This is also the vertex used for flat shading.
index in vertex buffer 00 (v1)
index in vertex buffer 00 (v2)
As v1 = v2 you have only one line drawn (well the same line drawn twice and a point)
Default line with is 0x03 as I understand (I assume 1.5f). This W can be adjusted with the first byte of W1 (this byte is signed) by adding this default value with first byte of W1.
You can have as well V10, V11 and V11 in the last 3 bytes of W1 in case of (G_TRI2: 0x06)
Glover 2:
0x08 works as other games for LINE3D command.
0x08v0v1W
0x00000000
example
0x08000203
0x00000000
the code takes here only v0 and v1 in the vertex buffer to draw the line.
v0 is also the flag for flat shading.
W is the width. It is by default 0x03 (1.5f i assume) and you can add to this W value a signed byte.
So in our example we would have a width of 0x06 (0x03 + 0x03).
In Glover2 you have also:
0x080002ff 0x00000000
here the width will be then 0x02 (so 1.0f I assume).
My analysis concerns mainly LDEX2 btw. Can be different in with LDEX and Line3D original code.
Will check first LDEX1.
LDEX1: LINE3D
B5000000
00V0V1W
The code draws a line of with vertex V0 and V1. V0 is the vertex for flat shading.
Width is by default 0x03 (1.5f i assume) and a unsigned byte W can be added to this value.
In LDEX2 W0 was used, here it is W1.
LDEX1: command B1 (TRI2) and BF (TRI1)
B1:
B1v10v11v12
00v00v01v02
the code draws line between v10 and v11, then v11 and v12, then v12 to v10, then v00 and v01, then v01 and v02 and finally v02 to v00.
the width is fixed to 0x03 (1.5f). There is no W parameters.
V10 is the vertex for v10,v11,v12 combination for flat shading
v00 is the vertex for v00,v01,v02 combination for flat shading.
BF000000
00v00v01v02
the code draws line between v00 and v01, then v01 and v02 and finally v02 to v00.
the width is fixed to 0x03 (1.5f). There is no W parameters.
the original fast3d ucode for line is siglthy different than LDEX v1. Will check this.
Original Line3D (Fast3D):
B5000000
FFV0V1WW
same than for LDEX1, except that a flag byte FF is set in the first byte of W1 (for flat shading)
If FF = 0x00, V0 is the vertex for flat shading
If FF = 0x01, V1 is the vertex for flat shading
Original TRI1 (Fast3D):
BF000000
FFV0V1V2
If FF = 0x00, V0 is the vertex for flat shading
If FF = 0x01, V1 is the vertex for flat shading
If FF = 0x02, V2 is the vertex for flat shading
Width is fixed to 0x03 (1.5f).
Then 3 lines are drawn between the vertex.
hopefully with all my explanation this should solve the issues spotted so far.
Anything else necessary for this matter? :)
Anything else necessary for this matter? :)
I think, no. You did quite a research, thank you very much! I'll check and fix all line commands implementations.
@olivieryuyu I corrected L3D* commands, thanks for the detailed information.
One problem left: wrong colors for fishing rod and fishing line in Glover2 intro.
Both objects are drawn by LINE3D command.
Color combiner uses only vertex color.
Lighting is enabled (G_LIGHTING is set in geometryMode), so vertex color is calculated accordingly to light colors, flat shading is not used.
Line vertices have gray color, so both lines are gray.
I force disabled lighting and got the correct colors.
The questions:
-
Is lighting always ignored for L3D* vertices? I guess, it should be so, lighting has no meaning for lines.
-
Is flat shading is always enabled? For triangles it works like this:
if G_LIGHTING is set in geometryMode, no flat shading.
if G_LIGHTING is not set in geometryMode
if G_SHADE is not set in geometryMode use Prim shading, that is set prim color as vertex color for all vertices.
if G_SHADE is set but G_SHADING_SMOOTH is not set in geometryMode, use flat shading.
if G_SHADING_SMOOTH is set, use normal shading.
Is it the same for L3D* commands? Or flat shading is always used, for all commands?
Ok it is quite a puzzling situation.
So far what i can see:
Line3D checks out G_SHADING_SMOOTH is set on or not.
If G_SHADING_SMOOTH is set on, the colors are the one set for each vertex.
if G_SHADING_SMOOTH is set off, the colors is the one of the vertex selected for being used for flat shading
For command 0x080002FF 0x00000000, I have geomode 0x00A20405
So G_SHADING_SMOOTH is set on and the colors to be used in this case should be the one for each vertex.
I have in this case:
0x202020FF
0x000020FF
This is dark colors but not may be not black.
I would need to check if colors of the vertex are impacted by G_LIGHTING. I assume so far yes.
Hard nut
Ok there is no lighting code in L3DEX2 so there is no lighting computation to be done. This make total sense.
as G_SHADING_SMOOTH is set on, you should use the original colors of the each vertex.
great!
Lot of work for tiny bugs :)
PR landed.
@dq6
can you close please?
You guys, are awesome! 😃
I couldn't (in name of all gamers of the world) thank you enough for your patience and efforts, making GLideN64 such a miraculous piece of software that it allows playing N64 games directly in Google TV with good speed and that high fidelity... 🙂
Thank you very much!