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.
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
-add a new separate class for crosshair
-crosshair coordinates are calculated by matrix instead of recreating every object at correct coordinates
-add ability to scale crosshair by dpi
-add ability to use bitmap crosshair (located in ./Media/). 32bits bmp format + alpha
-cmd line "-bitmapcrosshair" or "-vectorcrosshair" and/or BitmapCrosshair=0|1 in config file
-these changes are only for lost world game with Crosshairs=1|2|3
don't forget to copy the 2 crosshair images in Supermodel/Media folder
