Open Horizon progress demonstration 5

There are a lot of tasks done in this version, like collisions, hud and special weapons, but the most important is that since this release Open Horizon finally feels like an Ace Combat game. It’s not yet feature complete, but already playable and fun.

This release also featuring experimental multiplayer, but don’t expect much – this is the first row implementation and requires a lot of additional work, so expect lags and report bugs.

There is no more requirement to run Open Horizon from ACAH folder, you can run it from other location and will be asked to specify resources path.

Download: Open Horizon 5th Demo

My experience with Ubuntu Touch development.

It’s been a while since I bought myself a Meizu MX4 Ubuntu Edition phone, but I finally found time and motivation to learn more about this new mobile platform from Canonical. I chose to port Allegro game library and my pet project, Return of Dr. Destructo, which is presently also nearing release on iOS and Android as a commercial app, to that platform. This post, however, won’t be very specific to my own projects, but can be used as a general set of answers to some problems with Ubuntu Touch-targeted development of OpenGL apps.

The worst thing about developing for a new platform is lack of coherent documentation. Even Windows Phone, with MSDN and Microsoft’s large workforce had this problem in the beginning, as it was impossible to google answers to even the simplest questions. In this post, I will try do document some peculiarities, problems and solutions of developing an OpenGL application (namely, a game) for Ubuntu Touch. If you’re more interested in developing apps with native UI (QML, QtQuick), then it will be slightly less useful to you, but you may still find something here.

Continue reading

Resources research

I’ve got some progress on Ace Combat resources research, have added code to unpack resources from base containers of AC4-6, besides Assault Horizon. Actual progress is shown here.  Actually, it’s a low priority task I do when I’m stalled with others, so I’m not sure how soon Open Horizon will actually use resources from previous games.


Sound is a different story. I don’t want to mess with legal problems of CRI’s patented HCA proprietary codec until Open Horizon get any descent community around. Possibly, never. Upd: found an open source implementation under MIT license GARbro so I can port that to C++ and use in Horizon without messing with a suspicious source code from japanese boards.

Separate price and currency in Windows Store

Usually, having price as a double value is a very bad mistake. However, in some cases this is necessary, for example when your analytic system requires it, like Amazon Mobile Analytic does. Both Android and iOS provide you with a way to get that information, but Windows (Phone) Store only gives you FormattedPrice string.

And obvious way to get price value from it is to use CurrencyFormatter class provided by Microsoft. However, things are not quite that simple. The biggest question is which locale Store used to create FormattedPrice for you. The answer is a little complicated. It pulls currency (and its symbol) from one place, but it takes formatting (including placement of currency symbol relative to value and thousands separator) from another.

If you create CurrencyFormatter with only currency identifier, it will not be able to parse FormattedPrice in all cases, when user have set different regional settings in different places (for example, if he uses USA store with USD as currency, but his price formatting is done in British style) or if he set up some custom formatting.

So instead we need to use the second constructor. It takes a list of languages, and ID of geographical region. It might not be obvious how it can help our cause, but actually specifying this information allows CurrencyFormatter to pull formatting properties set up for user’s language and use them instead of defaults. However, exactly how it does it is not clear from documentation. Our own testing showed that the last parameter (geographical region ID) does not matter – you can always pass in “US”, but the key is to pass user’s language as the second parameter. Take this with a grain of salt, please: until we know the third parameter NEVER does affect parsing, we need to be cautious about it…

The only remaining question is how to get the locale used by Store. The only answer I found works only in C++ using old WinAPI functions, so it’s only relevant for those who target desktop Windows, or Windows Phone 8.1+ and use C++ to interact with Store. Fortunately, that’s just what we do at work 🙂 So, here’s the final code to get price value from FormattedPrice in Windows Store in C++:

// Assuming we're in LoadListingInformationByProductIdsAsync handler 
// and just successfully received ListingInformation
ApplicationModel::Store::ListingInformation^ listInfo = operation->GetResults(); 

// This gets us currency ID used by store, but language settings used for formatting
Windows::Globalization::GeographicRegion^ geographicRegion 
    = ref new Windows::Globalization::GeographicRegion(listInfo->CurrentMarket); 
Platform::String^ currencyID = geographicRegion->CurrenciesInUse->GetAt(0);

// Now, some WinAPI magic: get us user's default locale, which is used by Store to format things
WCHAR wcBuffer[10];
GetUserDefaultLocaleName(wcBuffer, 10);
Platform::String^ userFormatLocale = ref new Platform::String(wcBuffer);

// Use locale returned by GetUserDefaultLocaleName to populate 
// a list of languages for CurrencyFormatter
Platform::Collections::Vector<Platform::String^>^ v 
    = ref new Platform::Collections::Vector<Platform::String^>();

// Create CurrencyFormatter using the second form of constructor. 
// Please note that I'm NOT sure about meaning of the 3rd parameter!
Windows::Globalization::NumberFormatting::CurrencyFormatter^ formatter 
   = ref new Windows::Globalization::NumberFormatting::CurrencyFormatter(currencyID, 
         v, ref new Platform::String(L"US"));

// Iterate over products in listInfo
for (auto iter : listInfo->ProductListings)
    ApplicationModel::Store::ProductListing^ store_product = iter->Value;
    // Use formatter to parse currency value into double. 
    // A Decimal might be preferable for anything serious, but for statistics it will have to do
    Platform::IBox<double>^ result = formatter->ParseDouble(store_product->FormattedPrice);

    // In case formatter failed to parse the price, to a check
    double price = result == nullptr ? 0.0f : result->Value;  

There you have it. This solution is not without magic components which may fail, but it seems to work in most cases. Please remember, that you DON’T need this most of the time – a price representation in string format should suffice for almost ANY case! But if you really, really need to parse FormattedPrice into double value – there you have it.