Experiences building from source

[robinwatts]

Hi all,

I've just got a Windows Mobile 5 device (an MDA Vario II) and tried Scummvm on it - it works much better than I'd dared hope, and I'm busily converting all the games I've owned for years into forms that work with it.

When I tried 'Curse of Monkey Island' I noted that it wouldn't rotate the screen in quite the way I'd like it to - I guess this is because of a missing scaler in the source.

Also, I note that in some of the docs I read it says that sometimes audio and video can get slightly out of sync, due to needing a slightly faster blitter.

I mention this not to complain in any way, but because these sound like exactly the kind of things I could help with - I program graphics etc on ARM devices for a living, so I could probably knock up an optimised assembly routine for the odd speed critical bit if that'd help.

So, I thought I'd have a crack at building everything from sources. Wow - a much longer slog than I'd expected to get up and running - I generally use eVc etc to develop with, so building my own gcc has been 'interesting'.

I thought I'd post my experiences here in the hopes that they are useful to others.

First off, I should say that I'm building on a windows machine using cygwin. The instructions on the Wiki were great (I'd never have got anything built without them!) but it might be worth noting that:

* The packages needed for Cygwin are the ones listed, *plus* patch, cvs, gettext, gettext-devel and perl. Oh, and maybe svn, though that may be standard.

* If you make sure that you do the cvs checkout from within cygwin, you'll use cygwins version of cvs rather than any other - hence you'll have no CRLF problems. That cost me an hour or so :)

* Patching doesn't *quite* work within cygwin, because it fails to pick up the names of the files to patch. Fortunately when it fails, it prompts you, and you can supply the name interactively, so it's not too much of a problem.

* "make install" on gcc failed for me, until I nobbled the install-fixinclude step. No idea about that.

That was enough to get the tools built, but then I hit another couple of snags actually building scummvm.

* I had a problem with the current source, where I needed to add a #include "common/events.h" to wince-sdl.cpp

* When it reached the link stage, it failed telling me that the symbol _assert wasn't found (I'm assuming this is a debug build, and so shouldn't have found it anyway?) I patched around this by adding extern "C" { void assert(int x) {} } to one of the files.

And now I have something that appears to build and run OK (albeit with green/black graphics menus rather than the coloured ones I had before).

I hope these comments are useful to someone - or maybe someone can point me to what I did wrong.

Thanks,

Robin

[fingolfin]

I never used cygwin myself (being an Mac OS X user), but regarding "Patching doesn't *quite* work within cygwin" -- did you try using the -pN option of the "patch" tool ? E.g. -p0, -p1, -p2, ... -- it will strip off the first N components of the paths in the patch you are trying to apply. Often that makes the difference between "patch" detecting the filenames properly, or not.

Maybe the problem lies elsewhere, but I thought it wouldn't hurt to mention this, just in case it applies here, too.

[fingolfin]

Oh and I fixed the common/events.h problem in SVN.

[robinwatts]

The patch suff: I don't think -pN would have helped. It would tell me that it couldn't find file "foo/bar.c" and I'd then enter "foo/bar.c" and hit RETURN and it'd patch that bit OK. Very strange.

I had a play last night, and I've ARM coded a version of PocketPCHalf (the scaler that is used for Curse of Monkey Island when played on a 320x240 screen). Having a look at the SDL blitting stuff today...

Thanks,

Robin

[knakos]

Hi Robin,

When I tried 'Curse of Monkey Island' I noted that it wouldn't rotate the screen in quite the way I'd like it to - I guess this is because of a missing scaler in the source.

I see that your device has a 240x320 screen. You should be able to rotate to portrait, landscape and inverse landscape. This leaves only one orientation, inverse portrait. Is this what you mean?
It might be the case though that your device is a 320x240 "landscape" display. Then, I'm not sure how you can rotate with existing versions. Please clarify this.
Also, the orientation is handled by SDL, not by a scaler. More on this later.

I generally use eVc etc to develop with, so building my own gcc has been 'interesting'.

We dropped support for evc for a gazillion reasons - I'm sure you'll find some of them in my previous posts. I strongly recommend you develop with free tools too

I thought I'd post my [building] experiences here in the hopes that they are useful to others.

Thanks for this, will include some more detailed stuff in the wiki.

If you make sure that you do the cvs checkout from within cygwin, you'll use cygwins version of cvs rather than any other - hence you'll have no CRLF problems.

Ideally all work should be done inside cygwin to avoid such stuff (who needs gui anyway ).

Patching doesn't *quite* work within cygwin

As Fingolfin said, patch -p0 at the right place will patch everything allright. Some files may patch with a little fuzz though, as stated in the wiki.

"make install" on gcc failed for me

No idea about this one. I've rebuilt the toolchain in cygwin & linux 32 and there were no problems.

I had a problem with the current source, where I needed to add a #include "common/events.h" to wince-sdl.cpp

At the moment, the trunk is a little out of date (especially with the recent changes for events. I'm working off a frozen copy right now towards greatly improving the SDL lib. In my checklist I've reached point #4 from a total 6, so when I'm done I'll release an svn build and update the sdl patches.

When it reached the link stage, it failed telling me that the symbol _assert wasn't found

This happens because your include order is wrong in the Makefile. You should put the toolchain include path after all other includes path. I'll fix this in the trunk soon and/or mention it in the wiki as well.

]And now I have something that appears to build and run OK (albeit with green/black graphics menus rather than the coloured ones I had before).

You have to upload the newer modern.[zip][ini] files to your device.

I had a play last night, and I've ARM coded a version of PocketPCHalf (the scaler that is used for Curse of Monkey Island when played on a 320x240 screen). Having a look at the SDL blitting stuff today...

If you finalize this, please post it on the project's patchtracker for discussion. Let me state that while I generally would not accept device-specific stuff (e.g. ARM over SH3 or MIPS), this will be only enabled for ARM devices, and the fallback C-code one will always be there to fall back on. Also note that from extensive dissasembly, gcc proves to be extremely efficient when compiling "close to assembly" code like the scaler stuff. What is slow in existing build is the back end blitting by SDL, which I've recently optimized to, dare I say, lightning fast levels . Stand by for those changes as soon as I finish my SDL backend updates.

Thanks,
Kostas

[robinwatts]

Hi,

I don't develop using eVc by choice - it's what tends to be forced on me when developing for WinCE devices. I've used all manner of tools (including free and commercial ones, both good, bad and truly dreadful), but ultimately as long as I have a C compiler and an assembler that accepts standard (or in gas's case vaguely standard) ARM code, I'll cope.

It's not my place to try and convince people to change tools (and neither would I want to). You've clearly picked these tools for this project for good reasons. My comments weren't intended to be complaints!

The device has a 240x320 screen, as you say. For most games I can either run them in portrait mode, or landscape, or inverted landscape. Inverted landscape is the one that works best for me - with the D pad on the right hand side.

The Curse of Monkey Island only runs in standard landscape mode - no rotation options are offered. I assumed that this was because it was a 640x480 screen that gets scaled down?

As regards my ARM code PocketPCHalf scaler, it is compiled in conditionally on whether 'ARM' is defined - so SH3 and MIPS builds will still be fine. Certainly it would never be my intention to break them.

Todays explorations have been in the SDL library, where I have an ARM code version of Blit1to2 (protected in the same way by #ifdef ARM).

Tomorrow I was planning to spend some time ARM coding the GAPI_UpdateRects function.

I'll make all of these changes available to you in any way you'd like - I'll investigate the patchtracker tomorrow. I appreciate now that they may not fit with your revised SDL library - if that's the case then so be it. I can always wait until the new version becomes available and play again.

You say that gcc does an "extremely efficient" job of compiling close to assembly code - and indeed there are times where it does a creditable job. Thankfully however there is often still scope for significant hand optimisations. I've been coding for ARMs for almost 20 years now, so hopefully I should be able to spot cases where this is true. :-)

You've all done a brilliant job in making it work as fabulously as it does. If I can help out in improving it even a little, then I'd be glad to.

Thanks,

Robin

[knakos]

It's not my place to try and convince people to change tools (and neither would I want to). You've clearly picked these tools for this project for good reasons. My comments weren't intended to be complaints!

I assure you they were not taken as such. ScummVM eagerly welcomes any contribution you make to the project. In fact we encourage it! The best way to show your appreciation is to give back to the community some good code. Please feel free to submit patches.

The Curse of Monkey Island...

Now, this has happened to me several times already. I completely missed you were talking about COMI. I assumed you were talking about a standard 320x200 game (COMI is a bit of a corner case).

...only runs in standard landscape mode - no rotation options are offered. I assumed that this was because it was a 640x480 screen that gets scaled down?

You can't invert landscape in COMI because of last-minute safety precautions during the 0.9.1 release. In fact, you should be able to incude support for inverted landscape with no problem by doing the following changes in wince-sdl.cpp (line numbers may vary a bit, as I'm working on a modified, uncommitted copy):
Around line 854, in update_game_settings(), kill this if altogether:

Code: Select all

if &#40;_screenWidth <= 320 && &#40;isOzone&#40;&#41; || !CEDevice&#58;&#58;hasDesktopResolution&#40;&#41;&#41;&#41; &#123;

Around line 2205, in the SDL_MOUSEBUTTONDOWN handler kill the "&& _mode ==GFX_NORMAL" part of this if:

Code: Select all

if (_newOrientation != _orientationLandscape) && _mode == GFX_NORMAL) {

I've done this recently and works fine for me (hope I didn't forget anything else).

I have an ARM code version of Blit1to2

Excellent, I have not touched that part of the code.

Tomorrow I was planning to spend some time ARM coding the GAPI_UpdateRects function.

On the other hand this function has been gutted to death Incidentally, my sdl patches are not made public at this time as they're being worked on heavily and it would be a shame to hinder user's builds by half-assed code. SDL and the ce port of scummvm will be updated in one go.

You say that gcc does an "extremely efficient" job of compiling close to assembly code - and indeed there are times where it does a creditable job. Thankfully however there is often still scope for significant hand optimisations. I've been coding for ARMs for almost 20 years now, so hopefully I should be able to spot cases where this is true.

GCC gave scummvm an incredible increase in execution speed, making the VS2005 arm compiler seem crippled. Hand optimizations for computationally intensive parts are the zen of programming Feel free to submit your patches.

Best,
Kostas

[robinwatts]

I've uploaded the PocketPCHalf patch to PatchTracker as Request 1696852

[robinwatts]

I've uploaded the Blit1to2 patch to the patch tracker as request 1696866.

I hope I've done this right, as I'm new to this. Any problems, please just say.

I'll hold off on playing any more with the SDL stuff until you've got your changes in - no point in ARM coding stuff that's going to be removed in the next version!

Thanks,

Robin

[Herrscher]

* If you make sure that you do the cvs checkout from within cygwin, you'll use cygwins version of cvs rather than any other - hence you'll have no CRLF problems. That cost me an hour or so

IIRC you can choose at installation of Cygwin whether to use UNIX or DOS linebreaks. If you choose the last one, Cygwin DOS->UNIX-converts them while reading into Cygwin programs and the other way round when saving. This could also save you an hour.