6 commits

Author	SHA1	Message	Date
Ian Curtis	4d1484c0c9	merge conflicts	2024-06-13 13:40:30 +01:00
Ian Curtis	edb11dc223	Performance improvements ... The old texture code was being bottle necked by the texture reads. We mirrored the real3d texture memory directly, including the mipmaps in a single large texture. I *think* most h/w has some sort of texture cache for a 2x2 or 4x4 block of pixels for a texture. What we were doing was reading the base texture, then reading the mipmap data from a totally separate part of the same texture which I can only assume flushed this cache. What I did was to create mipmap chains for the texture sheet, then copy the mipmap data there. Doing this basically doubles performance.	2024-06-13 13:36:30 +01:00
gm-matthew	42e236be0d	Add comment briefly explaining optimization	2024-06-10 15:25:13 -07:00
gm-matthew	f30a8ee2a8	Minor shader optimization ... If the mipmap level is 0.0, we only need to run texBiLinear() for the highest quality texture mipmap Adds around 10-20% more performance in Daytona 2	2024-06-10 15:25:13 -07:00
Ian Curtis	f89da17f17	Fix white gfx on linux / intel gpus. These optimisations originally came from toxieainc	2023-10-27 10:45:16 +01:00
Ian Curtis	6595b9320e	Rewrite the renderer a bit to spit out the finished graphics from the 3d chip on separate buffers. One buffer is for opaque pixels, and 2 more for translucent pixels. Before the frame was composited on the back buffer, which meant the tilegen had to have been drawn first. This way the images are now totally independant of the tilegen chip so can be drawn as soon as the register write 0xC is written to the tilegen. ... 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.	2023-10-14 20:05:00 +01:00