1138 replies to this topic

[esak]

And how is it going? Almost done or do you still need to do a lot rewritting?

[theludicrous]

Please don't pull a 'coder-Chris' on us!

Edited by theludicrous, 09 November 2009 - 01:22 AM.

[Dylijn]

No please dont

[Consoft]

Does it support concave polygons?

[Mordi]

This is great. Seems to be really fast. Finally we can have physics in Vista and 7.

[michael pw]

this is awesome!!
in the future can you please make a stack of tutorials, complex ones and simple ones, i just found the one there now hard to understand, btw what let GmPhysics down was lack of documentation and explanation on lots of the functions.

Please don't let that happen to this, it seems to good!

[Maarten Baert]

I'm still working on this.

Does it support concave polygons?

No, but you can create concave polygons by dividing them into multiple convex polygons. I could even try to make the engine do that automatically, but it's very hard to generate a good subdivision.

This is what I want to do, but I haven't found a good algorithm yet.

[icuurd12b42]

http://blog.touchmyp...s-ear-clipping/

[Maarten Baert]

http://blog.touchmyp...s-ear-clipping/

The first example looks very good, I will add that in v2.1 if possible.

I've rewritten half of the code so far (100kb ). The other half should be easier because I don't have to change it completely.

[icuurd12b42]

http://blog.touchmyp...s-ear-clipping/

The first example looks very good, I will add that in v2.1 if possible.

I've rewritten half of the code so far (100kb ). The other half should be easier because I don't have to change it completely.

The only thing is that people usually define vertices clockwise.... So be careful. I have no idea why the implementation is backwards (or maybe I am).

[Charny]

Nice work. I like it.

[Maarten Baert]

The only thing is that people usually define vertices clockwise.... So be careful. I have no idea why the implementation is backwards (or maybe I am).

My implementation is clockwise. Or did you mean the implementation in the example? I'm not going to copy the code (I am not using any code I don't understand ), I will probably write my own code anyway.

[icuurd12b42]

The only thing is that people usually define vertices clockwise.... So be careful. I have no idea why the implementation is backwards (or maybe I am).

My implementation is clockwise. Or did you mean the implementation in the example? I'm not going to copy the code (I am not using any code I don't understand ), I will probably write my own code anyway.

Yeah, I meant all the examples listed there are backwards. Cool find though. hope it helped.

[Maarten Baert]

I've just discovered another strange GM 'bug': apparently GM shows "unexpected error occurred while running the game" errors for all possible floating-point exceptions. Luckily I can disable this, but it isn't that simple. Enabling or disabling the exceptions takes time. There are three things I can do:
- Avoid exceptions by checking for overflow manually. This is possible but not very convenient. I can only do this when casting doubles (from gm) to other types, but that's not really a problem as the actual code doesn't need casts. This won't stop overflow errors from being thrown during the simulation itself, but I think my code is overflow-safe.
- Disable exceptions when entering the function and enable them again when returning. This is also rather inconvenient, and it will decrease performance. If a game uses EP functions 100000 times per second (3333 times per frame, 30fps), which is reasonable, it will be spending 1-2% of its time enabling and disabling exceptions.
- Disable exceptions when the DLL is loaded. This is very simple, but not very safe. It would break GM code (and possibly code in other DLLs) that relies on exceptions. Moreover it won't work if GM enables the exceptions again (and I have no idea when this will happen).
I'm not sure about the best solution for this problem. What's your opinion?

Edited by Maarten Baert, 25 November 2009 - 03:51 PM.

[icuurd12b42]

yeah, it's your sin/cos... whatever function that expects values from -1 to 1.

sin with 1.000000000001, the value is a floating point impresition which happens quite often

so you have to min(1,max(-1,value))

Some times, depending where you do a dll call with this problem you dont even get exeptions, you find your GM code, after calling a function is skipped... I even had one game going straight from the step even into the draw event of another object, skipping all objects step and end step...

Edited by icuurd12b42, 25 November 2009 - 11:04 PM.

[Maarten Baert]

yeah, it's your sin/cos... whatever function that expects values from -1 to 1.

sin with 1.000000000001, the value is a floating point impresition which happens quite often

so you have to min(1,max(-1,value))

Some times, depending where you do a dll call with this problem you dont even get exeptions, you find your GM code, after calling a function is skipped... I even had one game going straight from the step even into the draw event of another object, skipping all objects step and end step...

No it's not . The only functions I am using are sin(), cos() and sqrt(x*x+y*y). But I was casting doubles to unsigned longs (ids) everywhere and apparently this crashes when the doubles are larger than $ffffffff = 2^32-1 ...
Now i'm using this code:

// gm_cast - cast without throwing exceptions
template <typename A> A gm_cast(double);
template <> inline unsigned long gm_cast<unsigned long>(double d) {
	if((double)((unsigned long)(0x00000000))<=d && d<=(double)((unsigned long)(ULONG_MAX))) return (unsigned long)(d);
	else return 0;
}
template <> inline int gm_cast<int>(double d) {
	if((double)((int)(INT_MIN))<=d && d<=(double)((int)(INT_MAX))) return (int)(d);
	else return 0;
}
template <> inline bool gm_cast<bool>(double d) {
	if(d>=0.5) return true;
	else return false;
}
template <> inline float gm_cast<float>(double d) {
	if((double)((float)(FLT_MIN))<=d && d<=(double)((float)(FLT_MAX))) return (float)(d);
	else return (float)(0);
}

This solves the problem when casting gm's doubles to other types, but it doesn't stop overflows in the simulation code. For example, I can't use this code without checking whether pos1-pos2>1e-100:

double d;
	d = (pos1-best_len)/(pos1-pos2);
	d = ep_clamp(0,1,d); // macro

It's not a huge problem but it would be easier if I could just use 'normal' C++ code.

[icuurd12b42]

you need progressive casts... for example, to bool
bool t = (bool)(short)(DWORD) doublevalue;
from bool
return (double)(DWORD)(short) boolvalue;

but why are you using the troublesome unsigned longs? DWORD should do for IDs... IDs are int32 (int or DWORD), pretty sure about that from the way people reported the value wraping to negative.

I ALWAYS pass through DWORD. Refer to my dll tutorial...


but you will eventually find trouble with the sin cost, guaranteed.

[3dman101]

any possible way one could make a realistic cape movement that flows, flaps, and drags about while hinged about the player's neck?

[PsichiX]

icuurd12b42: for cast double<->bool faster way:

double input;
bool output=(input)?true:false;

bool input;
double output=input; // allowed hidden cast from low-bit size to high-bit size

Edited by PsichiX, 27 November 2009 - 06:56 AM.

[icuurd12b42]

icuurd12b42: for cast double<->bool faster way:

double input;
bool output=(input)?true:false;

bool input;
double output=input; // allowed hidden cast from low-bit size to high-bit size

really? casts are resolved at compile time (is this a cast?), where this is done at run time (is it?). so I do have my doupts, so please enlighten me.