Jump to content
XCOMUFO & Xenocide

Getting started with a new port


Hitman/Code HQ

Recommended Posts

Hi there.

 

Allow me to introduce myself. I'm Colin Ward AKA Hitman/Code HQ and I ported Allegro to the Amiga. So now a friend and I are porting Allegro games to the Amiga using my Allegro port. Sometimes they just compile but sometimes it's a bit more difficult!

 

Unfortunately UFO2000 seems to fit into the "bit more difficult category."

 

I have a binary that I can run and it starts loading the data files but crashes due to not finding those data files. In src/gui.cpp in SkinInterface::get_bitmap() it tries to load "Background" but fails and later on when the game tries to blit this background, the bitmap is NULL so it's game over.

 

Now usually I can figure out this kind of problem when porting Allegro games (it's usually caused by endian issues or by people putting MS-DOS style \ instead of UNIX style / in paths, so its easily fixed. But of course Allegro is using Lua, and I have no idea of what the get_bitmap() function is doing or where this supposed "Background" bitmap is supposed to come from. There are no files with this name to be found.

 

I wonder if someone could point me towards some documentation or give me a quick rundown of how Lua is used and how it extracts bitmaps in functions like get_bitmap()? Knowing the background concepts certainly helps with the details!

 

I'm hoping to demo the Amiga version of the game at a small computer show in London on the 12th of December so any pointers on getting it up and running would be great!

Link to comment
Share on other sites

Replying to myself, it seems that there is a mismatch between the datafiles required and those in the tarball I downloaded. I get the following when I run the binary:

 

Temp:ufo2000-0.7.1062/init-scripts/main.lua:66: CheckDataFiles: crc32 error for file 'Temp:ufo2000-0.7.1062/ufo2000.dat' (0x29641bee / 0x85f35853)

 

This problem may be caused by incorrect installation of the game (you probably forgot to copy original X-COM data files to the place where the game can locate them).

 

Please make sure that you followed the instructions from 'INSTALL' file before reporting bugs.

stack traceback:

[C]: in function `error'

Temp:ufo2000-0.7.1062/init-scripts/main.lua:66: in function `Error'

Temp:ufo2000-0.7.1062/init-scripts/filecheck.lua:202: in function `CheckDataFiles'

Temp:ufo2000-0.7.1062/init-scripts/filecheck.lua:218: in main chunk

[C]: in function `dofile'

Temp:ufo2000-0.7.1062/init-scripts/main.lua:760: in main chunk

 

Is svn up to date?

Link to comment
Share on other sites

SVN is more or less up to date. UFO2000 can run fine with the free graphics only (and I would recommend trying this setup first). But if you really want to run the game with the original X-COM graphics, UFO2000 tries to be strict and verify some checksums to be sure that the data files are compatible/tested.

 

Is your target hardware fast? One of the problems is that relatively recent updates (by commit number, not by date :) ) made the game much more CPU and memory hungry than it used to be. This definitely can be improved, but we are not there yet.

 

Additionally, seems like stability is not quite top notch and there are really lots of errors reported by valgrind with latest SVN. I'm going to clean up this mess over the next few weekends.

 

If you have some other allegro based games in the queue, it makes sense to look at them first and come back to UFO2000 later. In any case, if you encounter obvious showstopper bugs, reporting them is very much velcome.

Link to comment
Share on other sites

Hi Serge.

 

SVN is more or less up to date. UFO2000 can run fine with the free graphics only (and I would recommend trying this setup first). But if you really want to run the game with the original X-COM graphics, UFO2000 tries to be strict and verify some checksums to be sure that the data files are compatible/tested.

 

Thanks for your feedback! I scrapped my work and started again, getting a fresh copy of the svn version of the source, just in case the tarball I had downloaded was out of date. It actually compiles quite easily (great! This is often not the case with Allegro games!) but again, it crashes on startup.

 

This is due to some missing bitmaps that aren't present in svn. When I copy the data files from a tarball that I downloaded then my build from svn does start successfully, but then I get the errors about the CRC being wrong. So it would seem that the data in svn is out of date? The data in the tarball I downloaded also has this problem.

 

Can you recommend a tarball that is the stable version of UFO that I can try? The tarball I downloaded certainly doesn't seem to be stable (like svn it has missing files and gets crashes and/or CRC errors).

 

Is your target hardware fast? One of the problems is that relatively recent updates (by commit number, not by date :) ) made the game much more CPU and memory hungry than it used to be. This definitely can be improved, but we are not there yet.

 

It's 800 mhz. Not blazingly fast but for a strategy game like UFO I would hope it would be enough.

 

If you have some other allegro based games in the queue, it makes sense to look at them first and come back to UFO2000 later. In any case, if you encounter obvious showstopper bugs, reporting them is very much velcome.

 

To be honest there aren't many decent games on Allegro! The best ones seem to be closed source, so I've been searching for some "decent" games that make the 12 months of work I put into porting Allegro worth it! I'm hoping that UFO2000 will be one of those, if we can get the data file problem sorted out. :-)

 

Colin.

Link to comment
Share on other sites

Thanks for your feedback! I scrapped my work and started again, getting a fresh copy of the svn version of the source, just in case the tarball I had downloaded was out of date. It actually compiles quite easily (great! This is often not the case with Allegro games!) but again, it crashes on startup.

Can you run a debugging build compiled with 'make debug=1' in gdb and show a backtrace? Disabling fullscreen mode (set F_FULLSCREEN to 0 in ufo2000.ini) makes debugging easier.

 

This is due to some missing bitmaps that aren't present in svn. When I copy the data files from a tarball that I downloaded then my build from svn does start successfully, but then I get the errors about the CRC being wrong. So it would seem that the data in svn is out of date? The data in the tarball I downloaded also has this problem.

This should not be a problem. If anything is missing in SVN, then it is not strictly required :) I'm running a build compiled from SVN quite fine without any extra stuff or data files.

 

Can you recommend a tarball that is the stable version of UFO that I can try? The tarball I downloaded certainly doesn't seem to be stable (like svn it has missing files and gets crashes and/or CRC errors).

Not sure about this.You could try a tarball for 0.9.1105 version, but it had a bug which might affect you and which is (supposed to be) fixed in SVN. I think SVN is the best choice at the moment.

 

It's 800 mhz. Not blazingly fast but for a strategy game like UFO I would hope it would be enough.

OK, it should be fine, though not blazingly fast with 16 levels of map and lightling processing. I was thinking more about legacy pentium2 class desktops and ~200MHz ARM powered handhelds :)

Link to comment
Share on other sites

Thanks for your feedback! I scrapped my work and started again, getting a fresh copy of the svn version of the source, just in case the tarball I had downloaded was out of date. It actually compiles quite easily (great! This is often not the case with Allegro games!) but again, it crashes on startup.

Can you run a debugging build compiled with 'make debug=1' in gdb and show a backtrace? Disabling fullscreen mode (set F_FULLSCREEN to 0 in ufo2000.ini) makes debugging easier.

 

Ok, here is a stack trace.

 

_Z17draw_alpha_spriteP6BITMAPP10RLE_SPRITEiij()+0x88 (section 8 @ 0xc74b0)

_ZN13SkinInterface10backgroundEv()+0x58 (section 8 @ 0x24efc)

_Z8initmainiPPc()+0x1B4C (section 8 @ 0x4bd20)

main()+0x144 (section 8 @ 0x4f37c)

 

Demangling the C++ names, the top functions become:

 

draw_alpha_sprite() line 534

SkinInterface::background() line 88

 

SkinInterface::background() calls draw_alpha_sprite() passing in m_background, which is NULL because in SkinInterface::SkinInterface() it calls:

 

m_background = get_bitmap("Background");

 

But get_bitmap() fails and returns NULL, hence the crash. But finding out why get_bitmap() fails when I am unfamiliar with LUA and how UFO uses it, is diffuclt!

 

I used a file monitoring program to see if some data files were not being opened, but apart from the commercial UFO datafiles not being found, it didn't look like anything was being missed. Yet when I copied data files across from another tarball that I downloaded, the crash didn't happen and the game proceeded to start, but then got a CRC error loading ufo2000.dat!

 

So it is quite confusing and seems as though some files are missing in svn?

 

If I can solve this little problem then we will have UFO running on my Amiga!

Link to comment
Share on other sites

It may make sense to set a breakpoint at 'png_image' function because it is called back from lua to do actual image loading. It is also interesting to know the value of 'screen_name' argument for the failing SkinInterface::SkinInterface call.

 

If you can come to #ufo2000 IRC channel at freenode.net, we could try to debug this issue in 'realtime'.

Link to comment
Share on other sites

OK, most likely it is getting called from 'initmain' function with 'Game_init' argument. This stuff is in 'init-scripts/standard-gui.lua' and it should load background via png_image("$(ufo2000)/arts/loading_screen.png") which is directly binded to C function png_image. Checking how this relative path gets resolved and whether the file gets actually loaded should provide some insights.
Link to comment
Share on other sites

It may make sense to set a breakpoint at 'png_image' function because it is called back from lua to do actual image loading. It is also interesting to know the value of 'screen_name' argument for the failing SkinInterface::SkinInterface call.

 

Great suggestion - I got it working through this! It was my own fault actually. Quite often when I port Allegro games, the makefiles are a bit of a mess, so it's easier to just use my own template makefile and add the names of the .c files to it so that's what I did here. But I should have a had a look at the official makefile because then I would have seen that -DUSE_PNG was required! So it wasn't able to load the .png datafiles, hence the crash.

 

So apart from my own silliness, it was quite easy to port. Contratulations, your UFO remake just ran on the Amiga for the first time. :-)

 

Thanks for the help!

Link to comment
Share on other sites

Great suggestion - I got it working through this! It was my own fault actually. Quite often when I port Allegro games, the makefiles are a bit of a mess, so it's easier to just use my own template makefile and add the names of the .c files to it so that's what I did here. But I should have a had a look at the official makefile because then I would have seen that -DUSE_PNG was required! So it wasn't able to load the .png datafiles, hence the crash.

I'm glad that ufo2000 works in your system now.

 

But you noticed an interesting thing (more like got hit by it). Actually looks like libpng is not an optional dependency anymore, hence this USE_PNG define needs to be eliminated. Same for freetype. Another thing is that the game should not crash even if it could not load the image, lua files are supposed to be used for extending the game. Providing a sensible error message instead of crashing to the one who is trying to customize the game would be definitely better.

 

So apart from my own silliness, it was quite easy to port. Contratulations, your UFO remake just ran on the Amiga for the first time. :-)

Nice. I wonder if we are going to see new Amiga players on the game server :)

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...