Jump to content
XCOMUFO & Xenocide

Ufo2000 For Nokia 770


Fidel

Recommended Posts

How about a lite version? I'm currently stuck with the required sqlite (which will not be installed on my target system). Didn't figure out how to get rid of the dependencies yet (is it used for server only?

Yes, it is used for the server only. We have plans for removing this dependency for client before the next stable release, but did not have time to do this yet. If you are interested in fixing this issue, you may try to do this yourself and submit a patch :)

Link to comment
Share on other sites

Yes, it is used for the server only. We have plans for removing this dependency for client before the next stable release, but did not have time to do this yet. If you are interested in fixing this issue, you may try to do this yourself and submit a patch :)

I might give it a shot over the weekend. Doesn't look that difficult. BTW, I'm trying to port this to the Nokia 770 thingy. Even with the sqlite it wouldn't work yet (./init-scripts/main.lua:47: CheckDataFiles: crc32 error for file './ufo2000.dat'). I fear some endian problems :-( If I manage, will post screenshots ;-)

Link to comment
Share on other sites

The game did run on MacOS X not so long ago, so all the critical endian related problems should be fixed now already, if we did not add some new problems in the latest revisions :)

 

About crc32 error, I had a similar problem when porting the game to amd64. If it is the same issue, check sizeof(int), sizeof(long) and sizeof(double). We have some typedefs like int32/uint32, etc. They all should have correct size for the game to run. And lua interpreter uses double type for storing numbers, crc32 is being checked from lua, so 32-bit integer value should be converted to double with no precision loss. That means that double type should be at least 64-bit.

 

And it is quite interesting to see the game ported to portable devices =b

 

By the way, what operating system does it run? Are all the library dependencies working there? For example does the allegro demo work?

Link to comment
Share on other sites

Thanks for those hints. Looking into the crc error now. Might be actually some mess I made mixing x86 and ARM versions.

 

By the way, what operating system does it run? Are all the library dependencies working there? For example does the allegro demo work?

The device runs Linux on ARM (very close to normal Debian/Ubuntu), with some modifications, normal X server, normal glibc, etc.

 

And yes, the Allegro demo runs, but the screen detection is notoriously buggy cowardly refusing to run fullscreen 640x480x16, so far :Brickwall: (windowed is ok). Would be *really* nice to get it running at the display's resolution of 800x480. I'm bit worried about the controls, as it has stylus, i.e. you will not see the movement/shooting targetting till you "click", but lets see about it later when I have it running.

Link to comment
Share on other sites

The device runs Linux on ARM (very close to normal Debian/Ubuntu), with some modifications, normal X server, normal glibc, etc.

Thanks, I found some information about this device and it is looks very interesting. I'm even considering to buy it when it gets available for sale at our places :)

 

By the way, do you have access to a real device or just use SDK with emulator? I will check maemo sdk myself as soon as it gets added to gentoo portage tree or even earlier.

 

For making a true port we need to take more attention at resources use, now all the maps and other data gets loaded to memory on start and it is not a problem for desktop pc, but we might run our of memory on the mobile device. Also we seriously thought about dropping 640x480 screen resolution in favour of 800x600, but you appeared just in time to reconsider this :)

 

And yes, the Allegro demo runs, but the screen detection is notoriously buggy cowardly refusing to run fullscreen 640x480x16, so far  :Brickwall:  (windowed is ok). Would be *really* nice to get it running at the display's resolution of 800x480. I'm bit worried about the controls, as it has stylus, i.e. you will not see the movement/shooting targetting till you "click", but lets see about it later when I have it running.

Maybe it is worth reporting these issues at http://www.allegro.cc forums? I'm quite sure that allegro developers would be interested in having a support for this device too.

Link to comment
Share on other sites

By the way, do you have access to a real device or just use SDK with emulator?

I have both, had ported some games already. Gave up on ufo2000 before cause Allegro 4.0 was bad mixture of C and assembly. Now at version 4.2.0RC2 it at least compiles.

 

For making a true port we need to take more attention at resources use, now all the maps and other data gets loaded to memory on start and it is not a problem for desktop pc, but we might run our of memory on the mobile device. Also we seriously thought about dropping 640x480 screen resolution in favour of 800x600, but you appeared just in time to reconsider this :)

So far (on x86) it looks heavy memory and CPU wise. Some 25MB of data ... the rest looks alright. I bet I'd fit into the memory already now. And having it at 800x600 (with option for 800x480) would be nice.

 

And yes, the Allegro demo runs, but the screen detection is notoriously buggy cowardly refusing to run fullscreen 640x480x16, so far  :Brickwall:  (windowed is ok). Would be *really* nice to get it running at the display's resolution of 800x480. I'm bit worried about the controls, as it has stylus, i.e. you will not see the movement/shooting targetting till you "click", but lets see about it later when I have it running.

Maybe it is worth reporting these issues at http://www.allegro.cc forums? I'm quite sure that allegro developers would be interested in having a support for this device too.

Possibly. If I get this running in windowed mode then it is much easier to get fullscreen ;-)

 

BTW, the latest status (didn't spend too much time) is that ufo2000 (rev 936) compiles just nice and all, but then:

"cannot read ./init-scripts/main.lua: No such file or directory"
lf.f = fopen(filename, "r");

and the filename is ok. This seems to be the very first file open in Lua, and it fails. Guess something is rotten ...

Link to comment
Share on other sites

By the way, do you have access to a real device or just use SDK with emulator?

I have both, had ported some games already. Gave up on ufo2000 before cause Allegro 4.0 was bad mixture of C and assembly. Now at version 4.2.0RC2 it at least compiles.

Do you have any idea when they can get available for public (Q3 is already here)? I'm not quite happy to have to maintain support for a platform I don't have access to :( A good example is MacOS, now we have to rely on the reports of of the people having it and we even don't have any idea if revision 936 still works there. Unless you are going to keep an eye on us from now on, we may have troubles supporting this port in the future.

 

Does SDK allow debugging the game in ARM emulation mode? Are all the problems you have already mentioned reproducible there? Well ARM is big endian (right?), having nokia 770 would help to ensure big endian compatibility and help to have a working MacOS port too. But its seems to be a bit expensive just for a toy, so not sure yet :)

 

So far (on x86)  it looks heavy memory and CPU wise. Some 25MB of data ... the rest looks alright. I bet I'd fit into the memory already now.

Right, but it can be optimized. As we did not target mobile devices, we did not pay too much attention to optimizations, but they really should not be a problem. I did run ufo2000 on P166MMX about a year ago and it worked with acceptable performance (could be better though).

 

And having it at 800x600 (with option for 800x480) would be nice.

The game supports any screen resolutions equal or larger than 640x480 now. The idea was to make minimum resolution 800x600 in order to reposition some gui elements, put more things on the screen, have larger and better quality font.

 

BTW, the latest status (didn't spend too much time) is that ufo2000 (rev 936) compiles just nice and all, but then:

"cannot read ./init-scripts/main.lua: No such file or directory"
lf.f = fopen(filename, "r");

and the filename is ok. This seems to be the very first file open in Lua, and it fails. Guess something is rotten ...

 

Hmm. The problem might be here:

// Set current directory to the place where ufo2000 executable was started from
// if no data directory location was specified
   char ufo2000_dir[512];
   get_executable_name(ufo2000_dir, sizeof(ufo2000_dir));
   char *p = get_filename(ufo2000_dir);
   ASSERT(p > ufo2000_dir);
   *(p - 1) = '\0';
...    
   chdir(ufo2000_dir);
...
   lua_safe_dofile(L, "./init-scripts/main.lua");
...

If allegro function get_executable_name is not working quite good, we might have wrong current directory set.

Link to comment
Share on other sites

If allegro function get_executable_name is not working quite good, we might have wrong current directory set.

 

Indeed, this was not working in the SDK and also some lua home dir functions too. But when I got past it, I got it almost running. Some screens (Allegro still not in fullscreen):

 

post-7203-1126011079_thumb.pngpost-7203-1126011094_thumb.png

 

Bad thing, right after the game starts it aborts. Might be sound releated though. Otherwise it is too heavy, I had to kill half of the system to get it that far. And the starting time is rather long (25 seconds) to menu, then 20+ to mission planner, then 20+ to the game. It does look very cute and nice on the screen though :)

 

Some thoughts:

- looks like pixel-doubled gfx, some hires game gfx would be much nicer

- I expect problem with interaction (no right mouse button, no CTRL keys, and no keyboard at all as of now)

- how do I turn off sounds?

- why I don't get any ufo2000.ini file after the build?

- it has the potential to run almost nice, if the memory stays under control

- need to patch lua and Allegro for the file paths (SDK problem only, I hope)

- need proper Allegro support (fullscreen, speed)

Edited by Fidel
Link to comment
Share on other sites

Some thoughts:

- looks like pixel-doubled gfx, some hires game gfx would be much nicer

 

try disabling "enlarged battleview" in options dialog

 

- why I don't get any ufo2000.ini file after the build?

 

if ufo2000.ini isn't found during the start of the game it is automatically created of ufo2000.default.ini

Link to comment
Share on other sites

Indeed, this was not working in the SDK and also some lua home dir functions too. But when I got past it, I got it almost running. Some screens (Allegro still not in fullscreen):

Cool =b If you get any photos of a tablet running ufo2000 later, please post them too :)

 

Bad thing, right after the game starts it aborts. Might be sound releated though. Otherwise it is too heavy, I had to kill half of the system to get it that far. And the starting time is rather long (25 seconds) to menu, then 20+ to mission planner, then 20+ to the game. It does look very cute and nice on the screen though  :)

Excess memory usage is a fixable problem. Also we probably need to insert additional asserts after every memory allocation to at least catch unexpected problems when we run out of memory.

 

But it might be worth compiling the game with all the possible optimizations (-O3 -fomit-frame-pointer -march=...) and assertions disabled (remove -DDEBUGMODE) to estimate if it helps to improve performance a bit. But that can be done as an experiment, removing asserts is dangerous and too early right now as asserts help to find some problems.

 

If you manage to get some fps numbers, that could help to estimate how much work we have ahead (there is 0 fps indicator on the screenshot, does it show anything other than that?). And I guess I will try to run the game in valgrind/callgrind more often in order to simulate slow behaviour (in addition to providing a way to scan for memory related bugs and detecting performance bottlenecks). :)

 

- I expect problem with interaction (no right mouse button, no CTRL keys, and no keyboard at all as of now)

Right, that's probably the largest piece of work. We will need to redesign the user interface so that the game can be usable. N770 has some buttons on its left side, is it possible to emulate right button click with holding one of these keys pressed? Also extra horizontal space can be used to put the buttons which can be used to emulate the keyboard, at least for some of the most important actions.

 

- how do I turn off sounds?

There is no way to turn off the sounds currently. You can try to hack sound.cpp and change DIGI_AUTODETECT/MIDI_AUTODETECT to DIGI_NONE/MIDI_NONE.

 

- it has the potential to run almost nice, if the memory stays under control

Memory requirements can be lowered by not keeping some of the pictures in memory all the time but loading them when needed (soldiers inventory pictures for example or background screens). Also sprites can be converted to allegro RLE sprites, they take less space in memory and also are faster to blit. But they are a bit less flexible, so we don't use them right now. Back to the original problem, cutting off sqlite will not save much, it is only about 200K in a compiled form, but every little bit helps.

 

- need to patch lua and Allegro for the file paths (SDK problem only, I hope)

By the way, if you have any patches which can be safely applied already (without breaking the game on the other platform), you can attach them here. Or even better, you can create the issue report regarding N770 port at our bugtracker: http://ufo2k.lxnt.info/mantis/view_all_bug_page.php

 

- need proper Allegro support (fullscreen, speed)

Just remembered this, did you change screen resolution settings in ufo2000.ini to 800x480 or 640x480? There is 800x600 screen resolution configured by default in revision 936, maybe that could be the problem of nonworking fullscreen support.

 

By the way, is it possible to connect ufo2000 server from the game already?

Link to comment
Share on other sites

Sorry for starting it up and not following it up but have been really busy lately. Thanks for all the hints, they proved right

 

I have had it running for couple of seconds and the FPS went slowly up to 4FPS, then abort. The sqlite seems to be the smallest of problems right now. Will post some real pics if I can keep it running for more than 5 seconds

 

Problems I had relate all to Allegro so far (fullscreen modes, aborting, paths), the game itself builds without problems, it even has sounds in menu and game.

Link to comment
Share on other sites

Promised screens, made in field conditions with cheap digital camera:

post-7203-1126692257_thumb.jpg

post-7203-1126692276_thumb.jpg

post-7203-1126692295_thumb.jpg

 

Sorry for the blurriness of the last one - it just crashes as soon as it shows the game, so I had to shoot it fast :) Will go bug Allero people to get this working on 770 fullscreen (and without aborts). Good news, this time it did run on the normal system, I didn't have to kill anything to get more memory. :beer:

Link to comment
Share on other sites

Thanks for the pictures :beer:

I'm quite busy lately too, so can't spend much time on ufo2000 right now. About performance problems ans crashes. There is one possible problem for crashes - scale2x allocates and frees bitmap for each frame, we might get heap fragmentation quite soon and unavailability of allocate any reasonably large piece of memory (but that's only a guess, I may be wrong). To verify this theory, you can try to set F_SCALE2X variable to 0 in ufo2000.ini and check if the crash disappears. Also in order to improve performance, it is better to set the map as small as possible (4x4 is selectable in the planner screen or even a smaller size can be set in ufo2000.ini) and also reduce the size of battleview screen area (width and height settings in ufo2000.ini). A speed_unit setting is the framerate which provides playing the game on default speed, it is set to 30 by default, it means that game state is updated 30 times per second and the screen is redrawn after each update. If the game can't draw frames fast enough, it skips some, but it still is overly optimistic and supposes that it will be able to manage performing the needed number of game state update cycles (mostly running Map::smoker() function which is terribly inefficient and badly needs to be optimized, you can try to comment it out completely). That means we can even have a game freeze if speed_unit value is too high. I tried to run the game in valgrind and it really puts a top class Athlon64 3200+ to knees providing the same 5-8 fps as you got on Nokia 770 :) When run using callgrind tool, it completely freezes in the battlescape (probably because of the problem described above).

 

Well, an example config file which should probably provide optimal performance without making any changes to the code is below:

 

[General]
width = 390
height = 330
map_width = 2
map_height = 2
# units animation movement speed
speed_unit = 3
...
[Flags]
...
F_SCALE2X = 0

 

Also a useful flag is F_FASTSTART, when set to 1 in ufo2000.ini flags section, it starts the game in the battlescape mode using the settings of the previous game. It is useful when debugging as you don't need to repeat that time consuming soldiers placement routine.

 

As I already mentioned, I'm quite busy right now. I will have some time of this weekend, but I will try to resolve http://ufo2k.lxnt.info/mantis/view.php?id=182 as free graphics for the game seems to be more important right now. But I will surely try to add some of the optimizations which were discussed here to the game a bit later. In addition we can try to implement 'dirty rectangles' technique to avoid full screen redraws but some simplier changes should be tried before.

 

By the way, I managed to send an application to the Developer Device Program just in time before it got closed :) So if it gets approved, I will be able to provide much more help in porting the game to Nokia 770 and will see all the problems with my own eyes :)

Edited by Serge
Link to comment
Share on other sites

I will try to resolve http://ufo2k.lxnt.info/mantis/view.php?id=182 as free graphics for the game seems to be more important right now. But I will surely try to add some of the optimizations which were discussed here to the game a bit later. In addition we can try to implement 'dirty rectangles' technique to avoid full screen redraws but some simplier changes should be tried before.

Could not resist and worked on performance optimizations instead :)

 

Please check SVN revision 946 when you have some time. It has Map::smoker() bottleneck eliminated and also some other performance and memory usage optimizations. Profiling shows that one more bottleneck is the control panel drawing code, at least it takes much more time than it should. I fixed it a bit by calling draw_sprite() instead of draw_trans_sprite() when no transparency is needed (and we don't need it actually now), but we can improve it even more. Also we are not using rle_sprites yet, so we still have a lot room for future performance improvements which can be added later :) At least the game is now almost playable when run in valgrind with something around 10 FPS. I hope we can get acceptable battlescape performance soon (and crashes fixed) and will be able to start working on controls and usability.

 

Also most of the time is spent in allegro functions, recompiling allegro with more aggressive optimizations for ARM might probably help to improve performance. I doubt that their configure script could select the best optimizations settings.

Link to comment
Share on other sites

Really nice. I checked out the 934, compiled, etc.

Is it a typo? The latest revision is 946 at the moment:

http://ufo2000.lxnt.info/changelog.php

 

I would recommend using the latest SVN version and keep your changes in the SVN working copy, you can always update the sources to the latest upstream revision and also you can always create a patch containing all your changes running 'svn diff'. If you have any fixes ready for inclusion in the 'official' sources (even trivial ones), it is better to commit them sooner so that your patchset does not become too big and remains maintainable.

 

It gives up at startup with :

cannot read /root/u2000/cur_map.lua: No such file or directory

Looks like you have F_FASTSTART = 1 in your ufo2000.ini. That cur_map.lua file (along with cur_p1.dat, cur_p2.dat) is created in the planner screen and contains information about the map selected for the mission, cur_p1.dat and cur_p2.dat contain opposing squads placement information. Once you have played at least one game in normal mode (menu -> planner screen -> battlescape), you can use F_FASTSTART = 1 setting to skip mission preparations and immediately start the tactical battle using the previous settings. We don't have a predefined mission data files included with the game as these dat files are binary and architecture dependent (they are not compatible if copied between big/little endian systems for example), also their format can change any time.

 

I'll dig deeper next time I have time. But thanks for the hints, will check them all out B)

OK, thanks for your help.

Link to comment
Share on other sites

  • 2 weeks later...

A few more comments. I have found some docs about ARM architecture. So now I suspect that the crash can be a result of improper memory alignment. ARM seems to be very sensitive to this: http://www.arm.com/support/faqdev/1228.html

 

We need to find the offending piece of code (either in ufo2000 sources or in allegro) and fix it. Considering that you did not encounter the crash before getting to battlescape, that's probably our bug and we are doing something wrong.

 

You can try to make a simple test example which uses unaligned memory access to see how this problem shows up. Preferably we would like to have some exception and program termination (with core dump or something that can be analyzed) immediately on the instruction performing unaligned memory access. Much worse if we only get incorrect memory read/write operation result which only can show up later and can be a lot harder to debug.

 

Also is floating point not natively supported there? If we get it only via software emulation, lua using double as a numeric data type can result in some slowdown (maybe noticeable or maybe not). Lua can be configured to use integer data type to fix this issue.

Link to comment
Share on other sites

  • 2 weeks later...

Now we have an initial (but a bit buggy) version of the game which is selfcontained and does not require external data files from x-com (and as a side effect, by not initializing x-com resources, we have less data to load in memory). Also there were some optimizations done to improve performance and memory footprint.

 

2Fidel: If you are still tracking this thread, please post some kind of "I'm still alive" notice :) Even if you don't have time to do anything for porting ufo2000 to maemo platform at this moment.

Link to comment
Share on other sites

  • 4 weeks later...
Now we have an initial (but a bit buggy) version of the game which is selfcontained and does not require external data files from x-com (and as a side effect, by not initializing x-com resources, we have less data to load in memory). Also there were some optimizations done to improve performance and memory footprint.

 

2Fidel: If you are still tracking this thread, please post some kind of "I'm still alive" notice :) Even if you don't have time to do anything for porting ufo2000 to maemo platform at this moment.

 

Hi guys. I'm back here after month or so being overloaded with the release work. Will be back as soon as I have time. Fingers crossed. This would be so nice for our weekly "Friday afternoon 770 gaming session" at office =b

Link to comment
Share on other sites

  • 2 months later...
A few more comments. I have found some docs about ARM architecture. So now I suspect that the crash can be a result of improper memory alignment. ARM seems to be very sensitive to this: http://www.arm.com/support/faqdev/1228.html

 

We need to find the offending piece of code (either in ufo2000 sources or in allegro) and fix it. Considering that you did not encounter the crash before getting to battlescape, that's probably our bug and we are doing something wrong.

 

You can try to make a simple test example which uses unaligned memory access to see how this problem shows up. Preferably we would like to have some exception and program termination (with core dump or something that can be analyzed) immediately on the instruction performing unaligned memory access. Much worse if we only get incorrect memory read/write operation result which only can show up later and can be a lot harder to debug.

Just tried this theory on the real device (see http://www.xcomufo.com/forums/index.php?showtopic=242024906). A small test program shows that unaligned memory access is not caught as an exception but just reads a different value from memory (memory address is aligned first, data is read and then seems to be rotated). So ARM CPU differs from x86 in this aspect. On the other hand, nokia 770 uses the same byte order as intel. These problems might be tricky to find, but I hope that we will manage this somehow :)

Link to comment
Share on other sites

  • 2 weeks later...

Finally downloaded everything needed for setting up development environment - scratchbox and maemo SDK (about 700MB with my internet connection speed was quite a long process) :)

 

So now is the progress update. Tried to compile revision 995, no problems detected. After the game refused to run in fullscreen mode, set it to windowed 720x420 (maximum windowed size from maemo tutorial) also tweaking minimal supported resolution defines in video.cpp. After a very long loading process (more than a minute), the game started and run flawlessly without a single crash. I did not expect such an optimistic result as standard allegro examples had much more issues, mostly because of 8bpp mode :)

 

The controls are quite awkward, but the game seems to be even playable, it uses 21MB of memory and runs at about 10-12 FPS.

 

A bad news is that software floating point emulation is not quite IEEE754 compatible, so currently we can't allow Nokia 770 players to connect the server and play games against ordinary PC users. Something should be done about this.

 

Well, I have just committed revision 996, which has a special hack for setting video mode to windowed 720x420 when it suspects that the game is run on Nokia 770. I will try to fugure out how to build .deb installation packages for Nokia 770 and will prepare some test version soon.

Link to comment
Share on other sites

If ufo2000 can run on Nokia 770, I just may have to buy it! :) =b

 

Does Ufo2k run smooth during the battlescape? Try testing with xcom base+ on the fourth level and start scrolling around to check for speed if you haven't already done so. :) The reason for xcom base+ is due to that it has the most objects as a starting map.

Edited by Kratos
Link to comment
Share on other sites

Does Ufo2k run smooth during the battlescape?

10-12FPS (on 'Moon Base' map), you can set animation and scroll speed in ufo2000 settings to 10 on your desktop PC to simulate this behaviour and see if it is smooth enough :)

 

But I also think that performance can still be improved significantly. First, looks there is a bug, that makes all tiles from 'Moon Base' tileset to be processed as tiles with alpha transparency (even on my desktop PC I get about 50 FPS instead usual 100). It probably relates to the fact that all sprites are loaded as subbitmaps of one bigger PNG picture. If my guess is right, after fixing this issue, performance will be much better. Also probably some low level CPU specific optimizations may be possible to improve bitmap blitting/clearing. And at last, dirty rectangles can be used to update only the area which was changed instead of a full frame (but this is not so easy, so it is the last resort if nothing else helps :)).

 

Try testing with xcom base+ on the fourth level and start scrolling around to check for speed if you haven't already done so. :) The reason for xcom base+ is due to that it has the most objects as a starting map.

Well, Nokia 770 (or any other PDA) will never run as fast as desktop PC, so it will be always possible to create a map which will perform extremely sluggish. So our first goal is to make the game run fine on at least some subset of maps, which should be enough for mobile gaming :)

Link to comment
Share on other sites

First, looks there is a bug, that makes all tiles from 'Moon Base' tileset to be processed as tiles with alpha transparency (even on my desktop PC I get about 50 FPS instead usual 100). It probably relates to the fact that all sprites are loaded as subbitmaps of one bigger PNG picture. If my guess is right, after fixing this issue, performance will be much better.

This bug is fixed in revision 998, there is no visible improvement in performance on Nokia 770 unfortunately. But memory footprint is down to 15MB and that's a good thing :)

 

Also switchng scale2x/normal mode do not seem to affect performance at all. Probably the bottleneck is in blitting backbuffer to video memory. If the video memory is too slow, we will not see any performance improvements until we implement partial screen updates (with full frame update in the backbuffer just for simplicity). I'll try to benchmark screen blitting in both Allegro and SDL to get some numbers.

 

About the other problems, I have noticed that soldier names have '?' as the first letter, maybe that's because of some alignment/endiannes bugs.

Link to comment
Share on other sites

  • 4 weeks later...

 

Bad thing, right after the game starts it aborts. Might be sound releated though. Otherwise it is too heavy, I had to kill half of the system to get it that far. And the starting time is rather long (25 seconds) to menu, then 20+ to mission planner, then 20+ to the game. It does look very cute and nice on the screen though :)

 

I think we can help out with it if you still need !

 

- looks like pixel-doubled gfx, some hires game gfx would be much nicer

 

Beware with screen refresh. refreshing large portion of screen takes too much cpu on the real 770. but if it's small and only half screen need to be drawn, I think it can be fast enough to reach 15 fps

 

- I expect problem with interaction (no right mouse button, no CTRL keys, and no keyboard at all as of now)

We use in our games the select button as a right mouse "toggle". It works.

The escape key ( firt hardware key should be mantained ) but, if the game is always fullscreen the escape key could be used as A control key.

 

For the keyboard, we already have some virtual keyboard for maemo, but it was made in pygame. I think one could be made pretty fast converting this code to C / allegro

 

 

Also, we have the maemo game startup screen ( deals with Dbus stuff, and icon on the tasknavigator, and the idle screen in GTK / SDL games ). it's open source and can be fully customizable with plugins on it. I'm going to place the files in my site again ( I've lost everything ) and send you the ok ( it will be on : www.marceloeduardo.com/me/ )

 

For multiplayer: our game startup also has the support for creating the wi-fi connections, searching for players, and initializing the connections between them, all integrated. So you only need after that to use your sockets to make it goes multiplayer. I don't know how the multiplayer support is implemented in XCOM but we can also help bringing this one to the table. It would be nice to have 3 or 4 players via wi-fi =)

 

For UI : if you guys want I can also design a simple GUI for it. We had the same problem when porting doom to 770, and I came up with a simple set of buttons and a target area for pen in the bottom that solved the problem.

 

Hope to hear from you soon,

 

Marcelo Oliveira

Link to comment
Share on other sites

 

Bad thing, right after the game starts it aborts. Might be sound releated though. Otherwise it is too heavy, I had to kill half of the system to get it that far. And the starting time is rather long (25 seconds) to menu, then 20+ to mission planner, then 20+ to the game. It does look very cute and nice on the screen though  :)

 

I think we can help out with it if you still need !

 

Thanks a lot for your help proposal!

 

About performance, I know about 2 bottlenecks:

- lua uses floating point (double) as a numeric type and lua is used for initialization of resources at start

- inefficient process of convertion of loaded PNG pictures to RLE sprites (see http://www.allegro.cc/forums/thread/571021)

 

As for lua, there are some patches which add integer support. The last time I checked them, they were for lua 5.1 alpha or beta. Now as lua 5.1 is finally released, it is probably worth to check status of this patch.

 

Beware with screen refresh. refreshing large portion of screen takes too much cpu on the real 770. but if it's small and only half screen need to be drawn, I think it can be fast enough to reach 15 fps

I already noticed that :) On a positive side, adding just '-march=armv5te' command line switch improves performance a lot, now it is about 13FPS and these is a lot room for improvement. That architecture specific optimization gives that much benefits as older ARM cores did not have 16-bit memory access instructions at all! And Nokia 770 uses 16bpp screen mode, so there are lots of 16-bit memory accesses inside of Allegro. In addition, C code in Allegro is portable, but not very fast. We mostly need 2 functions: clear_to_color() function for bitmaps clearing - to prepare double buffer for each frame and also bitmap blitting function. They both contain memory filling or memory copying code. It appears that 8-bit memory write is twice slower than 16-bit and that is also twice slower than 32-bit. On x86 CPU seems to have a better cache, so performance difference is minimal, but ARM seems to be different and needs carefull optimization.

 

I already started learning ARM assembler and have written optimized memset() implementation. Surprisingly it is twice faster than standard glibs memset() used on Nokia 770! I'm currently trying to make a fast version of memcpy(). If I manage to do this, blitting/clearing bitmaps will be a lot faster. I'm going to make a patch for Allegro that fixes all known bugs and performance issues on Nokia 770, see http://www.allegro.cc/forums/thread/571721

 

Probably even SDL can be also improved. At least standard SDL has some x86 inline asm code with MMX/SSE instructions to improve performance. I did not see any ARM inline asm there. Maybe Nokia 770 has some performance patches for SDL but I did not see the sources yet.

 

- I expect problem with interaction (no right mouse button, no CTRL keys, and no keyboard at all as of now)

We use in our games the select button as a right mouse "toggle". It works.

The escape key ( firt hardware key should be mantained ) but, if the game is always fullscreen the escape key could be used as A control key.

 

For the keyboard, we already have some virtual keyboard for maemo, but it was made in pygame. I think one could be made pretty fast converting this code to C / allegro

 

Also, we have the maemo game startup screen ( deals with Dbus stuff, and icon on the tasknavigator, and the idle screen in GTK / SDL games ). it's open source and can be fully customizable with plugins on it. I'm going to place the files in my site again ( I've lost everything ) and send you the ok ( it will be on : www.marceloeduardo.com/me/ )

 

For multiplayer: our game startup also has the support for creating the wi-fi connections, searching for players, and initializing the connections between them, all integrated. So you only need after that to use your sockets to make it goes multiplayer. I don't know how the multiplayer support is implemented in XCOM but we can also help bringing this one to the table. It would be nice to have 3 or 4 players via wi-fi =)

 

For UI : if you guys want I can also design a simple GUI for it. We had the same problem when porting doom to 770, and I came up with a simple set of buttons and a target area for pen in the bottom that solved the problem.

Well, user interface issues are also important. But as we have a lot of other things to do (not related to maemo port), I would not focus on them too much right now. Not everything is so bad, the game is even almost playable without changing anything at all. Surely it is impossible to access soldiers editing screen right now (adding a button could help to do this), but as long as the player is satisfied with default settings, he does not need it to play.

 

So I'm currently trying to fix bugs and improve performance. But a help with building deb-package would be welcome, I'm not familiar with debian, so it can take some time. Currently the game has make target 'binary-gz', it builds the binaries and provides a tarball with linux binary. This binary is tuned for local installation, that means it looks for data files relative to its executable. In order to build binary with everything installed somewhere else, 'make no_dumbogg=1 DATA_DIR=\"/usr/share/games/\"'' can be used for example. So preparing deb-package should just require making 'debian' directory and tweaking makefile. The problem is that I don't know where to start with that 'debian' directory, so a help would be very much appreciated :)

Link to comment
Share on other sites

  • 1 month later...

Some status update, probably the game will be packaged for Nokia 770 after the next software update (Internet Tablet OS 2006 Edition) becomes available. It should change something with floating point, and if floating point becomes IEEE754 compatible, everything will be much easier for us (right now it is impossible to connect the server because we would have synchronization problems because of different floating point format/precision). Also why bothering with current version of application installer if it is going to become a history soon? :)

 

The game can be compiled and run in hotseat mode, provides 18-20 FPS on 'Moon Base' map. If anybody is interested, I can provide detailed instructions how to compile it for Nokia 770.

Edited by Serge
Link to comment
Share on other sites

  • 2 months later...
Some status update, probably the game will be packaged for Nokia 770 after the next software update (Internet Tablet OS 2006 Edition) becomes available.

 

That was already released in Beta version, which is really close to the final one. The IT-2006 has integrated SWAP on MMC (you have to turn it on in Control Panel-> Memory->Virtual) so the chances to get this running are really good right now.

 

And yes, the application installer installs "almost" normal Debian packages (please note the EABI is not arm but armel, so ususal packages do not work), only small modifications are usually needed.

Link to comment
Share on other sites

That was already released in Beta version, which is really close to the final one.

Thanks for reminding, I'm aware of this news :) Unfortunately download size is quite big for my internet connection and so upgrading will take some time, so I decided to wait for a final OS 2006 version. By the way, is it possible to install sbrsh on a normal image using apt-get now without extra tricks? Also I read about problems with ext3 in the mailing list and my RS-MMC card uses it.

 

The IT-2006 has integrated SWAP on MMC (you have to turn it on in Control Panel-> Memory->Virtual) so the chances to get this running are really good right now.

That's good, though not critical anymore, the game uses about 15MB of memory now and works fine even without swap.

 

And yes, the application installer installs "almost" normal Debian packages (please note the EABI is not arm but armel, so ususal packages do not work), only small modifications are usually needed.

Well, I'm using gentoo as my desktop system, so I'm not very familiar with debian packaging. But we got some ubuntu users who provided some support for debian packaging: http://www.xcomufo.com/forums/index.php?showtopic=242025301

I wonder if it is possible just to tweak makefile in order to be able just to run 'make maemo-package' or 'make debian-package' and have the game packaged for any debian-derived distro?

 

Also it is a good idea to wait for allegro 4.2.1 (their SVN is in feature freeze state before release now), it has fullscreen issues fixed and also corrects some ARM-related problems. So allegro 4.2.1 will work on Nokia 770, though not very fast. In order to fix performance problems, I want to submit some patches to allegro, based on the following code. Without these patches it would be impossible to get high performance in the game (20 FPS as announced above). In order to improve performance even more, it is possible to code RLE sprites blitting entirely in ARM assembly (I would estimate about 20% improvement), but this is not a very high priority task.

 

With all that said, I must confess that the highest priority for us now is to prepare the next version of the game (for PC) and finally deprecate an old 0.6.627 release. Having many tasks done in parallel is not very efficient, especially considering that my spare time is usually very limited :(

Fortunately I got 2 weeks of vacation now (the first week is already almost gone though), so I'm very optimistic about finally solving some long standing issues and making a release :) So by the time of the final OS 2006 release, we should have something to package.

Link to comment
Share on other sites

  • 3 weeks later...

After improvements introduced in revisions 1051 and 1052, loading time is now reduced a lot. It still seems to heavily depend on floating point performance because of lua game initialization code. Compiling lua with 'int' basic numeric type instead of 'double' makes a bit difference, with 'int' numeric type, loading the game takes about 20 seconds. One more bottleneck is in map loading/selection code in the mission planner, so it can be optimized later (now it causes noticeable pauses when changing or generating maps, also it affects entering planner screen time).

 

Also I tested network game and after fixing some alignment related problems in revision 1055, I was able to successfully play a simple test network game on the server (with IEEE754 compatibility test disabled).

 

That's all for now :)

 

I can provide a tarball with IT-2005 compatible binary if anybody is interested to test it. I'm going to install IT-2006 and development environment for the next week and try compiling the game there. Anyway, looks like I would still need some help packaging the game, creating a repository or whatever needed to distribute the game to the end users.

Link to comment
Share on other sites

Just installed IT2006 and maemo SDK 2.0. Had some troubles with mounting ext3 partition and later with nfs (so cpu transparency does not work). Anyway, I can compile the game for IT2006 now :)

 

A good news is that floating point math is IEEE-754 compatible with this new image and there should not be any problems because of this. I compiled a binary from current SVN sources: http://ufo2000.xcomufo.com/files/ufo2000-0...56-armel.tar.gz

 

Those who would like to try this experimental build need to start xterm, unpack tarball, enter 'ufo2000-0.7.1056' directory and start the game: './ufo2000'.

 

Proper .deb package still needs to be done.

Edited by Serge
Link to comment
Share on other sites

  • 3 months later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...