486quake's recently a thing but probably still would mean shit frames for FPU emulation.

PocketQuake's changes were targeting the C versions of the functions as SuperH processors were the concern, 486Quake has assembly changes

I don't know this fork but as I read it seems just to be some way optimized for older x86 CPUs but still requires FPU, right?

But might give a try on my other machine 486DLC with ULSI MathCo that gave me 2,5FPS in original Quake 😀

On my main PC (Sandybridge 2600K) the speed up of 586quake over original is like 540 vs 430FPS. So I'd expect maybe 3-3,5FPS on 486DLC...
UPDATE: hm, I got only 2,7FPS (+0,2).

looks like 486quake fork is reverting all the pipelined FPU optimizations (fxch is gone)

https://github.com/id-Software/Quake/blob/bf4 … e/d_draw.s#L121
https://github.com/goshhhy/486quake/blob/27bd … 6/d_draw.s#L125

but benchmark results show its not having the desired effect
You can try console d_subdiv16 1 to se if less FPU divides when texturing makes much of a difference. no wait, 16 is default, it would have to be modified higher. So you can try d_subdiv16 0 to see how much worse it gets 😀 or disable texturing altogether r_drawflat 1, that removes more than half of heavy FPU code.