Horde3D

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...

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!

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!

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.

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?

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

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!).

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.

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

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?

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.