As you know, I’m porting VCMI to the N900 mobile device. I’m pretty close but there are some issues left…
I hope you might consider removing the Mix_Chunk problem what was described by me in the “build error” thread. The similar project fheroes2 (Free Heroes 2) has done so, and I can show you the source. They removed it with a few #ifdefs and therefore still leave it up to you to enable it or not. If I understand it correctly the SDL_Mixer is used for music playback, and they have another solution which probably works just fine. See their source here (click). The problem is that I am forced to use libsdl_mixer1.2 with version 1.2.6 in the long term, which turned out to not compile properly (restricted by Nokia).
I had a look at the config/settings.txt. It sais I shall neither edit nor read it (lol). But I still tried to tweak it to my 800x480@16bit screen, and it fails miserable. The resolution is ignored, instead it complains about the 800x600 not being available (I guess it just switches to the next available, 800x600, which is not supported by the N900). 24bit is still used, SDL complains about it and wants to use 16bit (but is somehow forced not to). And fullscreen doesn’t work at all, it just segfaults.
Last but not least I could never go past the initial in-game screen. I could click the “New Game” button once in my SDK, but never on my handheld. It seems like the screen is either unresponsive (it doesn’t segfault tho), or the click event is raised with a wrong location due to the wrong resolution (like the actual button is out of the screen or not on the corresponding “new-game” image)…
BTW: The N900 is running Maemo 5 which is based on Debian Linux.
EDIT: and SVN Revision 1613…
So far so good, I hope someone has the patience to read this.
Thanks a bunch and keep up the good work!
Daniel
EDIT2: If removing the Mix_Chunk thingy is not an option I just spotted a possible workaround. Still it would be cool…
Actually you can read and edit this file, but it must be done carefully. VCMI supports only resolutions listed below in this file (mentioned also in VCMI manual and our wiki), unfortunately 800x480 is not one of them (some work to support this resolution has been made but there is still a lot to be done). 16bit screen is not supported - you can choose between 24 and 32 bit. There are no plans to add 16bit screen support (you can try to do it on your own, but prepare for long and tiring battle).
No offense, but why would you ever rely on fixed resolutions? Creating it dynamically leaving it open to any past and future resolution sounds a lot more sane to me. I really have no clue how this is achieved in VCMI, if this is non-sense please ignore it.
I’d like to try implement it on my own, but cannot due to lack of time. Guess this is not gonna change until fall this year.
By “not supported” do you mean it’s not featured in the settings.txt or completely restricted from the source code? Adding the resolution did not help, as mentioned.
As I see they made simple interface with two #ifdef-ed implementations, one using SDL_Mixer and one doesn’t. We don’t need such solution if the only problem is version of SDL_Mixer.
I you can’t switch to a newer build, I guess that a few simple #ifdefs on VCMI should also do the trick. Something like:
I wouldn’t give to much attention to this library as it has broken MP3 support (while all H3 music is in MP3 format) and we are planning to replace it.
Custom resolution made with settings.txt will work only for the actual game, main menu will aways use 800x600. I have plans to make pregame also respect settings.txt, it can be done when I receive set of graphics it should use. [Then I’ll extract all the needed options to the settings file.]
Possible… Buttons use positions from original resolution and coordinates in mouse events send by OS are compared against them. But if the resolution is 800x480 then it should be miss only height, not width and the New Game button should be in its original position. Unless the whole thing is somehow scrolled and sends coordinates with changed coords. I have no idea how does it look, so it’s hard for me to give any precise answer here.
As a workaround you may try using hotkeys (‘N’ for the new game, ‘S’ for single player, ‘S’ for available scenarios, scroll with arrows / page up / page down, start game with Enter).
Thanks Warmonger, I’ll move to that thread for further discussion on the resolution…
Any idea what might be wrong with the fullscreen toogle? Is it known to be broken, or is it just me with the wrong resolution?
Sounds like a plan! I’ll try the #ifdef thing but keep in mind it’s gonna be good anytime soon.
Good to hear too! But still I don’t get why you would not scale the graphics. IMHO this is the only sane solution. Expect where it really makes reading text impossible. But in case of a handheld it should not be an issue as you’re sitting pretty close to the screen.
Either case, do you have kind of a list which graphics need to be matched to the lower resolution, and which resolution to use? 800x480? Then you’de have two of them. What about the higher ones?
Regarding the buttons, it turned out to work (after several tries) with the 1024x768 (or 800x600 in the menu, as I learned from you). It freezes after pressing any button tho. This seems to be another issue, or also related to the wrong resolution. I think posting the crashlog here would mess up the topic. I’ll create another thread if this turns out to be an real issue.
It’s been discussed as a possibility with scripting support. With that you could layout the HUD however you want and skin it differently. But scripting support is far into the future.
I don’t know the exact reasons why this isn’t done already, but SDL is meager and doesn’t come with functions for scaling and rotating like a 3D engine would. Working out a formula for the positioning of all elements while also taking into account the sets of images used for different resolutions would also be necessary.
Proper handling of different resolutions is something I’d like see too. If it’s needed I could look into it after I’ve dealt with the artifact screen and when I’m free from work.
It works, but will indeed fail when you have the wrong resolution.
Thanks! The presence and will to help of each one of you is honey to my soul.
Even tho it would be a great step forward to implement the scripting of the HUD, I still strongly recommend to invest into the scaling you also mentioned. It’s the only sane way I could imagine. As you say SDL supports scaling (I was not sure if SDL was used completely or only for the mixer thingy). I can ensure you that the 800x600 pictures and texts will be very readable and give a detailed view on a mobile device like the Nokia N900.
As a proof I searched for an 800x600 screenshot, and scaled it to the 800 pixels width (hence missing some pixels in height). I hope the other cam could capture a good view on how it would look like to scale the 800x600) In fact the N900 seems to have like 4 times more pixels per inch as my normal TFT. When I connect with VNC the screen covers a quarter of my 21" at work. img441.imageshack.us/img441/8162/foto363z.jpg (I admit, the quality of the picture is sh**)
So in my opinion the only problem left is the lower width of the screen. This shouldn’t be a big one if you consider dynamic scaling. The whole screen/area should be have a wider view, imagine scaling the 800x600 down to 640x480 and adding another 160 pixels of land on the left. As a workaround you could either show a black bar of 160px in batlle/town, or 80px on each side. It would be another idea to either implement widescreen battlefields/towns or to repeat the first and last column of pixels until the screen is filled.
So far my twisted thoughts.
Also, thanks for clarifying the fullscreen issue!
Daniel
EDIT: I forgot to mention that serious threading issues come to my mind when it comes to SDL. Guess that might just happen to me too.
EDIT: I just re-read your post and see you said SDL does NOT support scaling. SDL makes use of OpenGL, right? OpenGL is able to scale tho? Maybe we should get rid of SDL?
One more EDIT: I had a short talk with OnionKnight on IRC. It’s fine, SDL doesn’t make use of OpenGL per default. He said implementing scaling needs just to be done, easy enough to implement. I think the original topics are covered in this thread, I’m fine with the answers.
H3 relied and since VCMI recreates H3… We had graphics only for 800x600. Of course, it would be nice to have a dynamic, modular, HUD-like GUI but it’s a matter of priorities. I have limited amount of time and recreating original H3 functionality remains #1. What comes from dynamic resolutions if there is no multiplayer mode nor AI, so no one can play VCMI?
I’m not insane, I just didn’t have time to implement all things I would like to have.
Somehow no one needed it. Moreover, VCMI uses SDL and SDL is slow (it’s all software rendering) and so are all graphics transformations.
All modern PCs support 800x600 resolution (or higher). It’s also often possible to use hardware scaling, many GPU drivers allow to choose how to handle non-native resolutions.
If a device doesn’t support 800x600 resolution then I’d fear that it will suffer from scaling performance hit.
So scaling is either unnecessary or too slow. And always makes graphic look ugly!
Well, you may try it, I don’t know how “powerful” N900 is but I wouldn’t expect too much. I would be surprised if VCMI was running smoothly now, without additional overhead.
I’m not sure if I understood. If the image was 800px wide, how can you scale it to the 800px? It looks as if you just trimmed the top pixels (reducing height) without any scaling.
SDL is used completely - for setting up the window, handling input events, rendering TTF fonts and playing sound effects.
Yeah, I get the point. My thoughts were more related to the planning of VCMI probably. I’d have tried to make it scaling dynamically right from the beginning. But I don’t even have a mere clue what decisions were made for what reason or if it just was inherited from WOG e.g. Forgive me if I sounded like I’d call you insane.
That’s a good point indeed. Did you ever consider getting rid of SDL for performance reasons? In a later state of development…
IMHO scaling looks ugly if scaled up. Scaling down should not be a problem. You’d just have to make sure that scaling doesn’t make graphics (e.g. text or minimaps) impossible to use the way they are meant to be used. Set a limit for down-scaling or something…
Well, it features a 600Mhz CPU which I currently overclocked to 850Mhz. There are people that successfully OCed to 1150Mhz. Memory is a decent 128MB… Guess it may run smoothly?
Guess I was a bit confused. I just zoomed in that far, that the picture matches the screen width, which indeed is the original width of the picture. The purpose was to show that the text is quite readable on a screen that is quarter or even less the size of one that is usually featured with 800x600 resolution. (Without making images/text bigger)
Thanks you!
OnionKnight sounded quite promising, we should ask him to give it a try. That way you could focus on the missing H3 functionality and he could try to implement scaling and eventually replace SDL?
Yes! Yes! Yes!
IMO, in this moment the AI and MP mode (HS and online) seems to be the most important, cause it will create a lot of work for tester and a lot of bugs which could be solved by less experienced programmers. Bugs resolving.
Then ofc implementing all thing included in VCMI-status and make VCMI as good as OH3. Bugs resolving.
Later all other things which are add-ons, mods etc. Bugs resolving.
We were thinking about replacing SDL (actually - drawing code using SDL, SDL is also used for several other things like event handling) with OpenGL. It’s the only way to have significant speedup but there are several issues.
OpenGL is less portable than OpenGL. It would be best to have two alternative graphic backends (hardware with OpenGL and software with SDL) but it is not so simple. OpenGL is not a magic box that makes every operation faster, it requires a different approach. Making a good OpenGL backend would require a lot of work. SDL is slow but - again - modern PCs are fast enough handle it.
OpenGL support is now something I moved to my post-1.0 wishlist.
It may
VCMI requires about 800-900 MHz, a little more may be required for battles (depending on armies size) and much more (~1200MHz?) for smooth map scrolling during hero movement (it can be turned off in settings.txt). That are approximate values, I don’t have CPU slow enough to verify it, moreover CPU frequencies are not the only factor affecting VCMI performance.
However if we are thinking about N900 port there are things that may help. If resolution will be reduced to 800x480, it will give speedup. * If support for 16bpp screen is done properly, it should also speed things up.
So I think it’s possible to have VCMI working smoothly on N900, even with SDL
Thanks you for your post! OnionKnight doesn’t have the time to do the scaling thingy anytime soon…
Sorry for being silent for a while, I had (and still have) issues with my car and motorcycle. Additionally I ported libboost 1.42 to Maemo. After doing so I know that libboost cannot be the problem for the errors that happen to me. I also rebuild VCMI with libboost 1.42 to make sure.
As this thread is originally meant to be used for errors and other issues, I’ll ask here. Some console output - I pastedbinned it as it would clutter up the post otherwise:
The second log is clearly a failed assertion in VCMI which should be reasonably easy to fix. The rest of logs suggest problems with SDL - probably VCMI uses it in a way not allowed on your platform. You should try to obtain more meaningful call stacks for those bugs.
Okay, I’m using SVN 1613 IIRC, but the latest SVN had linker errors on building when I tried it last time. (Guess the Makefiles are not updated with the VS project files) Just for your information. I may try if the latest SVN fixes the failed assertion. Or don’t you think this is already fixed?
I tried to get more meaningful call stacks by GDB, but GDB segfaults for unknown reason… Maybe could we first investigate in the second log?
The second log is simple. that printAt function just needs to be extended to support 16bpp screen. It shouldn’t be hard to do but I don’t think it’s the only place that needs fixes for 16bpp.
Ah, yes, but shouldn’t it be like initializing SDL with 16bpp, instead of 24/32? Then it would always use it per default. I don’t know the source at all tho. Is anyone willing to investigate and eventually fix this? The N900 only has a 16bpp screen…
As you said there are no plans to add the support, I guess you’re not willing to have a look at it?
The problem is with our functions which assume the screen is 24 or 32 bpp. Initializing SDL with 16 bpp is not enough.
Currently I have problems with my new hard drive so I would have to set up development environment on my old drive. Additionally I’m working on another project… and I fear that this problem with printAt function is just an edge of the wedge.
Thanks! After your post I thought I just might give it a try:
It turns out all issues disappear by running my Xephyr at 800x600x24@fullscreen. I could start a new scenario and do everything in game (5 minutes playing time). When I removed the fullscreen and switched back to 800x480 (but still 24bpp) it kinda started, but was really slow and ugly (grayscale). Seems like the window mode is not doing well on my scratchbox. So, this proves it’s really mostly caused by the missing support for 16bpp displays.
I added the 800x480 settings.txt by Tow to get the fullscreen back and tried if it worked better. In fact I couldn’t launch the game because of the fixed resolution in the menus. It complains about the 800x600 fullscreen resolution not being available (@hardware-side). So two things need to be done:
Add support for 16bpp screens (to fix the segfaults and crashes)
Dynamically scale the menu screen (entry menu) / add fixed 800x480 menu (to have fullscreen menus / increased speed)
Then I guess it will run perfectly on the N900 (well couldn’t test on the actual device - can’t fake the resolutions there ) The first one is more important, without it the game won’t even start…
May there be a way to ask all active developers if they’d have the time to give it a try? I saw a bunch of people committing to the SVN which do not seem to be active here in the forum. Or maybe they are just in the polish one (which I am not able to read/write)? If nobody is willing to give it a try, I’ll stop asking and tell the people at maemo.org that we have to sit and wait…
PrintAt would be just a beginning. All our functions for blitting 8bpp surfaces with alpha assume that screen has 24 or 32 bpp.
I can try adding 16bpp support after 0.82 release. It needs to be done carefully, because that blitting functions are efficiency-critical.
I’ll try the 
