ajtribick wrote:Aha got it (almost) working, though apparently the version of libpng1.dll I've got isn't the right one, because PNG textures do not seem to work.
The program also runs really slowly...
Usually, this is a symptom that you're running with software OpenGL. But if that were the case, Celestia built with the native Win32 UI would also run very slowly. Perhaps there are a lot of errors being generated?
I am confused as to why the Qt version needs libpng1.dll to display PNG textures when the Windows version doesn't (plus, there are no libpng1.dll, zlib.dll files in my Celestia windows installation and that seems to work fine...)
The Windows version uses statically linked versions of these libraries. I've been using them with the Qt4 version as well; it probably makes sense to make this the 'official' build approach, as it means one less thing to explain and one less thing to break. You don't even need to modify celestia.pro. Just replace the lib files with these:http://www.celestiaproject.net/~claurel/celest ... iclibs.zip
Now, these libs will *not* work with the Windows version of Celestia. That's because Celestia-Qt4 is built with MSVCRT (dynamic, multithreaded C++ runtime), while the Windows version of Celestia is built with LIBCMT (static, multithreaded C++ runtime.) Since the Qt4 libraries are by default built against MSVCRT, Celestia-Qt4 and all dependent libraries must be as well. I have't tried building Qt4 with LIBCMT; all that's necessary is to change two lines in mkspecs\win32-msvc2008\qmake.conf:
Code: Select all
QMAKE_CFLAGS_RELEASE = -O2 -MD
QMAKE_CFLAGS_DEBUG = -Zi -MDd
Code: Select all
QMAKE_CFLAGS_RELEASE = -O2 -MT
QMAKE_CFLAGS_DEBUG = -Zi -MTd
work, but since it's not the default for Qt4, we're just building everything with MSVCRT.
If you think all of this sucks, you're right. But, it's nowhere near as much of a nightmare as actually deploying
an app built with a recent version of MSVCRT and getting it to use the right DLLs.