Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map loading: some maps produce MAX_PATCH_PLANES error. #186

Open
KuehnhammerTobias opened this issue Apr 17, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@KuehnhammerTobias
Copy link

commented Apr 17, 2016

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

This comment has been minimized.

Copy link

commented Apr 17, 2016

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: JACoders/OpenJK@60072ca

@KuehnhammerTobias

This comment has been minimized.

Copy link
Author

commented Apr 17, 2016

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

This comment has been minimized.

Copy link

commented Apr 18, 2016

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-

This comment has been minimized.

Copy link

commented Aug 1, 2016

>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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.