Horde3D http://horde3d.org/forums/ |
|
[solved] Compile error on 64-bit Ubuntu http://horde3d.org/forums/viewtopic.php?f=3&t=239 |
Page 1 of 1 |
Author: | chris_c [ 17.02.2008, 15:56 ] |
Post subject: | [solved] Compile error on 64-bit Ubuntu |
cd Source/Collada\ Converter; make CFLAGS="" make[1]: Entering directory `/media/data/development/horde/Horde3D SDK [0.14.0]/Source/Collada Converter' g++ -c converter.cpp -oconverter.o -I../../Dependencies/Include -I../Shared daeLibAnimations.h: In member function ‘bool DaeAnimation::parse(const XMLNode&, unsigned int&)’: daeLibAnimations.h:148: error: no matching function for call to ‘max(unsigned int&, long unsigned int)’ daeLibAnimations.h:164: warning: comparison is always true due to limited range of data type make[1]: *** [converter.o] Error 1 make[1]: Leaving directory `/media/data/development/horde/Horde3D SDK [0.14.0]/Source/Collada Converter' make: *** [all] Error 2 There was no configure script and there's nothing in the readme so I'm not sure if I missed a dependency... |
Author: | marciano [ 18.02.2008, 15:04 ] |
Post subject: | |
This looks like a 64-bit portability issue. You could try to cast the second parameter of the max function in line 148 of daeLibAnimations.h to a 32-bit unsigned int. Unfortunately my experience with Linux is quite limited. If someone could create make files which correspond more to the common practice this would be very helpful! |
Author: | chris_c [ 18.02.2008, 19:23 ] |
Post subject: | |
this maxFrameCount = max( maxFrameCount, (unsigned int)(sampler.input->floatArray.size() / sampler.input->elemsPerEntry) ); seemed to fix it but I'm unsure of daeLibAnimations.h:164: warning: comparison is always true due to limited range of data type if( pos != string::npos && pos != s.length() - 1 ) and would you know where I can get a 64bit version or the source to ... /usr/bin/ld: skipping incompatible ../../Dependencies/Libs_Linux_x86/libNvTriStrip.a when searching for -lNvTriStrip isnt "new" hardware fun! |
Author: | marciano [ 20.02.2008, 11:42 ] |
Post subject: | |
I know that some other people have already compiled the engine using 64 bit systems. So I think it should be no problem to recompile the original NvTriStrip source on your platform. About the warning: pos needs to get the type size_t rather than unsigned int. This should fix it. |
Author: | chris_c [ 20.02.2008, 16:04 ] |
Post subject: | |
size_t did the trick however the link http://developer.nvidia.com/docs/IO/116 ... istrip.zip seems to be dead, do you have the source for that and the other dependency? |
Author: | marciano [ 20.02.2008, 16:11 ] |
Post subject: | |
The link can be found in the readme file. Nevertheless here it is again: http://developer.nvidia.com/object/nvtristrip_library.html BTW, I plan to remove this dependency one day but it might still take a bit until I find time for that. |
Author: | swiftcoder [ 21.02.2008, 05:48 ] |
Post subject: | |
marciano wrote: The link can be found in the readme file. Nevertheless here it is again:
http://developer.nvidia.com/object/nvtristrip_library.html BTW, I plan to remove this dependency one day but it might still take a bit until I find time for that. You might want the platform-independent version: here |
Author: | mb108 [ 08.03.2008, 18:51 ] |
Post subject: | |
I found this while trying to get this working in amd64-land. http://users.pandora.be/tfautre/softdev/tristripper/ On the landing page there's no mention of licensing, just that he wanted to "share with the open source community." Might give you a starting point for removing that NvTriStrip dep (seems to be faster too!). |
Author: | marciano [ 10.03.2008, 09:46 ] |
Post subject: | |
Thanks for the link. Funnily I have started replacing NVTriStrip by another custom algorithm the same day. I had to stop to do something else so I can't tell yet about the quality. |
Author: | marciano [ 15.03.2008, 18:15 ] |
Post subject: | |
NVTriStrip has been replaced now. The new algortihm is faster, more stable, clearly smaller and provides even better results. This removes another dependency from Horde so that the only one still left (except OpenGL and the standard libraries of course) is GLFW for the samples |
Author: | mb108 [ 15.03.2008, 22:24 ] |
Post subject: | |
Very nice! This will make Horde3D on Linux much easier. I now have the Horde3D Editor running on 64-bit Linux also. I had to compile Lua 5.1 and drop in a new liblua.a and headers, but after that it builds perfectly. I would like to port/update the Bullet integration example, but I noticed there was talk of altering how NodeAttachments work. Would this still be worthwhile or should I just sit tight until the attachment code stabilizes? |
Author: | Volker [ 15.03.2008, 22:34 ] |
Post subject: | |
Nice to see, that the editor is being used I plan to update the bullet integration anyway, when the terrain extension for the upcoming version is finished. Sadly I currently have to finish some class exercise until next week so it may take until the beginning of april. |
Page 1 of 1 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |