Refactorings

Wow. I found some qt is too big complains. Suggestions were to use wx…

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

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.

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

Edit: there are also MinGW binaries for Qt 5.0.1 RC: origin.releases.qt-project.org/qt5/5.0.1-rc1/

And for editor we’ll need at least Core + GUI. But yeah - 10 Mb is not a problem for me at least.

…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)

Thanks. Will try this, and wait 5.0.1.

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.

@Warmonger

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.

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.

Yesm that’d be nice. I also had internationalization support on my “TODO somewhen”. Some issues:

  • how to handle and store utf8 strings? C++ does not provide any support for them (shame!). If we wanted to stick to standard library, likely wstring with utf16 would be more convenient. (though memory expensive).
    There’s also Boost.Locale library, relatively new addition to Boost (1.48). I don’t know if it is good for us but certainly worth checking.
  • how to make internationalization work with H3-style fonts? (TTF fonts won’t have that issue but… they somehow look wrong in H3). I guess we could collect fonts from H3 distribution in various languages and merge them. There’ll still tons of missing glyphs but it should cover all “standard” usages in given languages.
    By the way, does anyone know how H3 handles languages that have more than 255 characters, like Chinese?
  • how to detect encoding of H3 files? I guess some heuristic based on characer frequency will do fine.

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.

Store them in std::string? What we need to to with strings:

  • detect length (in printable characters) of whole string or length (in bytes) of symbol. Implementing this is trivial but replacing every case may be not. Mostly limited to string breaking and printing.
  • replace placeholders. Shouldn’t be a problem - all placeholders are in ASCII so current code should work.
  • printing. This can be done:
    a) use ttf. Main source of “wrongness” is that they don’t have shadow but it can printed separately during rendering (trivial - only one file uses sdl_ttf). This along with blended rendering makes them quite similar to H3. Really good results considering that I don’t have Times New Roman but similar Liberation font.

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)

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.

  1. cleanup
  2. use BinaryReader

Boolean serialization introduced in 3146 does not work for vector can anyone fix it?

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 :wink:

OK, fixed (I hope).

Thanks anyway )

This container is evil. Wait, vector is not even a container! :confused: C++ madness.

Well, I thought it won’t be used in all possible places (like in rev. 3154) but in a few well-though ones. Maybe FoW or something, but a vector of a few hundred elements shouldn’t be a vector, even if it looks nice for someone who doesn’t know that optimization.