zturtleman/spearmint

Add a workaround for MAX_PATCH_PLANES

zturtleman opened this issue · 4 comments

One of the Q3 IHV maps fails to load due to MAX_PATCH_PLANES error. Increasing the max allowed needed 16x size if I remember correctly. So it needs changes to the precision instead.

There are also a lot of custom Q3 maps that fails to load due to MAX_PATCH_PLANES error. In Q3e they load fine, probably worth to look at.

I plan to test that Quake 3 IHV Test map ihv_test1 and some other maps work in Spearmint with MAX_PATCH_PLANES 5000 (instead of the Quake 3 limit of 2048) on all platforms/arch I make releases for.

Maps that error MAX_PATCH_PLANES:

If anyone happens to know other maps that hit MAX_PATCH_PLANES error, let me know. I'll try to test everything in a week or whenever I get back to this issue. (This isn't really serious important testing. I don't expect addon maps to have patches with more planes than ihv_test1, as the Q3 IHV Test engine limit seems to be higher.)


Q3 IHV Test map maps/ihv_test1.bsp hits MAX_PATCH_PLANES error in retail Quake 3 1.16n for Linux and Windows (run using Wine on Linux). (Spearmint supports Q3 IHV Test BSP natively but to test on Quake 3 I converted it to retail Q3 BSP format using my BSP converter.) It seems like Q3 IHV Test either has a higher limit than retail Q3 or handles planes differently.

MAX_PATCH_PLANES required to load ihv_test1:

MAX_PATCH_PLANES Test
4900 Spearmint x86_64 current cm_patch.c
4950 Spearmint x86_64 using Quake3e fix (ec-/Quake3e@447cf6d, ec-/Quake3e@50ed15b)
4750 Spearmint x86_64 using OpenJK fix (JACoders/OpenJK@60072ca)

I only tested MAX_PATCH_PLANES intervals of 50. I'm not saying these fixes are bad; even Quake 3 1.16n won't load ihv_test1.

It doesn't require 16x (MAX_PATCH_PLANES(2048)*16?) as I suggested possibly remembering it as in the original post; at least on Linux x86_64.

Using MAX_PATCH_PLANES 5000 with Spearmint's current cm_patch.c on Linux x86_64 fixes loading ihv_test1 and some addon maps (see list at top of post).

I'm still deciding what to do with it but I'm leaning toward just increasing MAX_PATCH_PLANES to 5000. I don't really want to spend time messing with float precision issues, and I'll still probably have to increase MAX_PATCH_PLANES for Q3 IHV Test anyway. I'm not planning to increase MAX_PATCH_PLANES in ioquake3 as it probably won't stand up to scrutiny and I can't use ihv_test1 as an excuse.

This is really a problem I've spent a lot of time with. A long time ago I had a list of all custom maps that failed to load due to MAX_PATCH_PLANES error. I haven't been looking for such maps since Q3e and I can't find the list at the moment either. As far as I remember, other maps of ROMANET Gael are also affected https://ws.q3df.org/maps/?map=&au=ROMANET+Gael.

Note: You know my heart will always go to Spearmint as it was the best time of my life. Anyways, regarding map loading, I have to say that Q3e outperforms everything else, even Spearmint. The problem is that besides the MAX_PATCH_PLANES error, other errors can also occur when trying to load custom maps, mostly memory problems. As far as I know, with Q3e you can load pretty much all maps, in contrast to other 1.32 based Q3A engines (Xreal/ioquake/Spearmint). At least default Q3 bsp format maps load pretty fine with Q3e. Of course no other format is supported.
So the best of all worlds would be something like a Spearmint-Q3e engine.
But that would almost be as if the programming gods were writing a new idtech3 engine.

Was definitely not on my list, but found this one, due user report: https://ws.q3df.org/map/red_planet_escape_1/