Re: [Opentnl-general] CodeWarrior port

[Mark F. <ma...@ga...>]

Hey Norbert,

Great fixes!  We would love to integrate them and have you on board as a 
contributor for TNL.  The only thing we need you to do is to fill out 
the joint copyright assignment form at 
http://www.opentnl.org/contribute.php and fax or mail it back to 
GarageGames.

Thanks for the fix on the Zap struct initializers too -- that one was 
giving me a headache.

- Mark

Norbert Harrer wrote:

>First of all, thanks to Mark Frohnmayer for fixing the
>"isDataToTransmit() bug" about two month or so ago. I never got around
>to thank you for the quick response. Sorry.
>
>Since I am using CodeWarrior 8.3 for Windows, I have ported the tnl
>and Zap source to it. Is there a chance that I could contribute my
>modifications to the official source on SourceForge?
>
>The biggest addition has been made to tnl/tnlMethodDispatch.cpp.
>CodeWarrior is using a 3*DWORD class method pointer, which needed
>another special assembler code in MarshalledCall::dispatch() for
>de-referencing the pointer. The other changes are mostly two-liners to
>solve some compiler depending issues.
>
>To give you an overview, here is the list of changes that I had to
>make in order to get CW to compile tnl, Zap and the other little
>sub-projects:
>
>
>1. Introduced the macros TNL_COMPILER_STRING and
>   TNL_SUPPORTS_MWERKS_INLINE_X86_ASM in:
>
>   tnl/tnlTypes.h
>
>2. CodwWarrior's class method pointer is 3 DWORDs long (no kidding)
>   and the dereferencing is done completely different then in MSVC and
>   GCC/x86.
>
>   MethodPointer has been extended to 3*U32. Also wrote a separate
>   dereferencing assembler code for CodeWarrior in
>   tnl/tnlMethodDispatch.cpp. Altogether, changes have been made in:
>
>   tnl/tnlJournal.h
>   tnl/tnlMethodDispatch.cpp
>   tnl/tnlMethodDispatch.h
>   tnl/tnlNetObject.h
>   tnl/tnlRPC.h
>
>3. CodeWarrior doesn't allow the initialization of an array with a
>   class like it is done with gWeapons[] in zap/gameWeapons.cpp. Same
>   issue with gProjInfo[] in zap/projectile.cpp. I added a constructor to
>   the structs ProjectileInfo and ShipWeaponInfo and did the initialization
>   through those constructors. Changes made to:
>
>   zap/gameWeapons.cpp
>   zap/gameWeapons.h
>   zap/projectile.cpp
>   zap/projectile.h
>
>4. Typedef'ed the types U64 and S64 for CodeWarrior builds in:
>
>   tnl/tnlTypes.h
>
>5. _HEAPOK is not supported in CodeWarrior. So I had to disable the
>   macro TNL_CHECK_HEAP for CW builds. Changes made in:
>
>   tnl/tnlPlatform.h
>   tnl/platform.h
>
>6. CW does not know <memory.h>. <string.h> needs to be included
>   instead. Modifications made to:
>
>   zap/lpc10dec.c
>   zap/lpc10enc.c
>   zap/private.h
>
>7. The function lrintf is already definition in one of CW's include
>   files. The duplicate definition needed to be #undef'ed in:
>
>   zap/ftol.h
>
>8. CodeWarrior for win32 does a "using std::exit;" in stdlib.h. So
>   declaration of ::exit(int) in glut.h causes an ambiguity error if
>   someone include stdlib.h before glut.h. Modified glut.h to use
>   std::exit() instead of ::exit() for CW builds:
>
>   glut/glut.h
>
>9. A similar issue exists with std::malloc, std::realloc and so forth
>   in:
>
>   libtomcrypt/mycrypt_custom.h
>
>
>Regards,
>Norbert.
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Opentnl-general mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opentnl-general
>  
>