Promised? 
My bad, I was so sure…
EDIT: Check this out! 
Promised!
“Trying” is something I can always promise 
But seriously it shouldn’t be a big problem. I’d expect more trouble from adjusting pregame to 800x480.
The video is nice. VCMI somehow looks on youtube much better than in reality. 
But that “DOESNT WORK” comment really wasn’t necessary
Well, so far it looks promising I wonder how fast it will be on regular smartphone by the time it will be ready?
Hehe, I guess once you are trying you’ll prolly not give up that fast. So I’m fine with a “try”. 
How can I make 0.82 happen faster? Guess reporting, I just fear I may not find too much time for playing…
Sorry for the comment in the video, it’s really a bit oversized. 
I just wanted to make it clear why I move my mouse like crazy. Guess one would rather think I want to point out a working feature… I’ll change it once I’ m at my computer (cell phone right now). One guy wanted that feature so much for multiplayer, so I guess this should go hand in hand with MP implementation. It’s really nice when it comes to MP games…
Regarding the quality: For me it seemed to look incredible good, not just on YouTube. Probably screensize?
The release is scheduled on August 1st and I want to keep it. I discovered that making releases on the first day of month makes project look much better organized than it actually is.
The only possible help would be testing upcoming development build - the more urgent issues I fix before 0.82, the more time I have later
PS. I assume that your 16bpp is 565 RGB?
Will you make development version few days before?
Yes. I’m going to release development build as soon as we have all advmap objects supported.
I’m really sorry I did not reply for a long time. I had tons of work to do (which is weird as I quit my job) I hope you don’t mind…
Yes, indeed.
Did you already look into the resolution/16bpp thing? I hope my absence did not keep you from giving it a try…
I also owe ubuntux a report of my try to build the latest SVN with the Maemo SDK… Tho I have to set it up first (at home).
Yes, I added support for 16 bpp. I haven’t tested it thoroughly but seems to work (at least on my machine). Try r1739 or later
Since last changes, game crashes at level-up window, pointing some SDL function.
Fixed, thanks for info. r1757
Tow, thank you very much! But using revision 1759 it doesn’t work. It crashes like before. To make sure I tried running at 24bpp and it worked fine. How could I gather some meaningful output for you? The current (probably not very helpful) output is here: pastebin.com/T7fz9Qxs
Cheers,
Daniel
EDIT: Wait, it seems to work if I use a 24bpp Xephyr, but use a 16bpp settings.txt. May it be that the actual game (ingame) runs at 16bpp, but somehow the game menu (the initial screen) still requires 24bpp? I mean as well as the actual game runs at 800x480 but the menu still requires 800x600… Did you just try to run with the 16bpp settings.txt or did you change your screens bpp to 16?
Huh… first of all, VCMI seems unable to open the settings file.
Starting...
Creating console and logfile: 0
Cannot open /opt/vcmi/config/settings.txt !Fix this and we’ll see what’s next. Please also try building VCMI with debug symbols and no optimizations, so we can get correct and readable stacktraces.
Oh sorry, forget about that. This was already fixed, but then the game was just freezing (aka no error output), so I took the previous error (for whatever reason). ><
I just tried again and the game freezes at the entry menu. I’m wondering if the “in the wake of gods” logo could have something to do with it, because it looks really distorted… Have a look at yfrog.com/ndvcmicrashmenup
I built a package including debugging symbols, but in fact I did not manage to make use of them yet. I hope I’ll find out.
Thanks!
Okay, this is what i got from a backtrace:
pastebin.com/edB0y3WZ
Is that of any use for you?
EDIT: When I do not strip the binary, gdb segfaults on “run”. I have no idea how that would be fixable. 
EDIT 2: Without gdb I get the well known freeze in the main menu. But now I managed to open a new game once! I have no idea how, and nothing changed (except the debug symbols), but after closing the game and retrying it froze again. (Keep in mind I have a 100% success rate with 24bpp)
EDIT3: It’s getting weird more and more. Now gdb works again (without a change) and I can get a backtrace with debug symbols: pastebin.com/ePAp2Xcs
EDIT4: More: pastebin.com/kBrv8ngq
EDIT 5: Apparently I can get it to work if I am fast enough (to click on New etc.) and have some luck. Once I’m at the new scenario screen it seems to work fine.
Thank you for information. It seems that video player doesn’t work well with 16 bpp display.
Please try disabling it: in hch/CVideoHandler.cpp:650 add return false; and see if freezes still appear.
Are the first intro videos (3DO and WoG ones) displayed properly?
Tow, you’re a master genius! It works now! Thank you!
The 3DO/WOG entry video was displayed properly. Guess the spinning “in the wake of gods” logo was the only problem…
We need a 800x480 menu now… Fix?
hi there.
so this is advancing! NICE 
For the menu i think (and for that i can be very very wrong) that the bottons could be rearanged to fit the 800x480 screen,no?or keyboard shortcuts?
and i prefered the homm3 sod menu image (ignore this last line :p).
I’m going to try to invent something in photoshop so i can show some sketchs 
Tow, I found a tiny workaround to at least get the thing running on the N900.
Index: vcmi-bin-0.82svn1767/client/CMT.cpp
===================================================================
--- vcmi-bin-0.82svn1767.orig/client/CMT.cpp 2010-08-21 20:48:33.000000000 +0200
+++ vcmi-bin-0.82svn1767/client/CMT.cpp 2010-08-21 20:48:44.000000000 +0200
@@ -255,7 +255,7 @@
}
atexit(SDL_Quit);
- setScreenRes(800,600,conf.cc.bpp,conf.cc.fullscreen);
+ setScreenRes(800,480,conf.cc.bpp,conf.cc.fullscreen);
tlog0 <<"\tInitializing screen: "<<pomtime.getDif() << std::endl;
// Initialize videoIt’s dumb, but prevents the game from crashing at 800x480. Could we somehow check if the resolution is 800x480 (from settings.txt?) and if yes set it like in the patch? Otherwise keep the 800x600. If it makes any sense for you…
Apparently videos work only when using an YUV overlay. Unfortunately this is Linux-specific (or rather non-Windows-specific) code and my knowledge here is limited.
However, you may try my two shots:
1.
In hch/CVideoHandler.cpp:737
replace: PIX_FMT_RGB32
with: PIX_FMT_RGB565 Exclusive or:
In hch/CVideoHandler.cpp:720
replace: CSDL_Ext::newSurface(codecContext->width, codecContext->height)
with: SDL_CreateRGBSurface(SDL_SWSURFACE, codecContext->width, codecContext->heigh, 24, 0xff0000, 0xff00, 0xff, 0)If I receive graphics / layout for that resolution, then I’ll support for them. (Via settings.txt)
If you (or people on maemo forum) are interested in providing missing graphics and layouts, then I can give you a list of currently used graphics and info on needed changes.
Almost. Buttons graphics contain a piece of nearby background. Keyboard shortcuts are implemented and working.
Tomorrow.