64-bit Upspring

[SpliFF]

Has anybody here had experience building UpSpring for 64-bit.

Kloot claims to have fixed 64-bit compatibility but I've already hit 2 issues that suggest otherwise.

* The first is fltk2 shipped with kloot's UpSpring doesn't build. The error seems to suggest a 64-bit issue.

Code: Select all

filename_list.cxx:66: error: invalid conversion from    int (*)(const void*, const void*)    to    int (*)(const dirent64**, const dirent64**)

* The second is LuaJIT categorically states it doesn't support x86_64 and refuses to build.

I got around the first issue by upgrading fltk2. I don't think LuaJIT is fixed yet though. It appears my options are:

* Figure out how to configure, build and run the project as 32 bit (chroot, build options, etc)

* Replace LuaJIT with Lua.

Just wondering if anyone's been in this position and whether you can recommend a good solution that doesn't require rewriting large parts of UpSpring or performing voodoo rituals when somebody tries to compile.

My preferred option is to replace LuaJIT with Lua (official). Any advice on that would be appreciated as well. It looks like to do that I need to rebuild a lot of SWIG code and I've never used SWIG before.

[imbaczek]

luajit 2.0 should work with x64, try upgrading.

[SpliFF]

luajit 2.0 should work with x64, try upgrading.

I found a discussion thread saying it wasn't getting worked on yet, guess I should have checked the dates.

[SpliFF]

Oops, nope, you're wrong. The x64 port is still under construction - not even beta yeat from what I can tell.

http://luajit.org/sponsors.html

[imbaczek]

google has thrown 8k euros at it this week, so expect quick progress from mike :) iirc luajit 2.0 HEAD works.

[SpliFF]

Still I'm leaning towards converting to Lua. I can't really see where LuaJIT optimisations would be useful for UpSpring (since realtime performance isn't a factor in any of its operations). I haven't looked hard enough to tell whether it needs any LuaJIT extensions yet.

In short, if LuaJIT is only there for performance reasons then it isn't that important and Lua 5.1.4 should be used in its place.

[SpliFF]

Just an update to say I appear to have successfully built UpSpring as native 64-bit linux. Still have cleanup to do like fixing swig lua and some strange relative paths to resources.

Still, looks very promising so far. The GUI loads and imports a sample 3DS file.

[SpliFF]

Just an update for people who were getting nervous about my comments about bypassing UpSpring in the modelling workflow. I am still working on Upspring, in fact it's my top priority outside of work/life balance. It will still be a useful tool for a long time, whether it's actually needed or not.

The hold-up at the moment is simply that the UpSpring source code was in a pretty sorry state. I've had to update most of its libs so it will build as a 64-bit application on my system. It also had so many compiler warnings that it was difficult to really see what was going on during compiles.

I've fixed most of the remaining 64-bit issues (kloot fixed many as well) and about 97% of the warnings. This will make future development much easier.

The next step will be repairing the Lua wrappers which have been broken by a switch from LuaJIT to Lua. This was required due to LuaJIT having no stable 64-bit implementation. I'll need to learn more about using SWIG before I tackle the Lua part.

The final step will be going through my todo list to support clean import/export of models and Lua metadata.

95% of the automation stuff will be done using Lua scripts, this will let people with Lua knowledge download or create their own batch scripts. UpSpring already had support for this, however I'm not sure what state it was in even before I went and broke the Lua wrapper.

I guess ETA for a testing release will be about 1-2 months.

[Masse]

Just an update for people who were getting nervous about my comments about bypassing UpSpring in the modelling workflow. I am still working on Upspring, in fact it's my top priority outside of work/life balance. It will still be a useful tool for a long time, whether it's actually needed or not.

The hold-up at the moment is simply that the UpSpring source code was in a pretty sorry state. I've had to update most of its libs so it will build as a 64-bit application on my system. It also had so many compiler warnings that it was difficult to really see what was going on during compiles.

I've fixed most of the remaining 64-bit issues (kloot fixed many as well) and about 97% of the warnings. This will make future development much easier.

The next step will be repairing the Lua wrappers which have been broken by a switch from LuaJIT to Lua. This was required due to LuaJIT having no stable 64-bit implementation. I'll need to learn more about using SWIG before I tackle the Lua part.

The final step will be going through my todo list to support clean import/export of models and Lua metadata.

95% of the automation stuff will be done using Lua scripts, this will let people with Lua knowledge download or create their own batch scripts. UpSpring already had support for this, however I'm not sure what state it was in even before I went and broke the Lua wrapper.

I guess ETA for a testing release will be about 1-2 months.

While your at it could you add map light settings to Upspring... or just manual light settings so that it models look closer to what they look like in Spring.
I would definitely use Upspring more while I texture my units.

[SpliFF]

Please don't quote an entire post just a make an unrelated point.

Anyway the only part of UpSpring texturing I intend to fix is the DDS/PNG upside-down textures. Lighting is map and settings dependent anyway so UpSpring can't really give you a perfectly accurate picture of how your model will look under different conditions (and I don't feel like setting up manual controls either).

[Masse]

Sorry for the whole quote... I was really tired and been wanting to ask that since you first mentioned you were doing something with Upspring.

But anyway thanks for the answer :)