If two translucent polygons with opposing patterns overlap the result is always opaque
Also the LOD scale calculation depends on Euclidean distance of x, y and z, not just z
The attenuation value effects the spot light on fog for the scroll fog layer. The old implemention was nearly correct but the paramaters for the mix function were swapped.
- Scroll fog needed a break statement otherwise it could draw potentially multiples times.
- The fog atttenuation paramater doesn't appear to effect scroll fog, other than to potentially enable it. This fixes some issues with emergency call ambulance.
- Added support for the node discard attributes which sega rally2 uses to throw away specific geometry. This fixes junk that starts to show up in the levels after multiple runs.
Polygons have a line of sight value that's either a 0 or 1. We write this value into the stencil buffer, then read the app can read it back to determine the polygon attribute is visible or not. The returned value is 1/depth value in world coordinates. The first bit of the float is actually a control bit, 1 indicates no geometry hit, 0 indicates geometry hit.
We're not blending between LODs yet as we're not sure of the best way to implement it
Also implementing control bits for disable culling and enable model scale (needed for ECA and Harley)
Rewrite the scroll fog shader slightly. Scroll fog is a 2d layer, it has no depth, or can be considered to be drawn at infinity, therefore is not effected by the viewport light. The scroll attenatuion value also I think attenatutes the scroll fog alpha value. This fixes various effects in emergency call ambulance.
For a long time we've had bug reports that in vf3 the background in the Dural levels was the wrong colour, it should have been much darker. We thought it was again missing scroll fog, but gm_mathew worked out it was actually coming from the fogAmbient paramater. Not only does it darken the fog, but it also has an effect on the 2d background from the tilegen, similar to scroll fog. This also fixes the sky in lemans24.
On PowerPC round to nearest ties to even, not away from zero
Also implement correct behavior for ppc_fresx
Fixes "tips to win" sequence in Daytona 2 BOTE
Some games update the tilegen after the ping_ping bit has flipped at 66% of the frame, so we need to split the tilegen drawing up into two stages to get some effects to work. So having the tilegen draw independantly of the 3d chip can make this happen.
Tilegen shaders are mapped to uniforms, and the vram and palette are mapped to two textures.
TODO rip out the redundant code in the tilegen class. We don't need to pre-calculate palettes anymore. etc
The tilegen code supports has a start/end line so we can emulate as many lines as we want in a chunk, which will come in later as some games update the tilegen immediately after the ping_pong bit has flipped ~ 66% of the frame.
The scud rolling start tilegen bug is probably actually a bug in the original h/w implementation, that ends up looking correct on original h/w but not for us. Need hardware testing to confirm what it's actually doing.
There is a quirk of the tilegen chip that causes this glitch not to occur on real hardware, but we can't be sure what it is without testing
Much easier to just patch all the Scud Race ROM sets
The 68K on the soundboard is rated at 12 MHz but runs at 11.2896 MHz, which is 256 cycles/sample with a 44100 Hz sample rate. Removed SoundClock and Freq as they are not needed
Star Wars Trilogy will sometimes write to a JTAG register and then read it back to verify it, but this doesn't work correctly with Supermodel's current JTAG implementation; it will try again and never succeed, getting stuck in an infinite loop. This patch stops the code from branching up and trying the write/read cycle again, allowing the subroutine to continue normally.
We need to implement shift register widths correctly for each JTAG device (Mercury, Venus, Earth, etc.) for the unpatched code to work properly... right now Supermodel implements one JTAG device with a huge 197-bit data shift register
