Bug in cpSpaceSegmentQueryFirst

Official forum for the Chipmunk2D Physics Library.
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

oh hey... random thought. I am using DirectX 10 and I have heard that can interfere with floating point accuracy. Have you had issues mixing this with chipmunk?
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

Enabled fp:strict.

Didn't help at all

Same behavior
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

Want some numbers?

If the platforms y position is y = -39, then the bug occurs

if the platforms y position is y = -39.0001, then it doesnt

the x position seems to be irrelevant
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by slembcke »

That's a good question actually. I have heard that DX sets some math flags on the CPU that do... something. That's as much as I know though. I guess issues have come up a couple times with LuaJIT and DX. A little Googling comes up with this: http://tracker.openblox.tuxfamily.org/ticket/21 which makes it sound like it's only an issue with DX9 and lower.

I'll try writing an alternate implementation of cpBBSegmentQuery() tonight.

I'm guessing that the only significance of the 39.0 number is that if you move it lower than that it changes from one node to another within the tree because of how other objects in the world are laid out. If you changed the order that you added geometry to your level, I'm guessing you'd find the issue would end up moving somewhere else since it would build a different tree.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

oh yeah, something I probably should have mentioned before.

I am modifying the scales of shapes *once* at run time (while building the level), but I am furiously reindexing them whenever I do. I am doing this by taking their vertices and modifying them. This has never shown to case any issues for me before, but I thought I should mention it. I want to reiterate this is only done during level loading.
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

I'd be very grateful for anything you can do on this. I HAVE to have this thing done in the next 3 days. For now I can disable that tree culling algorithm, but it does hurt my performance very badly.
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

oh dear god....

I cracked open cpBBSegmentQuery, and I instantly see all the floating point operations I always tried to avoid for this very reason =/

Also I cant help but notice that lovely:

INFINITY_HACK.Value

INFINITY_HACK

HACK

^ this word is always comforting
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

MSVC_EVIL_FLOAT_HACK INFINITY_HACK

0_0

ahem?
Beta Carotene
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by Beta Carotene »

extern "C++"{
#include <limits>
}

#ifndef INFINITY
#ifdef _MSC_VER
union MSVC_EVIL_FLOAT_HACK
{
unsigned __int8 Bytes[4];
float Value;
};
static union MSVC_EVIL_FLOAT_HACK INFINITY_HACK = {{0x00, 0x00, 0x80, 0x7F}};
#define INFINITY std::numeric_limits<float>::infinity()//(INFINITY_HACK.Value)


So I tried this for the hell of it. Didn't make any difference. Thought I would just give it a shot
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Bug in cpSpaceSegmentQueryFirst

Post by slembcke »

It's the *only* way I could ever find to make a constant for infinity in MSVC. There are compiler intrinsics for it in the most recent version though I think. That also shouldn't be the issue if it does IEEE floats correctly. Just about every other compiler and language has constants for infinity, and it's perfectly well defined what they should do and how they should act. The alternative is to make a much more branchy/slow version instead. I was trying to be efficient more than clever.

I'm already not so happy with MSVC. -_- It's sort of a PITA to support it since MS actually refuses to implement a 14 year old C spec. I think it was their chief compiler architect that claimed that the spec was too hard to implement and basically said "We don't wanna!". The compromise was to make it compile as C++ code in MSVC and avoid perfectly good language features like designated initializers, variable length arrays, and compound literals. Add on top of that it's peculiar math idiosyncrasies and Win32's multiple calling conventions... Ugh. It's easily the most work of any runtime to support AND it costs money.

/me grumbles

I'm going to eat, fly some helicopters for a bit and then take a closer look.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests