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:
anddev.org/code-snippets-for … 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

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

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)

[continuation to not make 3pages wide post]

but the problem with low memory and low cpu persists, so we have to think how to do things proper

i think we can have scaled blits and full image memory with static interfaces, but we need to consider what to do eg for battle screen
of course it will won’t work if we scale blit all animations, so we need at least use buffer for whole animated scene and then blit it to screen, but we could do more goodies to performance eg. scale animations of monsters/spells/projectiles at time of loading/uncompressing and then blit it 1-1 on scaled window

we also need to cut down most things that is not needed in short while and with current vcmi is resident in memory (eg. on battle we need only animations of creatures on battlefield and we can load more at time it become needed eg. summon, revive too etc. on battlefield we could enable to avoid remembering some animations and even avoid breathe/focus animation)

of course the managing memory should fit the needs - on 64bit machine with 8gb memory we don’t need to stick to 128mb memory - we could do things faster by using more resident things and we wouldn’t then want to avoid fluffs so the apparature should accept different memory cuttting levels and diffrent levels of defluffing (no defluffing on strong machines)

we should do a memory manager which wisely select what to load/unload and what to keep in memory and make program still works if the resource is temporary unavailable

we could do it at different methods: as unified memory/resource manager with some specific routines or speciality memory managers for different problems (eg. for battle, for town, for adventure map) with very lean common base (if there are things which would be common to all memory menagers which fits our assertions)

also we need to drastically improve the file managers, because it seems they tend to load almost anything once and no reload sometimes, and sometimes it loads files which is almost fully unnecessary

those consideration would fit/help not only to mobile phones

[continuation, phones specific only]

also we need to port thingies to OSes appropriate for mobile phones
all things not hardly dependent on hardware would become easy for symbian and android because they’re based on unix, and both have gcc/g++

symbian is not dead, nokia extensively work on this

one of things which is necessary to consider is how to do hardware acceleration of graphics, because phones have weak cpus

we also need to consider if we have to support exotic things as bada maemo etc. (well we have a maemo port or is it rumour?)

one thing which is extremely specific to phones is networking
hotseat would be easy, definately we need to support wifi, probably we need to support bluetooth, and we need consider if we need callable networking (gprs, edge, 3g) and if so how to mantain them

another problem specific to smartphones is disk space - we should avoid unnecessary writes, and cut down file resources needed to launch vcmi - we need to make able to not include things which won’t work on specific phone - so we need to separate resources for diffrent ratios of screen and not forcefully depend on those files, we need to be able to separate resources for really big screens - all things over 1280x1024 or even more precisely,
we need to be able to cut down sounds - making able to have better compresed music or able to left all music, and definately we need to make vcmi not dependent on video resources - i think it’s best to not play bink and smack on phones at all

probably we need consider windows mobile as separate platform, but what with windows phone 7? it has even no sd-card slot (licence require hardware to not include it)

and well should we support iphone os or not? it’s relatively uncomon target but worth to consider support

we need also to consider making able to work on low tech machines which is not exactly phones (pda, palmtops, portable game consoles, oreven weider thingies), or machines which is common but really weak (well we don’t need to support pre-x86 machines, but sparcs and 10-15 year old PCs would be nice, also support for windows 95/98/ME or commercial unix, maybe even dos port?)

GOOD NEWS
Boost on symbian has asio!
almost all parts of asio works
(serial port doesn’t work an maybe some others, but hopefully we can compile vcmi on symbian