Porting questions (80 column limit and terminals)

[abszero]

Hello all,

I led development on a PSP port of Angband about two years ago, and am now looking to make a version for the Nintendo DS. The basics didn't take all that long since I have the previous port to compare to, but there's one major difference that causes problems - the DS has two lower resolution screens instead of one large one.

More precisely, I have two 256 * 192 screens, and am using a 6x8 (5x7 plus spaces) font, giving me 42 * 24 chars per screen. So I could technically meet the 80 * 24 requirement by displaying the left half on the upper screen and the right half on the lower, but that would be very awkward visually. There was also work on a 3x8 subpixel font for the NDS, which just barely fits 80 * 24 on a single screen, but the tech demo available on the internet looks unattractive to me, and it will only be worse for colored text.

The solution I'd like to go with is to use one screen to display a 42 * 24 portion of the map and the other screen as a status display, equipment screen, etc. That obviously conflicts with the requirement in dungeon.c's play_game to have 80 columns.

So my main question is whether anyone knows what's required to get around the 80 column limitation. Are there any ports that do this? Even just some tips on which files are most likely to have problems would be great.

Also, I sorta remember reading something about setting up a second 'terminal' to handle the aforementioned status screen. Any tips on how to go about doing that? Like how that's intended to be implemented (anything cleaner than reimplementing fix_frame_compact, etc) or anything else useful?

Thanks for any info!

[Nick]

This is great.

Originally Posted by abszero

There was also work on a 3x8 subpixel font for the NDS, which just barely fits 80 * 24 on a single screen, but the tech demo available on the internet looks unattractive to me, and it will only be worse for colored text.

There has been some work done on a port to the DS - see here. I don't know what state it's in at the moment.

The solution I'd like to go with is to use one screen to display a 42 * 24 portion of the map and the other screen as a status display, equipment screen, etc. That obviously conflicts with the requirement in dungeon.c's play_game to have 80 columns.

It seems to me this could be done two ways on the DS - either have the map on the top screen and some control system on the touch screen, or map and some control on the touch screen and other info on the top. I favour the second option - see below.

So my main question is whether anyone knows what's required to get around the 80 column limitation. Are there any ports that do this? Even just some tips on which files are most likely to have problems would be great.

You should have a look at FAangband 0.2.3, which has a small screen mode which uses a 48 x 24 screen. It is also fully mouse-controllable, so it can be played without a keyboard (apart from entering the character name). This was done primarily to allow it to be ported to Windows CE; this was done by Si Griffin.

I have a plan (which is progressing slowly) to get the mouse control completely and cleanly ported to Vanilla; I'm guessing it will happen sometime in the next 3-12 months

Please feel free to ask for more detail about any of this.

[ajps]

Originally Posted by abszero

So my main question is whether anyone knows what's required to get around the 80 column limitation. Are there any ports that do this? Even just some tips on which files are most likely to have problems would be great.

At the moment, you can't really do a straight "port" and get around it, because all the standard layouts assume at least 80 character wide screens and the current system just gives a "terminal" to the front end and gets it to plot it.

I think the splash screen at the start, help screens, "death" screen and character info ('C') screen are the bits that assume at least 80 characters wide and would actually require redesign to fit on narrower terminals. Stores probably do too, but should be easier to adapt now they use the generic menu display code. The main screen is probably the easiest part, already being in two or three "chunks", with the map part being pretty adaptable.

If you look at the development version in svn I've been working on a system of game events for the frontend to handle rather than terminals with fixed layouts, to try and make it easier to do really radical rearrangements of the UI for handhelds, etc. That's a work in progress though and probably won't be in its final form before December. Using that would probably mean more work for your initial port, but would give more input flexibility too, and would hopefully mean that future versions would "just work".

Well, I can dream, anyway.

Also, I sorta remember reading something about setting up a second 'terminal' to handle the aforementioned status screen. Any tips on how to go about doing that? Like how that's intended to be implemented (anything cleaner than reimplementing fix_frame_compact, etc) or anything else useful?

As Nick says, look at FA for how they've done small-screen stuff there, that's the only proper attempt at reshaping the UI for handhelds so far, and it shouldn't be too hard to compare the changes with the V3.0.9 codebase. It'll be more useful than my suppositions, anyway, I'm sure.

[Nick]

Originally Posted by ajps

I think the splash screen at the start, help screens, "death" screen and character info ('C') screen are the bits that assume at least 80 characters wide and would actually require redesign to fit on narrower terminals. Stores probably do too, but should be easier to adapt now they use the generic menu display code. The main screen is probably the easiest part, already being in two or three "chunks", with the map part being pretty adaptable.

Yes, this is absolutely correct. The worst part of adapting was actually lots of little places where a string longer than 48 was put to the screen; object and monster names are examples. If you go through the FA code and search for small_screen you'll find the (many) places where special treatment was needed.

I think the plan of making the game engine talk to a UI which just deals with it is a great idea. And I suspect it'll be done before I have the mouse control properly done...

[abszero]

Originally Posted by Nick

There has been some work done on a port to the DS - see here. I don't know what state it's in at the moment.

Ah yes, I forgot to mention that. There was one being developed for awhile and a beta was released to a few testers but the author disappeared most of a year ago before making a public release

Originally Posted by ajps

I think the splash screen at the start, help screens, "death" screen and character info ('C') screen are the bits that assume at least 80 characters wide and would actually require redesign to fit on narrower terminals. Stores probably do too, but should be easier to adapt now they use the generic menu display code. The main screen is probably the easiest part, already being in two or three "chunks", with the map part being pretty adaptable.

Great, these are the sorts of things I was trying to think about. I knew death.txt and news.txt needed updating but hadn't thought about some of those others. Redesigning the stores sounds like it might be the worst just because it'd be really nice to keep each item to one line but some of those descriptions are really long. Maybe I can do something like display a truncated one-line version on the main screen and a full length version of the currently selected merchandise on the sub screen?

Originally Posted by Nick

Yes, this is absolutely correct. The worst part of adapting was actually lots of little places where a string longer than 48 was put to the screen; object and monster names are examples. If you go through the FA code and search for small_screen you'll find the (many) places where special treatment was needed.

Great, I'm taking a look at it now. That'll be helpful I'm sure.


I'm thinking the best course of action might be to stick to the lame solution of using each screen for half of an 80x24 terminal until I get the port to a fully playable state. Then I can experiment with some of these suggestions without as many potential sources of bugs.

[Nick]

Originally Posted by abszero

Great, these are the sorts of things I was trying to think about. I knew death.txt and news.txt needed updating but hadn't thought about some of those others. Redesigning the stores sounds like it might be the worst just because it'd be really nice to keep each item to one line but some of those descriptions are really long. Maybe I can do something like display a truncated one-line version on the main screen and a full length version of the currently selected merchandise on the sub screen?

One thing I did here was to replace "Potion of" with "!" (and so on) for shops; then I just truncated descriptions that were too long. Not an ideal solution. What would be really nice would be to have shortened versions of all item and monster names; the look command is another example where this is needed: "You see a Scruffy-looking hobbit (wounded, afraid)" is already a problem, without the prompt for further commands. In fact, maybe the cleanest solution would be to have alternate, short descriptions in the edit files, as well as some rewriting of the description code. But I don't think that's really a porters job

[takkaria]

Originally Posted by Nick

In fact, maybe the cleanest solution would be to have alternate, short descriptions in the edit files, as well as some rewriting of the description code. But I don't think that's really a porters job

I have a very intermittent internet connection at the moment, so in the time I would normally have spent on wikipedia or using IRC in the evenings, I've instead been rewriting the object description code. Expect it to hit SVN sometime this month.

[Nick]

Originally Posted by takkaria

I have a very intermittent internet connection at the moment, so in the time I would normally have spent on wikipedia or using IRC in the evenings, I've instead been rewriting the object description code. Expect it to hit SVN sometime this month.

Brilliant.

[Remuz]

Hi everyone,

It appears the person that originally worked on an angband port replied to the aforementionned thread. He gives away his sources, which seem to be quite outadated, as he mentions that they won't compile with the latest sdk.

http://forum.gbadev.org/viewtopic.ph...fbcd6cba7a68f6

Maybe someone nice, talented and interested can have a look at it and have some success with it. I, for one, would love to be able to play angband on my ds.

Cheers,

[takkaria]

Originally Posted by Remuz

Hi everyone,

It appears the person that originally worked on an angband port replied to the aforementionned thread. He gives away his sources, which seem to be quite outadated, as he mentions that they won't compile with the latest sdk.

http://forum.gbadev.org/viewtopic.ph...fbcd6cba7a68f6

Maybe someone nice, talented and interested can have a look at it and have some success with it. I, for one, would love to be able to play angband on my ds.

Mm. Shame it's built off 2.8.3 -- I imagine very little of work on that will apply cleanly to 3.0.9 and almost certainly not the dev version.

I'm having a look through the diff between 2.8.3 and that port's source now. Looks like some of the work done on the dev branch with splitting out various chunks of code into self-contained files has helped, along with the refactoring present in cmd-obj.c. Seems like if compression of existing savefiles is necessary, future savefile code will also need compression support built-in.

If anyone else fancies a butcher's at the diff: http://rephial.org/research/283-angband-ds.diff