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.

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]

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]

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]

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

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?

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]

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]

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]

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.php?t=11305&postdays=0&postorder=asc&start=30&sid=0db7631ee36bc75e48fbcd6cba7a68f6

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]

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.php?t=11305&postdays=0&postorder=asc&start=30&sid=0db7631ee36bc75e48fbcd6cba7a68f6

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

[Remuz]

That's quite a big diff file, unfortunately.

As a side note, I have tried nethack's port (at http://stuartp.commixus.com/nhds/). I am not a big fan of nethack. I used to play it, but got bored of having to remember 3 or 4 keys just to equip the different pieces of my equipment. However, I wanted to see what choices were made, from a playability point of view. I came to the following observations :
- The lower screen is used as a keyboard. This means that the developers did not bother to design a mouse-only interface beforehand. While not the best long-term solution, it is by far the easiest one, as it is simply a clone of the existing interface.
- One can either use characters or tiles on the upper screen. The size is 6*9. This is in my opinion way too small. I can hardly differentiate characters, and playing the game is very difficult.

In other words, I totally agree with what was discussed above. The 80*24 standard display is not achievable on that hardware. It would be more sensible to just show 40*12 (or so), and force the player to 'L'ook around when in need of more information.

Just my two cents.

Edit : for the sake of completeness : this (http://frodo.dyn.gno.org/~brettk/NetHackDS) looks much better and has some very good ideas.

[Pete Mack]

I totally agree with what was discussed above. The 80*24 standard display is not achievable on that hardware. It would be more sensible to just show 40*12 (or so), and force the player to 'L'ook around when in need of more information.

Cutting the number of rows sounds like a bad idea. 24 rows is just enough to fit a single LOS (not diameter). Going below 20 would mean that it would no longer be possible to do vertical targeting without multiple-screen scrolling. And the number of instadeaths to offscreen attacks would skyrocket. I suspect the game would be nearly unplayable. I strongly recommend looking at FAangband's small screen mode. (You can compile it small-screen for a full-screen device for a quick look.)

I suspect it would be easier to convert V's Character Info page to a small screen version, as the layout is more table-driven.

[takkaria]

Cutting the number of rows sounds like a bad idea. 24 rows is just enough to fit a single LOS (not diameter). Going below 20 would mean that it would no longer be possible to do vertical targeting without multiple-screen scrolling. And the number of instadeaths to offscreen attacks would skyrocket. I suspect the game would be nearly unplayable. I strongly recommend looking at FAangband's small screen mode. (You can compile it small-screen for a full-screen device for a quick look.)

I suspect it would be easier to convert V's Character Info page to a small screen version, as the layout is more table-driven.

ajps was muttering about having different modes; a smaller font for exploring, a bigger font for when you start getting in fights with things.

[Pete Mack]

ajps was muttering about having different modes; a smaller font for exploring, a bigger font for when you start getting in fights with things.

Do any of these devices have a portrait mode? The problem largely goes away if you align the narrow axis of the font with the narrow axis of the screen.

[Nick]

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.

Awesome, well spotted.

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

Thanks, Andrew, that's really helpful.

Edit : for the sake of completeness : this (http://frodo.dyn.gno.org/~brettk/NetHackDS) looks much better and has some very good ideas.

I have seen this one. I don't want to promise anything, but I think the combination of this and the 283 port may be enough.

Cutting the number of rows sounds like a bad idea. 24 rows is just enough to fit a single LOS (not diameter). Going below 20 would mean that it would no longer be possible to do vertical targeting without multiple-screen scrolling. And the number of instadeaths to offscreen attacks would skyrocket. I suspect the game would be nearly unplayable. I strongly recommend looking at FAangband's small screen mode. (You can compile it small-screen for a full-screen device for a quick look.)

I've already tested (and am planning to implement as a birth option) playing FA with all the projection and detection distances halved (it's an almost trivial code change). It does change the gameplay, but not as much as you might expect (although likely in some ways I didn't encounter). This would allow screen reduction, I think.

Having said that, I found the Nethack port quite reasonable, and happen to know that at least one person has ascended playing it; I think that having both as options would make sense.

That's quite a big diff file, unfortunately.

Meh. I've seen bigger.