A place to discuss everything related to Newton Dynamics.
Moderators: Sascha Willems, walaber
by ledahut » Mon Dec 06, 2010 10:33 am
Ok.
But with Kdiff between 2.25 and 2.26 for newton.h
at 350 NewtonGetMaxThreadsCount is new for 2.26
So Julio mistake?
Since July archemedia date has been release in 2210
I don't care, newton is working great.
-
ledahut
-
- Posts: 98
- Joined: Mon Jun 21, 2010 8:03 am
- Location: France
by ledahut » Mon Dec 06, 2010 10:37 am
Oups I forgot,
in NewtonImport_JointLibrary
pinsAndPivoChildFrame is now pinsAndPivotChildFrame
pinsAndPivotParentFrame is now pinsAndPivotParentFrame
But I don't know if it's really important when coding.
Thank you.
-
ledahut
-
- Posts: 98
- Joined: Mon Jun 21, 2010 8:03 am
- Location: France
by Stucuk » Wed Dec 08, 2010 5:16 pm
@Sascha Willems: is your 2.26 based on my 2.24 or one of your earlier versions? (There were bug fixes between your last release and 2.26)
-
Stucuk
-
- Posts: 801
- Joined: Sat Mar 12, 2005 3:54 pm
- Location: Scotland
-
by Sascha Willems » Wed Dec 08, 2010 5:18 pm
It's based on the last header I uploaded, which shoudl be 2.23 if I remember correct. So it's possible that there are still errors in it, but I sadly don't have much time to test everything.
-
Sascha Willems
- Moderator
-
- Posts: 346
- Joined: Fri Aug 27, 2004 10:18 am
- Location: Germany
-
by Sascha Willems » Thu Dec 09, 2010 8:55 am
I just checked the last pages in here, and it seems all the bugfixes are in the header, and some several new ones I've been pointed too. The only thing I seem to have forgotten was to change the reference of the joint library to dJointLibary.dll, that's what I did and reuploaded the headers.
So I hope they're correct now.
@ledahut :
Thanks again for pointing all the misc things out. I also fixed the latest spelling errors you pointed me at!
-
Sascha Willems
- Moderator
-
- Posts: 346
- Joined: Fri Aug 27, 2004 10:18 am
- Location: Germany
-
by ledahut » Thu Dec 09, 2010 12:18 pm
Just downloaded your last version and found
- Code: Select all
{$IFDEF __GPC__}name 'NewtonAddBodyImpulse'
instead of
- Code: Select all
{$IFDEF __GPC__}name 'NewtonBodyAddImpulse'
line 983
Another thing about typed pointer.
Stucuk's headers use typed pointer for mesh function like
- Code: Select all
PNewtonMeshVertex = Pointer;
PNewtonMeshEdge = Pointer;
PNewtonMeshFace = Pointer;
PNewtonMeshPoint = Pointer;
And yours just use 'Pointer'. I am little confuse because I can't judge which is the best (typed or nor typed).
I know I am punctilious. Whatever I don't think there is lot of people using these news mesh function for the moment because of blank wiki about them.
-
ledahut
-
- Posts: 98
- Joined: Mon Jun 21, 2010 8:03 am
- Location: France
by Stucuk » Mon Dec 13, 2010 1:24 pm
ledahut wrote:I am little confuse because I can't judge which is the best (typed or nor typed).
Pointer is bad as people then don't know what procedures/functions you can use it with. If it has NewtonWhatever then you know what stuff requires a NewtonWhatever.
Sascha Willems wrote:It's based on the last header I uploaded
I'll have to update the latest headers i worked on then. Hoped i could just upload it to my site. Don't know when ill get round to it.
-
Stucuk
-
- Posts: 801
- Joined: Sat Mar 12, 2005 3:54 pm
- Location: Scotland
-
by ledahut » Thu Dec 16, 2010 6:33 am
Arguments syntax correspondence with Newton.h
NewtonMeshGetVertexStreams
From wiki
- Code: Select all
void NewtonMeshGetVertexStreams (const NewtonMesh *mesh,
int vertexStrideInByte, dFloat* vertex,
int normalStrideInByte, dFloat* normal,
int uvStrideInByte, dFloat* uv);
From SW
- Code: Select all
procedure NewtonMeshGetVertexStreams(const mesh : PNewtonMesh;
vertexStrideInByte : int; vertex : PFloat;
normalStrideInByte : int; normal : PFloat;
uvStrideInByte : int; uv0 : PFloat;
uv1 : PFloat);
cdecl; external{$IFDEF __GPC__}name 'NewtonMeshGetVertexStreams'{$ELSE}NewtonDLL{$ENDIF __GPC__};
From Stucuk
- Code: Select all
procedure NewtonMeshGetVertexStreams(const mesh : PNewtonMesh;
vertexStrideInByte : int; vertex :
PFloat; normalStrideInByte : int; normal : PFloat;
uvStrideInByte1 : int; uv1 : PFloat;
uvStrideInByte2 : int; uv2 : PFloat);
cdecl; external{$IFDEF __GPC__}name 'NewtonMeshGetVertexStreams'{$ELSE}NewtonDLL{$ENDIF __GPC__};
From Newton.h
- Code: Select all
NEWTON_API void NewtonMeshGetVertexStreams (const NewtonMesh *mesh,
int vertexStrideInByte, dFloat* vertex,
int normalStrideInByte, dFloat* normal,
int uvStrideInByte0, dFloat* uv0,
int uvStrideInByte1, dFloat* uv1);
Wiki code is deprecated
SW code is wrong
Stucuk code is right but it would be better is index [0,1] where the same as newton.h
idem for NewtonMeshGetIndirectVertexStreams
In Stucuk code
NewtonMeshGetNextVertex
NewtonMeshGetVertexIndex
vertex argument is not 'const' where Newton.h says it is.
------------------------------------
Lot of Type are declared but not used
ex:
- Code: Select all
P__int8 = ^__int8;
P__int16 = ^__int16;
P__int32 = ^__int32;
P__int64 = ^__int64;
Long = LongInt;
Unsigned_long = LongWord;
Maybe we could removed them no?
About type, I have refactored Float and PFloat to avoid confusion with other pascal 'uses' (NGDFloat and PNGDFloat)
-
ledahut
-
- Posts: 98
- Joined: Mon Jun 21, 2010 8:03 am
- Location: France
by Sascha Willems » Thu Dec 16, 2010 6:49 am
Thanks again for pointing me to that error. I must admit that I never did use the Mesh functions, as my time for coding is very limited and my current game isn't using Newton, so it's nice if other people point out these errors that otherwise would have slipped.
I just updated the header and uploaded it.
As for the refactoring of e.g. Float : Though it would be nicer to rename it to something like NewtonFloat / NGD-Float this would mean that people would have to change their declarationst to, if they e.g. use several callbacks (submit constraints e.g.). So I won't change Float to something else within the header, but since Refactoring is easily done automatically everyone is free to do it themselves.
Although it would be worth a thought for the final release. So when NGD 2.XX (or 3.XX) is released to the public, it could be a good idea to clean out the header and to refactor some types and declarations. I'll think about this for the next official release of NGD.
And again thanks for pointing me to all those bugs and errors, and if you find more, please let me know and I'll fix the headers ASAP.
-
Sascha Willems
- Moderator
-
- Posts: 346
- Joined: Fri Aug 27, 2004 10:18 am
- Location: Germany
-
by Stucuk » Fri Dec 17, 2010 11:25 am
This is why it would be good to work off one version and update the latest released version each time, instead of working on multiple branches and having different errors in each.
ledahut wrote:vertex argument is not 'const' where Newton.h says it is.
As long as there is no
var then
const isn't needed as its the default.
-
Stucuk
-
- Posts: 801
- Joined: Sat Mar 12, 2005 3:54 pm
- Location: Scotland
-
by Sascha Willems » Thu Dec 30, 2010 6:25 am
I've just
updated my headers to the current 2.29 beta release. You can get them here :
http://www.saschawillems.de/download/ne ... 9_beta.zip@Stucuk :
Maybe it would be a wise idea to setup an account over at sourceforge in order to merge our slightly different headers? I think that would be the best way to unify development.
-
Sascha Willems
- Moderator
-
- Posts: 346
- Joined: Fri Aug 27, 2004 10:18 am
- Location: Germany
-
by Stucuk » Wed Jan 05, 2011 7:08 pm
Isn't sourceforge a bit over the top for a header?
-
Stucuk
-
- Posts: 801
- Joined: Sat Mar 12, 2005 3:54 pm
- Location: Scotland
-
by Carli » Sat Jan 08, 2011 5:41 am
Sourceforge also provides bugtracker functionality and the ability to offer patches.
So why don't use the infrastructure?
-
Carli
-
- Posts: 245
- Joined: Fri Oct 02, 2009 5:28 am
by Kjow » Sat Jan 08, 2011 7:56 am
At the moment I can't help (not enough skill), but I also think that sourceforge could be a valid way.
-
Kjow
-
- Posts: 56
- Joined: Thu Nov 13, 2008 11:33 am
Return to General Discussion
Who is online
Users browsing this forum: No registered users and 4 guests