z-fighting/ps2's lack of mipmapping/painter's algorithm questions

[inlimbo]

my memory might be shoddy here but i want to say constant middle distance z-fighting was less of an issue in older builds of pcsx2. which might just be a consequence of less accuracy in older builds, i suppose, considering the great strides toward accuracy rendering recently

if my memory is correct, my question is: could the more recent extreme z-fighting issues i see in emulation be a consequence of overlooking the ps2's quirks wrt to mipmapping or lack thereof? i would think anyone working on this project is well aware of this but ps2 lacked hardware and SDK support for mipmapping, right? presumably to help with its raw fillrate and transparency bandwidth? you could optionally implement it but most devs didn't, yeah? which is why ps2 had such a rep for aliasing crawling into the distance without mipmaps helping to smooth this out

if that's the case could the emulator's auto-mip mapping be causing more flicker than normal in some games? that said, unchecking in mipmapping in something like vice city does seemingly all of nothing to its flickering

i have some limited/rough and outdated pre-shader opengl standard graphics programming experience, so i have decent conceptual understanding of this stuff and depth buffers and why z-fighting happens, but no super deep knowledge about the nitty gritty of rasterization if some real "to the metal" style graphical issues are happening here during rendering emulation. so i dunno about that stuff, or why 32 bit videocards are a limiting factor as noted here:
PCSX2/pcsx2/issues/3692

but could some combination of an optional forced painter's algorithm and a rethink or reexamination of how the emulator is processing textures into the distance solve a lot of this? does mipmapping interact with depth information? i would think so, i just don't know on the code side personally since i forget and since opengl abstracted much of that from me and largely automated it iirc - presumably still does this

i realize the painter's algorithm is slow. it's not necessarily something you want on by default in emulation, but an option would be cool assuming it would have any affect


edit: another question: are opengl/vulkan or directx driver standards a limiting factor here at all? is there something about the way they render that might subtly influence the way inherently process some depth info or something? i wouldn't think so but i'm also ignorant at this point

[inlimbo]

i mean i do get floating point depth precision issues as they relate z-fighting and 3d rendering precision in general i just don't know why they can't be overcome in this case for all the reasons they were on native hardware or for all the reasons they could be with >32bit floating points. even allowing for occasional the occasional overlooked/unsquashable z-fighting issue on native hardware i'd assume is visible in every single ps2 game ever released (and maybe every 3d game ever) - and that's made more visible in emulation due to res increases and moving on from CRTs - it's clear that pcsx2 is introducing tons of z-fighting not present on native hardware. is it more of an issue of not being able to solve this at reasonable emulation speed on current hardware?

[inlimbo]

god i wish sony hadn't dropped the ball at ps2 launch with libraries/documentation. should've been as library-ready as the ps1. would've made all your lives much easier and i bet we'd have an even more robust pcsx2 presently because of it

its fillrate/blending prioritizing architecture was so goddamned forward thinking for hardware that was finalized before the first pixel shader cards. it's part of why it could compete with the xbox. what the xbox could do in shader code, the ps2 could sometimes match via mere render to texture/transparency blending/post process screen buffer manipulation

if its documentation hadn't been so hostile upfront to the average developer we'd have only seen better looking ps2 games on the whole, even from less technically adept devs

edit: to be clear the xbox or gamecube could also do the hardware-based, non-shader render to texture and post process transparency blends and manipulations the ps2 did (and the gc's famous tex unit thrived on this style of hardware based but flexible texture and framebuffer manipulation) it just couldn't do it nearly as fast as the ps2. ps2 had the fastest transparency/blending bandwidth of all of the consoles, including the xbox, unless there's some edge case where you could customize code so that the xbox could technically outperform it here but i've always heard otherwise. hell, i bet even modern architectures might crawl to some transparency overdraw where a similarly teraflopped ps2 architecture wouldn't