search

ioquake / ioq3

The ioquake3 community effort to continue supporting/developing id's Quake III Arena
https://ioquake3.org/
GNU General Public License v2.0
2.4k stars 529 forks source link

Map loading: some maps produce MAX_PATCH_PLANES error. #186

Open ghost opened 8 years ago

ghost commented 8 years ago

Not sure if this is relevant or of some interest: Some maps won't load in ioquake3 anymore, whereas they will load without problems in vanilla Q3. Motivated by another ones post (at ioquake3 forums) I investigated a bunch of maps that will not load and at least will give an error message.

Here are two maps I found: http://ws.q3df.org/map/a-spec-q3dm2/ and also: http://ws.q3df.org/map/wangctf1/ NOTES:

  1. Both renderers will fail to load the maps (assuming this is related to rendering).
  2. At least on my system the maps won't load: Win 8, Nvidia GTX 770, enough RAM for Q3 :)
  3. iirc the maps were loading in ioquake3 as well, in the past.

NOTE: The maps are custom Q3 maps, NOT QuakeLive maps!

ensiform commented 8 years ago

The issue isn't the renderer. It's the fact that Q3A was compiled with really old compilers lol and modern compilers and SSE have changed handling of floating points and a loss in precision during intermediate calculations. (See below commit comments)

Fixed here: https://github.com/JACoders/OpenJK/commit/60072ca08353db3e82cd068880775c4fda734ace

ghost commented 8 years ago

Oh, that was fast! Thank you for your response, ensiform. You're really clever! Hmm, so there is no chance to load those maps, when compiling a 64 bit exe? I use Cygwin (instead of MSVC). Using the values you refering to, and compiling with ARCH=x86_64 doesn't help.

ensiform commented 8 years ago

You won't be able to fix it without patching the engine as suggested. Modern hardware which is implied by 64-bit will always suffer from this issue. And modern builds with x86 will also suffer too most likely.

ec- commented 8 years ago

>a loss in precision during intermediate calculations I think that we have right opposite situation because old win32 binaries were compiled with /fp:fast option, while modern have /fp:precise - i.e. setting /fp:fast in project properties restores old behavior (at least on msvc2005 compiler and 32-bit builds)

luisvalenzuelar commented 4 years ago

Excuse my noobness. Has this been fixed or not? One comment above suggests a fix in OpenJK but not sure whether this translates into ioq3 or not.