search

JACoders / OpenJK

Community effort to maintain and improve Jedi Academy (SP & MP) + Jedi Outcast (SP only) released by Raven Software
GNU General Public License v2.0
2.01k stars 612 forks source link

MAX_PATCH_PLANES gets hit on some maps that didn't in jasp or jamp #589

Closed ensiform closed 9 years ago

ensiform commented 10 years ago

This error happens upon loading some maps in MP or SP OpenJK engine but did not happen in original.

Known maps: jedicouncil_gcx

Mostly posting issue for reference. Thread on jkhub has more details.

ensiform commented 10 years ago

http://jkhub.org/topic/3990-max-patch-planes-jedicouncilgcx-map/#entry68247

xycaleth commented 10 years ago

The problem doesn't happen if compiled with VS2010... Will carry on investigating tomorrow.

xycaleth commented 10 years ago

I've narrowed it down to a floating point precision issue. It works fine with SSE and MMX disabled. The fun part is when you enable SSE2...

Originally JKA used x87 floating point precision, that is, all floating point operations operate internally on 80-bit floats. With SSE2 enabled, all floating point (FP) operations are now performed in 32-bits (for single precision floats) or 64-bits (for double precision floats). So obviously, there will be some precision loss when using SSE2 over x87 but in the majority of cases this isn't a problem.

I looked at CrossProduct in particular because this is where I first noticed a precision problem (although I don't believe this is the only place where precision is being lost). With the VS2010 compiler and SSE2 enabled, the compiler is converting the single precision floats into doubles and then performing the FP operations. In VS2013, no conversion takes place so all FP operations are performed with single precision. As a result VS2010 and VS2013 get slightly different results which eventually accumulate and cause issues later on.

There's also some dodgy FP operations with mixing large and small numbers will can be a source of precision issues as well. I'll try and fix these types of problems first to see if things improve instead of messing about with SSE2 stuff.

xycaleth commented 10 years ago

Looks like any float operations which were converted to MMX/SSE are using double precision calculations under VS2010.

xycaleth commented 9 years ago

One way of fixing this would be to disable SSE2, but x64 builds would still exhibit the problem because SSE2 cannot be disabled (as far as I know). We really need a way to fix the problem, regardless of the instruction set that's used.

ensiform commented 9 years ago

It also happens in a couple of 3rd party maps in ioquake3 too. And I don't think they use sse2 or any SSE flags in the make file.

xycaleth commented 9 years ago

I'm absolutely sure that you won't hit the problem if you aren't using any MMX/SSE instructions. Unless the code was changed of course.

ensiform commented 9 years ago

Mingw or GCC is probably defaulting it then.

ensiform commented 9 years ago

I think I only tested x86_64 ioq3 though hmm.