Page 1 of 1

Porting R'N'D to handheld/PDA devices

Posted: Fri Sep 08, 2006 3:08 am
by pfalcon
Greetings!

I am interested in porting R'N'D to [primarily Linux-based] handheld/PDA devices. Actually, I also made a rough recipe for OpenEmbedded, and tested it under QEMU ARM emulator. It worked and runs, I'd even say well, except it's of course barely playable.

There're following issues with running R'N'D on devices in question:

1. Unfortunate default screen size R'N'D uses. It just *slightly* larger than standard 640x480, common best available for handheld devices. Why??? ;-) Was there some magic in having 17x17 tilesize?

2. Actually, previous note is just lazy grievance that it might work for just some of devices OOB. That's wouldn't help handheld port in general, as there're various screensizes, commonly lower than VGA. So, we're talking about dynamic sizing of game screen/window, and possibly dynamic resizing of sprites.

3. Keeping game data in uncompressed form doesn't scale well for handheld devices.

4. Why PCX is used for graphics? ;-)


So, I'd appreciate if the author described the attitude towards these problems - any chance some of the issues above being handled soon? If not, would be patches accepted? Any suggestions regarding window/tile sizing? Would just replacing constants with vars work in first approximation (leaving aside that hardcoded frame graphics, it would need to be dynamically drawn eventually too, of course)?


I also know that some of the problems above are being/were tackled, but it seems a bit slow/not very ordered, so to say. For example, screen/tile size matter must have been addressed at least partially with RoNDi, but it has that common story - binary only releases (which is violation of GPL by the way), then author's gone, source lost. And just diffing HerzAusGold's source against mainline shows that it will take some more time until that could be accepted into it.


Thanks,
Paul

Posted: Fri Sep 08, 2006 3:09 am
by pfalcon
Almost forgot - where's R'N'D's SCM? Couldn't find reference to it on project's pages.

Posted: Fri Sep 08, 2006 4:19 pm
by HerzAusGold
Hi DiPal, can you release the source for your port/ports?

btw: SCM - source code manual?? or what?
If it is so, look to the source.

Posted: Fri Sep 08, 2006 4:23 pm
by pfalcon
Source Configuration Management, a buzzword to name CVS/Subversion/etc version control systems, sorry for confusion.

Posted: Fri Sep 08, 2006 5:20 pm
by Tomi
AFAIK, RnD doesn't use any SCM (or VCS), although I'd like it very much if it would (e.g. for downloadable nightly project snapshots) and it would make many things (managing ChangeLog?) simpler IMO.

Posted: Fri Sep 08, 2006 8:19 pm
by Holger
> I am interested in porting R'N'D to [primarily Linux-based] handheld/PDA
> devices.

That would be cool! :-)

> It worked and runs,

Wow! :)

> 1. Unfortunate default screen size R'N'D uses. It just *slightly* larger
> than standard 640x480, common best available for handheld devices.

Oh well, you're right... :-o

> Why??? Was there some magic in having 17x17 tilesize?

Not at all! I just thought it would look nice to have a square screen! :-o ;-)

The game was initially developed on a Unix system (eleven years ago), using various screen sizes on X11 terminals. As the screen resolutions were always different (but always high enough), and the game was initially always running in windowed mode, I did not use any "classic" screen mode or screen size (as I would do now, which is funny). I just thought "17x17 would look nice" and used that. Today, I would use something that would result in a 4:3 screen aspect ratio, like 640x480 or 800x600... :-o

> So, we're talking about dynamic sizing of game screen/window, and
> possibly dynamic resizing of sprites.

That would indeed be a major feature and big advantage for R'n'D (when thinking about porting it to new systems)...

> 3. Keeping game data in uncompressed form doesn't scale well for
> handheld devices.

Well, this should be very easy to solve -- when using some wrapper code, this could probably be solvable in an easy and transparent way.

> 4. Why PCX is used for graphics?

In the very first place? Because it was easy to write a loader for it! ;-)

First, R'n'D used graphics in XPM format, using the the XPM library for loading the image files. (If you think PCX is some sort of "uncompressed", look at XPM files. ;-) )

To get rid of the XPM library dependency (for the DOS port), I switched to the GIF format. For this, I had to write my own GIF loader, as there was no widespread GIF loading library around at that time, and I didn't want to add another library dependency. Unfortunately, I found that there were many strange things that I would have to support (like interlaced GIFs), and then came those nasty problems with the GIF patent, so I throw it all away and switched over to PCX which is a very simple image format, and the PCX loader was easy to write... ;-)

Nowadays, one would probably use PNG for it...

> So, I'd appreciate if the author described the attitude towards these
> problems - any chance some of the issues above being handled soon?

Well, this is indeed on my TODO list, but I better don't promise anything any time soon -- it didn't work very good in the past... :-/

> If not, would be patches accepted?

In general, yes, although I still cannot promise when to incorporate them into the main game version then (especially if they add new library dependencies, but this would probably be only the case for that certain platform(s) in this case, handled by the build system etc.)

> Any suggestions regarding window/tile sizing?

This is a question I though about many times in the past. I really would like to see a resizable window size for R'n'D. The main problem is the existence of level sets with custom artwork, like BD2K3 or Snake Bite, which rely on the current screen dimensions. But this problem may be solvable...

> Would just replacing constants with vars work in first approximation
> (leaving aside that hardcoded frame graphics, it would need to be
> dynamically drawn eventually too, of course)?

It may work -- I've never tried it. (I'm sure there are some values here and there that use hardcoded values although they shouldn't...)

> For example, screen/tile size matter must have been addressed at least
> partially with RoNDi, but it has that common story - binary only releases
> (which is violation of GPL by the way), then author's gone, source lost.

Yes, although I'm not sure if it is really a violation of the GPL -- I've asked for the source code once, and received it from the author (DiPal), so I think this is in conformance with the GPL. (That version of the source code might not be from the latest version of the binaries that are offered for download, but at least the code isn't completely lost forever. ;-) )

BTW: For the incorporation of the next native game engines (SP and BD), it might be desirable to make it possible to also use "native" screen sizes (like 640x400 or 640x480), so this is something that might come sooner than expected.

In any case, I will be happy to help you with a version of R'n'D for new platforms (like that you are targeting), and see if the changes can be incorporated into the main version to make it easier to maintain the handheld/portable version of the game.

About SCM/VCS/CVS: Sorry, there's currently no (public or private) CVS repository available for R'n'D... Probably this is something that would make sense somewhere in the (near?) future...

Posted: Sat Sep 09, 2006 2:13 pm
by pfalcon
Holger, thanks for your response. I'm glad to hear that you think favory about the things I wrote about. I so mostly as build engineer, who'd like to get package work nicely with a distribution, but I'll enqueue hacking on it developer,as it is clearly worth it ;-).

Couple of topics I'd still like to discuss:

1. GPL
I clearly don't want to start my appearencen this forum with another licensing flame, yet directly with the auhor. Buit GPL is tricky thing, and I guess it's nice to raise that question, especially that I didn't see much that discussed.

So, GPL is not just about submitting modified source to the author. It's actually about giving many of author's rights to users. And the first right is to having the source for whatever binaries they get, by the same means as binaries. So yes, that means that binaries and sources must go together. Note that GPL protects author too - whatever changes made and for what is being done with them as long as it goes to thirdparty, the changes in source form must be passed to the author too.

Of course, you, as the author, and copyright holder, may make arbitrary exceptions to this. So, you might have let DiPal not release source. If this is teh case, I'd like to know. Or you may let DiPal market his ports as shareware in eturn to royalty (did you thought about that? could easily pay for the server, I guess ;-) ). But if the above not teh case, and you don't have interest in options like mentioned, I'd like to ask you to release DiPal's sources which you were passed, to fix his non-compliance.

Thanks for considering this.

2. SCM/VCS

I second Tomi's thought that public version control would be very beneficial for R'N'D. It would both alleviate your work as maintainer (i.e. peron who must deal with contributions/bugreports/etc, not just write code ;-) ) and will intrinsically guide contributors to productive process.

I seriously suggest comtemporary Subversion over stone-aged CVS. Subversion is also very mature and work perfect on Both Unix and Windows systems, has wonderful documentation in form of constantly updating book, but also support much better tree management (renames and moves), command set is largely CVS compatible, but more clean and has better usability.

It's also very easy to start with it - just like CVS, it supports local repositories, so it's as easy as installing package and starting import of the previous versions ;-).

It's also not much pressing with going public - there're quite few SVN hosting providers available, with sourceforge.net and berlios.de to name a few. There should be little concern of giving away a repo in third hands - both sf.net & berlios.de offer downloadle backups (berlios.de as daily tarball last time I checked, sf.net recently switched to more practical rsync). Both should offer initial import of local repository (sf.net by automatic means).

So, if you could really find some time to look at Subversion, might be pretty easy to set it all up. The whole R'N'D contribution community would be grateful for this (including new potential contributors for whom this streamlined procedure would allow to try).

Again, thanks for considering this!

With best regards,
Paul

Posted: Sun Sep 10, 2006 4:24 pm
by Daniel H.
I use Subversion too. I think that it would be great for Rocks 'n' Diamonds! :D