VCMI on Mobile Devices and related talk

I have thought of mobile mode, it would need something more than resolution entry, also implementing it in main version without conditional compilation would be troublesome

so all things in code should be done in #ifdef VCMI__MobileMode blocks
fixes: making able to work on resolution from 320x240 and very low memory
changes to fix:

  • videos disabled and not loaded (and no needing for *.VID files) - the classes for using video will be dummy in Mobile Mode
  • animations will be cached (some of animation files memory would be dropped on SD card to be able unload it from memory) and/or would be loaded partially (some of them would be not loaded even compressed)
  • scallable windows would be divided into more interface parts (eg. adventure map interface would be an element divided into: the map, the minimap with some AM buttons, the status box with rest of adventure map buttons all switchable by tiny 8x8pixels buttons)
  • non scallable windows would feature scrolling with some special features and will be meant as 800x600 scrollable
    requirements to work: qwerty keyboard (may feature some virtual keyboard for non qwerty phones users)

special features for non scallable windows
all: when moving cursor the preview would center around the cursor
battle: when battle animation of move plays, the preview follows moving creature (to not blink it would show center on the first attacking creature when contrattacked)
Town Menu- would be divided into plain non scallable menu of only town view, rest of menu (armies and infos) would be hidden, and accesible from tab button

special features for divided windows:
some of them would be able to switch around using tab key
some of them will have tiny 8x8 pixels symbols to switch to desired subwindow
adventure map interface would be an element divided into: the map, the minimap with some AM buttons, the status box with rest of adventure map buttons
hero interface would be divided into: stats box, garrrison box, and paperdoll (wearing of artifacts)

PS: I may work on some code for it, and it would be funny to play vcmi on non-packed-up phone, and i hope it wouldn’t need to port any of code out of SDL

EDIT: not all thoughts from this thread would pass into vcmi especially things from earlier posts like this

What is “very low memory”? 64MB? 32MB? 16MB?
Do you have any specific platform on mind?

Why? Besides, conditional compilation can be pretty troublesome itself.
More complex resolution entries + special set of graphics should be enough.
I don’t see reason for using conditional compilation. “if” is not so slow.

Caching doesn’t like “very low memory”. Playing animations from SD cards will be probably too slow. On N900 animations using current code they were slow, you can’t additionally slow it down by keeping them partially on SD. Especially if you think about platforms weaker than N900.

Do you also think about battle screen here? Memory and animations size can be issue here again.

Well it have to be designed to be able to play on phones below 200$
caching is maybe not so good idea, so it has to be changed into unloading almost all unneeded animations
it will be nice if it runs on better phones from 2005 too

well battle screen is special case and is specially able to make optimalisation
the 800x600 scrollable wil be base for it but there many parts could be ommitted in rendering, but it needs good margin too keep smooth (loading def from drive when monster entries 320x240 subscreen won’t act nice)

and yes i think about platforms virtually weaker than N900 (or near it)

@very low memory
it requires perhaps to be 128MB or lower, it will be nice if it could be as low as 64mb
but it takes to consider if it feasible to do (maybe even 256mb isn’t too low but we need to specify target)
virtually any decrase of memory use is wanted

@platform in mind
i have in mind specific smartphone with symbian which is 5-6 years from factory, but I want to make able it to work on virtually any medium class smartphone and perhaps some lower class smartphones

Do you imagine how much work would be needed to make VCMI running on such devices? I’m not even sure if all of libraries we use would work on them. I think it would be a great achievement to make VCMI running on symbian devices without videos and big graphics. As far as I know nobody is interested in wasting tens of hours on doing anything to make VCMI working on smartphones so this discussion is just pointless. If you are interested in spending your time on it then you should start with solving problems in order of occurrence (compiler for symbian? SDL? boost::asio? design of GUI for smaller resolutions?).

I heard that there’s GCC for symbian (although not sure if the g++ part of it works)
I don’t know about boost, but they are tending to be very portable
and Yes - the worst problem is SDL so there may be demand for alternate gui system (praise to not)

I though at gui first because its most outstanding part for me to see.
if this gui is worked and memory use is reduced - we can easily make an Android 320x240 devices port, then symbian would come next

It would be best doing that because I’ll get personal Results from it, and there are no “What the hell to code it!” - just making do working stuff to be able to work on another devices (well there is a need for new gui) - so the most bad problem “what to do now and which concept” doesn’t exist there

yes there will be throng of work - I’ve never got such a big project - but if I have time and I am able to do this I’ll be keen working on it (but the help of somebody other than me may be needed)

No. If it comes out that we need another rendering engine / networking library, we would have a lot of additional work. As of SDL, I’ve found a page with something that looked like Symbian port of SDL. From my experience it’s almost surely incomplete and buggy. I’ve found no info on whether asio supports symbian or not - so most probably it doesn’t.

I don’t get what you mean…

If you have no C/C++ programming experience, you are not able to help us significantly. Our rendering system needs to be tweaked and battle window has to be rewritten… these tasks are hard.

I think you should check OpenTyrian game for Android.
It is running on Android version of SDL, so if you can use that SDL for HOMAM3, port for Android would be much easier.
That SDL port has even virtual keyboard and touch screen support.

Link to Android SDL: … t9218.html

Well I have wise about C++ and somewhat limited programming experience (I code too low frequently, however I code since i was 7, but i started with something another than C/C++)

the part that tow doesn’t understand is about:
"I know how to code things if i know how it works, but if I am about to create new algoritms (or those i never known about) I really don’t know how to bite that"
so in short: I’m pretty well coder, but a bit weak software designer, if you know what I am writing about

SO there I will just need time and no more, because i would know what to do (I feel very unhappy when I don’t know what to do)

the help i stated is just that those work would be probably too low for one person with very limited time, so probably if it have to be finished before VCMI is fully playablethe only me may be not enough

I didn’t state “learn me and I’ll do”, but just "let somebody do part of my work"
Ihave no experience on boost or SDL but mastering those won’t be too hard, as mastering Allegro game library by me was more pleasure than hard work

(more I will tell later)

PS: Johny you made me some hope :slight_smile:

But nobody is going to prepare for you nice UML diagrams for every change that needs to be done to make VCMI work on smartphones. In this case, the coder must be a software designer too. It’s inseparable.

Please, don’t discuss with my experience - you just can’t help here. If you want to help us with coding, fix some bugs. It requires almost no design skill. Leave redesigning of engine to those who know C++ and VCMI structure well enough.

I’m afraid that Dragon is right, even if he sounds a bit too harsh. You simply can’t redesign engine if you are not a software designer.

Graphical engine has been alive and kicking long time before I joined the project. All the interface and technical issues are deeply set in a bottom layer of code and used by countless functionalities, so it may not be possible to replace just any random part of the code. You would better build something on the existing engine, as it was suggested on 480x800 topic. These are the little steps that matter :wink:

There is no point in rewriting the engine for very old devices, as smartphones will significantly improve in performance before VCMI is eventually avaliable for them.

maybe I talked too low precise
I am able to prepare software if i know the way, even if it’s a whole layer
My problem is that I’m lost where I don’t know what to do
Also I’m not good at planning… but if part of existing code tells me what to do next, it will defeat my most limits

Maybe the aim i stated is to great to me for achieve, well I’ll never know if i won’t try

the reason for me needing help is time aspect only - two persons do the thing almost twice as fast

I was able to design part of game, when I followed some mind templates (eg. the map is divided into tiles, and what the tiles is) - just the problem is when there’s too much posibilities - even chess programs use templates for begin duel because it will choke on begin of duel when it have no templates (I had once the chess program where i could remove starting database, and after remowing it, it was playing awful)

I’m relatively good at coding if i want what program is going to do - I’m just weak at algorithm designing - but there’s many existing algorithms to use raw or modified, and also sometimes algorithm is obvious

I’m not trying to rewrite engine - I’m going to build over it - however building from roof sometimes happens to be wrong tactics - I think about some classes become dummy (eg video ones) to work nicely with existing code when removed - I also wanted to redesign some interface to be able to work on 320x240, also building on top of existing classes - also probably some nice memory manager and it’s enough for making so called “Mobile mode”

Perhaps some changes could share code with ones for 800x480 - it would be fine
the video part really needs conditional compiling (to not link video library statically nor dynamically)
perhaps memory manager should use some of conditional compiling to avoid it beeing too strict making game too slow

well when i hear you I totally agree that interface part should share something with those for non-mobile.

and the reason for making it able to run on symbian devices isn’t to enable too work on old ones - but on cheap ones - when you want to buy cheap smartphone you can choose between weak new ones and the elder which was the best at its own time
so i’m not going to do it work on phones which is both OLD and Weak in Time of Production

and thinking symbian things are old is not fully true - nokia is going to build it’s own system on top of symbian and it looks like it going to be backwards compatible - so symbian port isn’t so minor

I know I should precise better my goals to know what is possible and what is very hard to do - but mayor part of idea is to make VCMI work on smartphones which come with 320x240 pixels screen and have memory card slot - if not all then most of it

the reason i mentioned the old phone i think is that I am able to buy that phone which was 750+ PLN at date of production for a half a price (well for 429PLN) and it’s much better for that price than new ones in same price (you almost can’t buy a new smartphone for the price) - so new ones which come for 600+ PLNis a good aim to cover my personal aim (well that’s more 200$ on American market but i hoped that also some a bit weaker machines could handle it)

nowadays smartphones with screen greater than 320x240 px is really expensive, so making able to play at this resolution is fair aim, so it perhaps it could be working on cheapest smartphones in 2012 on somewhat later

If nobody want to help me I could start alone - just it would take ages - and im not good at waiting for something to work so perhaps if nobody come in the year to help me in the aim I would surrender

One major problem is that SDL doesnt support hardware accelerated blitting in X11. You have to use Xlib wie XClipMask or some work arounds with Masks changing graphic contexts. This would speed up rendering for linux smart phones which use X11. I dont know how big the graphics are but the freerunner has 8 MB graphic ram and 128 MB normal RAM. For blitting it should be fair enough, when there is just a transparent color and no full alpha channel.

Else you have to port graphics… oh man sounds like lots of work.

we can do something like interlace but not for screen - for vidmemory
we would fill graphics buffer only with part of graphics then free then another part
(it would decrase speed greatly)

another way is to precise precisely which graphics is used and which is not - then some can be freed semi-permanently

well - I don’t know much about low level graphics… wait! there’s patch for SDL to use OPENGL isn’t it? I believe opengl can be accelerated under x11… however the video memory under 32 MB is reaally pain in ass

so the best use is to do strict memory manager for graphics - it’s most sense way to do it - also perhaps keeping images in memory as no greater than 16bpp would help… hmm 320x240x2=153600 bytes for only a screen - well it could be done on 8MB but we need to make strict which is used and which is not loaded. for reduce memory use per image we can use SDL-sprites (it reduces memory kept by pixels same color near - and then transparency pixels which are huge memory eaters in heroes graphics)

but first i would start for adapting interface which is easier, needed for game to work not only to work great, and can share some code with low resolutions for PC
anyway when we have 8MB video memory many things can be done as many things were done in history on only 64kb video buffer and no hardware acceleration and 8MB is much more than 64kb so if we optimise properly it would work on those machines even without lagging - but well it needs really good memory manager

[well i would think more later]

AFAIK SDL1.2 have hardware acceleration but with some restrictions. There is also SDL1.3 in development which supposed to have full acceleration so it may be better to wait for it.

Most of images are stored in same format as file which is 8bpp for Heroes graphics. No need to optimize something here.
Making resource manager makes sense however. I won’t surprise if some of preloaded images which eat memory all the time are not used or something is loaded multiple times.
And what do you mean by SDL-sprites? Only thing I found in SDL is built-in RLE compression for images. Worth to look closer I suppose.

There are at least 3 problems with VCMI and hardware acceleration:

  1. SDL 1.3 is in development for years and nothing suggests it’s going to be released soon.
  2. VCMI performs many pixel-level operations on surfaces which are impossible on hardware surfaces without moving them between RAM and video memory (but it’s slow) or on-GPU programs (very complicated, possibly not portable or too limited in features).
  3. Are 8bpp surfaces with alpha channel supported by hardware? It’s a significant problem since shadows are semi-transparent (and we don’t want everything to be 32bpp).

I’m a developer for the Freerunner Smart Phone. The stupid thing has no for transperency XRender Accelaration. Or even XClipMask, you have to do some work arounds with NAND or OR graphic context for transparent pixels when you are providing a mask.

But its fast 640x480 @ 50-60 FPS even with all blitted as long you stay in Video RAM. Going back from RAM to VideoRAM is deadly at least at this phone. There is a ca. 20 MB / second bandwith from CPU to GPU. And its done via memcpy means cpu time. Do as much as you can on the gpu to save cpu time, use less power (important for mobile phones) and speed things up.

My question: is there only a transparent color or is semi transparency or full alpha channel in Heroes 3?

If there is you can maybe writing some Xlib code for it. But it would low level and a lot of work.

Most graphics have just key color for transparency (no. 0 in palette IIRC) and it’s fully transparent. But some graphics (mostly shadows on adventure map / battle window) have a few levels of transparency (coded by a few of first special colors in palette).

Just for curiosity how would it look like if you remove all semi transparency to handle the images on the gpu? Someone tested it? You could make everything transparent or leave some parts as normal color. Would it be useable (on small screens like smart phones) or is it a stupid idea?

I think it’s possible, we could even have interlaced fully transparent/fully opaque pixels for semi-transparency. Anyway, it’s not our biggest problem.

well thinking about it, i supppose that 128 mb is good target
most of today smartphones have 128mb or 256mb of ram

now I’m a bit richer and i suppose to buy better phone but still it would be symbian one (though it would be one of newest versions of symbian)

well I think on a while it would be horrible to play on 320x240, but we need sizes lower than 800x600 of course

on phones with relatively high resolution it could work with scaling only (but we would have a bit worse quality) so i think i can write a fast image scaling function (it would allow only specific ratios, more precisely only those when we don’t need calculating horrible on multiple pixels calculation)
it could be thought if it’s scaled blit, scale whole image, or scale on load image but i have in mind a class of functor to scaling and it will have two signed char parameters
first if negative ommit pixel every -n pixels, if positive clone pixel every n pixels
second if negative ommit each pixel which position would be not dividable by -n if positive clone each pixel n times,
both if zero disable processing on at appropariate step
i’ll code it on a while later and it would be universal as it could scale to diffrent resolutions and for machines not as weak as phones it could work in real time because it needs aproximately same power as bliting with custom transparent color (however it may be not accelerable so we need then scale blit only late buffers eg. xxxnterface buffers not early boffers eg. buttons or anims nor middle buffers eg parts of interface)
the thing is for windows which can’t be done more lean and is able to do comfort in screen resolutions than is not exact n800 x n600 nor exact 800/n x 600/n (yes the battle screen could fit almost whole screen with 1280x1024 resolution)
it’s flexible because we can achieve almost any ratio that we could be interested in and it could be done for whole project, not only mobile branch

second problem is that interface built on stock 4:3 ratio as was in original heroes does not fit phones which is mostly widescreen and moreover it doesn’t have to follow the 16:9 standard - resolutions as 640x360 800x360 8nnx480 480x2nn and so on are common on high resolution phones
the problem is more important thab on laptops because we will be hurt by scaling down more when it fits less

so the step to control this is to achieve rebuilt interfaces based on original components but reorganised to achieve diffren ratios (it doesn’t have to be exactly the ratio since we have windows but they should be aproximately as common ratios) eg. on battle screen lower bar could become right bar with components reorganised, or on hero screen the hero garnison could become two right rows (4+3, on additional place could fit some buttons eg split and formation) or on castle screen we could move all things which is not part of main picture to the right

the interfaces would be prepared in diffrent ratios but not diffrent scales - it would be task for scaling function - so against having interfaces in diffrent resolutions as is fairly done with adv map interface, we would have diffrent ratios each in one size then scaled blit by fast blitting function

with that simple thing we can avoid scrolling for now, and we will be able to draw bigger windows in bigger resolution or smaller windows in smaller ones so we have caught two birds at one while (or how it translates to english)