Out Of Curiosity... How Much Work Is A Port?

[Gilrad]

...Relative to the size of the project, of course.

Is it the sort of thing that, if efficiency is not an issue on a small program (like with say, Gjiten, the jap-english dictionary app I use), somebody could jump in and port it over in a weekend? Or does it take more extensive knowledge of the program, or ARM architecture, or both?

What about, in a bit more of an out-there possibility, an indie gaming company wants to port something to Pandora... Would it be considered somewhat cost-effective, even if it meant only an extra 1000 copies sold?

 

[Tinnus]

If the game is well coded, the programming effort should be well worth it, the bigger problem might be the publishing costs like manuals, support, advertising (maybe not needed here?) and such more than the actual technical work involved.

 

[sindbad]

And if the source is available and if it doesn't use things only available on certain platforms (like directx). It depends a lot on the app, but for a well coded one it should be within 10% of the effort to make it in the first place.

 

[ldesnogu]

What about, in a bit more of an out-there possibility, an indie gaming company wants to port something to Pandora... Would it be considered somewhat cost-effective, even if it meant only an extra 1000 copies sold?

Probably not. Unless they are using a game engine that is multi-platform, unless their programmers know what data alignment means.
If that was cost effective don't you think you'd see much more Linux games?

 

[sol_hsa]

Short answer: depends.

Long answer:
Most software isn't written to be portable. Even SDL itself isn't very portable, even though it has been ported to numerous platforms. For software that is designed to be ported, the whole porting process is trivial, 1-2 week thing, regardless of the complexity of the software.

This is to get things compiled and running on the target hardware. The second part is whether the application functionality needs to be changed to suit the target hardware better. If the original program expects full keyboard and mouse at VGA resolution or higher, running it on a QVGA and ten buttons might require some changes..

On top of this you have possible third party libraries which might either be rather unportable or just not available, in which case you need to figure out how to replace their functionality. Audio is a common problem.

Sometimes you have some bits of code that just plain simply weren't designed to be ported at all, such as specialized assembler functions or dependency on certain OS functionality. Some games on windows actually use windows GUI components even if they don't look like it. These most likely need to be rewritten from scratch.

As to your less-than-1k-sold question, depends on how much it will cost to do the porting - if it's a hobby, it might be profitable =)

 

[ledow]

It depends on an awful lot:

Quality of the code
Distance to the "top spec" of the machine you're porting to (i.e. are you trying to run a PSX emulator or similar high-end app)
Libraries / languages used

If a particular program has been designed from the ground-up to be portable, and it happens to use a library that is just as portable (e.g. SDL), it's well-documented, doesn't need lots of "tricks" (i.e. trying to get the joystick recognised as a mouse, using in-line assembly to speed up certain operations etc.), has been ported to similar architectures before and had those problems solved, and there's a helpful programmer on the other end of it, you can port in a matter of hours, or maybe even minutes.

If a program isn't designed to be portable (or uses unported libraries), you *can* run into an awful lot of problems (alignment, endianness, machine-specific features and optimisations, etc.). If it isn't well-documented, you can find a lot of those problems become very difficult, if not so off-putting that you give up.

In the worst case, you could be writing the ENTIRE program again, from scratch, which is an enormous undertaking. In the best case, it can be just a matter of changing a line in a Makefile and recompiling.

I've only ported the Simon Tatham Puzzles over to the GP2X, but this is what I found:

The code was designed to be EXTREMELY portable (It's called the *Portable* Puzzle Collection) and modular.
The code was based on GTK for the nearest Linux ports but also had code for MacOS, Palm etc.
The code was well-written and had a lot of documentation except in one or two tiny cases.

I first "ported" this to use SDL (a cross-platform library) instead of GTK. This was very easy because of the way that it had been designed - everything was abstracted out to primitive functions, so basically all I had to do was get a routine to draw a circle, one to draw a square, one to copy an area of video memory etc. This took a mere matter of, in some cases, SECONDS for the functions to convert and HOURS for the whole thing overall.

Getting the thing to compile (and therefore giving the first "port" was trivial and, not including my own mistakes, probably takes MINUTES)

Then I had to rewrite a lot of "desktop code" to allow it to run on the GP2X in particular (which doesn't have a keyboard, doesn't have a mouse, etc.) - this meant writing an awful lot of new, machine-specific code that still doesn't work the way I want it after several DAYS of development time. This also meant a lot of "hackiness" in the code which I don't like. Additionally I had to tweak timers, graphical display etc. and create a whole new menu system to sit inside the games. This took DAYS of development time.

And even then, one game (out of the 27 ported) is still giving me problems due to a machine-dependent problem but due to the code for that game being mostly undocumented, I have little hope of fixing it very soon. I've spent HOURS on just that problem alone. And I'm nowhere near a complete port and I wrote about 4000 lines of code to back up the much-larger, already-written and well-tested code that the puzzles had originally. I didn't have to do any artwork, I didn't have to optimise any of the game code to make it run quick enough, I didn't have to write any of the interface code to the games, I didn't have to use a different compiler or architecture to compile it on, the libraries were already ported for me and the GP2X is Linux-based, so I didn't have to change anything Linux-specific in there (writing to files, threads etc.). And it's taken DAYS of development time (i.e. hundreds of HOURS) and I still haven't finished.

Now, if you were doing it on a random project that would stretch the machine and was never designed to be portable, you could run into MONTHS of development time just to port an already-written project.

At one end of the scale, you have things like Powder2x - an open-source, portable, ready-written game - that took someone a matter of minutes to port to the GP2X and be functional and a few hours to clean it up. And at the other, you have things like people's emulators that they so-desperately-need that could easily takes years to do.

 

[B_Lizzard]

It all depends on the program being ported, the availability of libraries and the toolchain. For instance, if we (or I ) set up an OE cross-compilation environment, porting most non-basic stuff (glibc etc, stuff that don't need any special patches or tweaking.) will be very, very easy. Wesnoth would just take an hour (since it doesn't need any patches to compile on weird embedded systems) to port, assuming that all the libraries (SDL, boost) are available beforehand.

 

[Parkydr]

In my case, anything from 2 days (GP2Xpdf and Powder2X) to a couple of months (GravityForce2X/Garden2X). Probably averaging a couple of hours a night).

The initial version of GP2Xpdf involved no code changes just configuration - thanks to the X server and Motif.

GravityForce2X/Garden needed controls adding and graphic rescaling including code changes for hard coded screen positions.

Powder2X just needed GP2X controls adding, the scaling was already there.

Other things that often need to be added are volume control and controls to allow text entry in high scores etc.

Gjiten is more of a problem as it uses GTK. I have managed to compile GTK stuff using a QEMU arm environment but a better way is to do what ledow did with STPC and convert the GTK interface to SDL.

 

[Svartalf]

...Relative to the size of the project, of course.

Is it the sort of thing that, if efficiency is not an issue on a small program (like with say, Gjiten, the jap-english dictionary app I use), somebody could jump in and port it over in a weekend? Or does it take more extensive knowledge of the program, or ARM architecture, or both?

There might be gotchas along the way, but if it's C/C++ code running on Linux in the first place,
I can't say there'd be too many problems with doing that. You've just got to pay attention to things
like endianness, etc.

QUOTE

What about, in a bit more of an out-there possibility, an indie gaming company wants to port something to Pandora... Would it be considered somewhat cost-effective, even if it meant only an extra 1000 copies sold?



This is a bit steeper play depending on the circumstances they're in.

If they've coded for cross-platform (i.e. MacOS/PS3/Linux) then it's only a matter of a recompile and a rework for an OpenGL ES 2.0 rendering backend plus making sure that you have your sound and input layers properly supported under SDL/OpenAL at that point. The re-work may be a small amount of work (you used programmable shaders...) or a bit of work (Fixed functionality rendering...). All in all, it's probably not an unrealistic thing to see them at least considering a Pandora version if they've got a Linux one in hand or in the works.

If they've coded for Windows and only Windows, there's a bunch of different factors that may make it a pet-project prospect only for an indie studio. If they don't use OpenGL at all, they'll have to re-work the
rendering backend to use OpenGL ES 2.0 at the minimum. If they used DirectInput/DirectSound, they'll have to re-work things to use SDL. If they used DirectPlay, they will have to rip that out and use RakNet
or Grapple- or roll their own if they don't like either of those. If the codebase is relatively clean and they didn't get lazy and rely on VC++ letting you do all kinds of atrocious coding practices (VC++ will let you
do nasty things like modify a constant string's allocation with only a warning- the result of this sort of stunt in Linux/MacOS/etc. will be a core dump because you're altering a segment that doesn't belong to you
(Constants are supposed to be that, duh...)), then the work is something on the order of 2-6 man months to get the codebase over. IF it's clean. If it's not...heh...it'll be at least another 4-6 man months on top
of the time that it'd normally take as you end up chasing your tail on all sorts of goofy crap that VC++ just "worked" with- but was the source of all kinds of transients.

If you're facing that, a paltry 1k unit deal isn't going to cut it unless you're doing it as a pet project. You need at least 5k units to make it worth your trouble.

 

[Sphinxter]

Sometimes it's a lot easier to make a use case out of it, chuck the rest and start fresh. Some things are better left behind.

 

[Svartalf]

Sometimes it's a lot easier to make a use case out of it, chuck the rest and start fresh. Some things are better left behind.

No kidding... It's all on what you're looking for.

If it's clean and portable (and there ARE indie titles that have been that...) then it's a no-brainer to do the port, especially if you were contemplating a Linux version or have one on the plan or in progress. If it's not so clean, unless you're doing the Linux/MacOS version (Perversely, doing one nearly provides the other...I wonder why... ) already, it may be time to do a Sphinxter suggests. Use it as a springboard for new ideas and start over.

 

[Gilrad]

What about games that were released for multiple platforms? Would they, by definition, be easily portable, or is this a whole different can of worms to port from a commercial console/handheld to Pandora, regardless of whether it's been ported or not?

 

[PoisonedV]

What about games that were released for multiple platforms? Would they, by definition, be easily portable, or is this a whole different can of worms to port from a commercial console/handheld to Pandora, regardless of whether it's been ported or not?

It still depends entirely on the program. A Linux program may seem more like to work on the Pandora, for example, but if its coded very specifically to work on that specific computer/distribution or whatever, it could still be very hard. There is no way to give a definite answer.