Hmm. Core vx is also 10mb.
Ill try building QT (there is no official binary release for mingw with gcc 47), but I
m afraid it will be useless waste of time - may fail during linking in case of not enough memory.
Hmm. Core vx is also 10mb.
Ill try building QT (there is no official binary release for mingw with gcc 47), but I
m afraid it will be useless waste of time - may fail during linking in case of not enough memory.
Hmm. Core vx is also 10mb.
Wow. I found some qt is too big complains. Suggestions were to use wx…
I`ll try building QT (there is no official binary release for mingw with gcc 47),
QT Creator allows selecting “toolchains” (recently renamed to kits). So it is possible to use same Qt libraries with different compilers - I have gcc 4.5, 4.6 and 4.7 along with clang. All of them work fine (Unless there is some issue I don’t know about)
+1 for C++ and Qt.
Obviously VCMI is an open source project and you can use to it to develop whatever you want. You can write editor in FreePascal and have fun. However, if you decide to use technology that other developers also know, then your editor can become something so much more than just a private, for-fun project, that’ll die as soon as you stop maintaining it. Making things other people can benefit of is fun. But the most fun for me is when I see something I’ve created starting to live its own, independent life.
Problems I know about - size of QT core library (~10 Mb) plus Qt has its own version of stl (QString, QMap and so on).
Qt is huge, though modular. Size depends on modules used. All of them had about 50MB. 10MB was Core + GUI. But well… binaries size are rarely an issue nowadays.
QString is useful, it is more than reimplementation of std::string. While std::string is basically a no-overhead sugar over vector, QString is Unicode string and supports conversions from/to various encodings.
As for the other types… I have no idea why Qt provides them (historical reasons?), I’d be surprised to see a project that does not allow STL but does use Qt. I developed a few (small) projects in Qt, never used them in my code. Fortunately Qt-containers provide STL-like interface and work with STL algorithms — so Qt containers in API are kinda transparent.
I`ll try building QT (there is no official binary release for mingw with gcc 47),
Building Qt is a pain. It’s worth it. Still, a pain.
Haven’t tried that but it may be what you need: qt-project.org/forums/viewthread/23002/ — Qt binaries built with MinGW 4.7.2.
Edit: there are also MinGW binaries for Qt 5.0.1 RC: origin.releases.qt-project.org/qt5/5.0.1-rc1/
Qt is huge, though modular. Size depends on modules used. All of them had about 50MB. 10MB was Core + GUI. But well… binaries size are rarely an issue nowadays.
And for editor we’ll need at least Core + GUI. But yeah - 10 Mb is not a problem for me at least.
Fortunately Qt-containers provide STL-like interface and work with STL algorithms
…as well as constructors from stl containers.
The main problem is that using our lib for editor will need a lot of stl <-> Qt conversions. Especially string conversions.
Probably we’ll need to add unicode (utf8) for vcmi as well - localizations won’t work with qt othervice. I wanted to add it for some time already and now I actually have one more reason for it (first one is mod localization system)
Building Qt is a pain. It’s worth it. Still, a pain.
Haven’t tried that but it may be what you need: qt-project.org/forums/viewthread/23002/ — Qt binaries built with MinGW 4.7.2.
Thanks. Will try this, and wait 5.0.1.
Building Qt is a pain. It’s worth it. Still, a pain.
I was searching for a long time for proper building Qt apps on linux for windows, but since some time official sources work, just compile them with proper switch:
-xplatform win32-g++ -device-option CROSS_COMPILE=x86_64-w64-mingw32
Full version of my configure:
./configure -xplatform win32-g++ -device-option CROSS_COMPILE=x86_64-w64-mingw32- -opensource -no-phonon -nomake examples -nomake demos -nomake docs -nomake tools -openssl -system-zlib -release -static -no-opengl -fast -no-qt3support -no-xmlpatterns -no-multimedia -no-webkit -no-javascript-jit -no-script -no-scripttools -qt-libpng -qt-zlib -qt-libjpeg -no-openssl -no-nis -no-cups -no-dbus
(most of it is not needed, just for speedup)
Just in case, Tiled got update yesterday.
mapeditor.org/2013/01/tiled- … eased.html
Lots of random features of unspecified use, but teh project is alive at least. I suggest checking its implementation and whether internal structures match VCMI needs.
At least whole GUI and various drawing tools are ready to use.
Also, I think we should wait with map editor until RMG is ready, that is it handles objects in general and is aware of their properties. until then it may be just unnecessary duplication of work or conflicts.
There is a lot to do about Map Editor before map drawing and object properties can be handled. Regarding Tiled – the only nontrivial feature we could borrow from it is placing new object on map I think. The rest of GUI seems to be either trivial of VCMI-specific. And as I wrote, there is a lot to do before we can benefit from Tiled’s solution.
My experiments are also under way. BTW drawing is most trivial part (OpenGL rules), all others are much more complex.
The main problem is that using our lib for editor will need a lot of stl <-> Qt conversions. Especially string conversions.
Strings… well, probably there’ll plenty of copies in the air. I doubt it will be an issue. Strings are really tiny when compared eg. to graphics.
Probably we’ll need to add unicode (utf8) for vcmi as well - localizations won’t work with qt othervice. I wanted to add it for some time already and now I actually have one more reason for it (first one is mod localization system)
Yesm that’d be nice. I also had internationalization support on my “TODO somewhen”. Some issues:
Strings… well, probably there’ll plenty of copies in the air. I doubt it will be an issue.
It’s not their size in memory. This is a lot of conversions between them, a lot of copies that should be updated (unlike game there will be more changes).
However every single UI framework uses its own string class so this is not something specific to Qt.
For localization we can use gettext. But I’ll check boost.locale too.
EDIT:
boost.locale covers gettext functionality and in c++ style. Certainly better.
- how to handle and store utf8 strings?
Store them in std::string? What we need to to with strings:
b) use H3 fonts: use heuristics results of txt’s to determine language and translate chars from .fnt to unicode.
Merging fonts from different languages would be cool but at least Russian fonts have different metrics compared to English fonts.
Replacing everything to use utf16 may take too long (utf32 is not an option due to SDL_ttf)
- how to detect encoding of H3 files? I guess some heuristic based on characer frequency will do fine.
Both detection and conversion between any encodings can be done using iconv. This is small C library, seems to be available everywhere (but I’d like to have confirmation from msvc side)
Current refactoring is map loading code.
Boolean serialization introduced in 3146 does not work for vector can anyone fix it?
I’ll fix it today.
EDIT: Done!
I’ll fix it today.
EDIT: Done!
Smth wrong:
error: no matching function for call to ‘CConnection::loadBooleanVector(bool&)’ and more similar errors.
Wierd. I’ve tried to serialize vector and it compiled OK. I’ll look at it and see what could be wrong.
EDIT: OK, I got it. Stupid mistake. Quite interesting that it wasn’t caught by my compiler.
use gcc
OK, fixed (I hope).
Thanks anyway )
Hosting provided by DigitalOcean