[Announce] Cthangband 6.2.0 Release

[Dean Anderson]

Surely the problem with that is that - as the developer - you don't know how big the screen is going to be, so you can't lay it out properly.

I mean if I know the screen is going to be 80x25 I can make maximum use of that space. On the other hand, if I know it's going to be (say) 80x30 then I know I've got an extra five lines that I can make use of.

And if it's something even bigger like 120x45 then I've got a whole forty column strip down the side that I can use to put things in.

But if the user decides the font and screen size I've no idea how much space I've got so all I can do is fill in the minimum and maybe make the main play area expand to fit.

But other than the play area expanding, the rest of the extra room would all be wasted - or, if the user makes the screen smaller, various stuff would fail to display.

[Aszazin]

The font in the current 80x25 display is at the big side for me on a 23" monitor, but it is okay and fine to play.

If there is any change to the display I would really like, it would be rather using a square font. Almost all bands use a rectangular font, which creates a false sight in distance. The (effective) distance vertical is different than the same in-game distance horizontal.

Although, enlarging the 80x25 display would for sure be not bad, as you require a Windows environment to play your variant. It is less likely it will be played on legacy small display computers. You might try to find the optimal size with a screen size varying from an avarage laptop up to a 27" display.

[Dean Anderson]

If there is any change to the display I would really like, it would be rather using a square font. Almost all bands use a rectangular font, which creates a false sight in distance. The (effective) distance vertical is different than the same in-game distance horizontal.

The problem there is that while having a square cell size is ideal for making vertical and horizontal distances equal, most actual typefaces are designed to be taller than they are wide so forcing them to be square makes them look weirdly squashed or forces you to have unnaturally wide spaces between letters.

[Dean Anderson]

Okay, so last night I did some experimentation and it looks like if I'm sticking to a 16:9 aspect ratio then making the display 80x45 will result in exactly square cells.

I did some testing and while forcing the cells to be square clearly stretches the fonts horizontally, I think I managed to find a good compromise between wide characters and overly spaced out characters.

I also had a quick play around increasing the main game display to take advantage of the extra rows, and that's going to need some careful fiddling. The way the game works (and this is stuff that's not changed in 20 years) is that the size of dungeon levels is based on multiples of the screen size and the internal layout of dungeon levels is based on sub-units that divide up into the screen size neatly.

In the current game, those sub-units are 22x11 grid tiles, and the screen is 66x22 grids (i.e. 3x2 sub-units, which is why small levels tend to have 3x2 rooms, one room per sub-unit) - with the maximum dungeon size being 198x66 grids (i.e. 3x3 screens or 9x6 sub-units).

The question is: do I need the screen to be an exact multiple of a sub-unit? The only way I could do that with a 45 row display would be to have it 4 sub-units tall which would be 44 of the 45 rows. That would only leave a single row at the top of the screen for your messages and would leave no space at the bottom for status texts (e.g. depth, "poisoned", etc.)

And if I don't have the screen an exact multiple of a sub-unit (for example, if I have it 42 rows instead of 44, so I've got two rows at the bottom for status text), what knock-ons does that have? Currently, I've no idea.

[Aszazin]

Cool, you actually try stuff immediatly!

It's quite abstract what your are telling to me currently. I didn't have any idea there was such a relation between the display and the dungeon creation.

The question is: do I need the screen to be an exact multiple of a sub-unit?

I'd say: no.
As Cthangband is a windows game, I'd de-couple the display from the dungeon creation. I guess it would create more options in the future to generate different kind of dungeons.

[Dean Anderson]

Cool, you actually try stuff immediatly!

I was actually intending to put Cthangband on the back burner for a while because I have another project I'm supposed to be working on (I write tabletop RPGs as well as Angband variants), but this talk of display changes got me interested.

It's quite abstract what your are telling to me currently. I didn't have any idea there was such a relation between the display and the dungeon creation.

It stems from the old days before the display used to scroll with you in the centre.

When Moria was first written, before it was ported to Angband, there's no way the computers running it would have been able to redraw the whole screen quickly enough for it to be acceptable, so the map couldn't scroll around with every move of the player.

The work-around for this was to have the concept of an 11x11 tile "panel". The main game view on screen was (and still is by default) 66x22 characters, so it was exactly 6x2 panels big.

The way this worked was that the screen therefore contained six columns, each one containing a half panel at the top and bottom and a full panel in the middle. As you move around the dungeon, the game always knows which panel you're in; so it makes sure that it's one of the two panels that's in the centre of the screen.

The effect to the player is that the screen flicks rather than scrollling. While you're near the middle of the screen (i.e. in the middle panels) the screen doesn't move, and it's only when you move into one of the surrounding panels that the screen redraws the whole display centering that panel instead. The exception being that when you're near the very edge of the map it lets you go right up to the edge of the screen.

One side-effect of this flick-screen system was that the map was only ever displayed at known points - looking left-to-right you always had six whole panels and looking to-to-bottom you always had two half-panels sandwiching a whole panel.

The reason this was then tied into dungeon generation was twofold. Firstly, the dungeon size had to be an exact multiple of the panel size to prevent the game from trying to draw out-of-bounds areas when it drew the display. And secondly, when placing rooms the dungeon generation would always place a room entirely in a single panel rather than across two panels so that a room wouldn't end up half on the screen and half off, or make you flick screen while you were in the middle of it.

Although the flick-screen system is no longer used, the panels still exist for two reasons.

Firstly, the dungeon generation still works the same way as it always did. The first thing it does is divide up the map into panels and then go through deciding which panels should contain rooms before connecting those rooms up with panel-spanning corridors.

And secondly, the display system still uses them. You know how it scrolls centering the player until you get near the edge of the map and then it lets you walk to the edge of the screen without scrolling? That's because behind the scenes it's still using the code that tracks which panel you're in. The difference is that if you're not in one of the edge panels it centers on you instead of centering on the panel you're in; but if you are in one of the edge panels it still lets you move to the edge of the screen.

So that's why the dungeon generation still cares about the screen size. When it creates the level, it creates it an integer multiple of the screen size and then divides it into panels knowing that this will also be an exact integer.

If the map size is not an exact multiple of the panel size then the dungeon won't reach all the way to the edge of the map; and if the screen size is not an exact multiple of the panel size then it won't scroll all the way to the edge of the screen, stopping short by however large the remainder is when one is divided by the other.

I'd say: no.
As Cthangband is a windows game, I'd de-couple the display from the dungeon creation. I guess it would create more options in the future to generate different kind of dungeons.

I thought about that, but it would be quite a lot of work to decouple the systems from each other. We'd need a different algorithm for dungeon generation which would mean the dungeons wouldn't have that "classic" Angband look, and we'd also need a different display system.

It's all doable, but a lot of work for little gain.

So after a bit of experimenting, I simply increased the size of each panel.

With the old 66x22 display, that was 6x2 11x11 panels and a dungeon with a maximum size of 3x3 screens (that is 18x6 panels or 198x66 tiles).

So with the new 66x42 display, I still have 6x2 panels; but now they're 11x21 in size. The dungeon can still be a maximum size of 3x3 screens (still 18x6 panels but now 198x126 tiles).

This way, everything still works nicely. You still have a dungeon that's always an exact multiple of panels and a screen that's an exact multiple of panels. The dungeon generation still places rooms in panels and still reaches the edge of the map; and the display still scrolls around you until you approach the edge and still reaches the edge of the map.

The only difference is that the dungeons are about twice as tall as they were before, with the rooms further apart vertically. This isn't a problem, because it fits the squarer tiles and although the dungeon is physically bigger it doesn't seem that much bigger because it still has the same number of rooms. It's just the north-south corridors that are longer, and they now more closely match the east-west corridors.

(Wilderness and town maps were 1x2 screens before, or 80x44 tiles, and had vertical but not horizontal scrolling. With the new display I've reduced them to 1x1 screen, or 80x42 tiles. That's only two tiles smaller, so it doesn't make much difference in terms of fitting things into them, but it makes a huge difference in terms of feel having an entire town or entire wilderness grid on screen at once instead of having the partial scroll.)

This is all working fine in my dev build. However, there's a surprising amount of other things that need changing. All the non-overhead displays (opening title, menu, character viewer, character creation screens, inventory, journal, map view, messages, shops, and so forth - there are more than you might think) are all now squashed up into the top half of the display and look terrible.

[Aszazin]

Thanks for the explanation.
Changing the dungeon/display relation indeed must be a hell of a job for little gain.

This is all working fine in my dev build. However, there's a surprising amount of other things that need changing. All the non-overhead displays (opening title, menu, character viewer, character creation screens, inventory, journal, map view, messages, shops, and so forth - there are more than you might think) are all now squashed up into the top half of the display and look terrible.

Sounds like a domino effect!

I'm quite curious right to try what you made.

Does the shift+direction keys for running work again in your dev version too?
I'm currently playing a vanilla game, waiting for the shift to work again to run and dive into Cthangband. Using the period is painful on my azerty-keyboard.

[Pete Mack]

You might take a look at how other variants do this now. The display code is a lot more mature and portable, and you can pretty much drop your code in and not worry about it.

[Gwarl]

Specifically bigscreen (display areas of any MxN rather than the original 66x22) was added in stages between 2.8.3 and 3.0.6

Very helpful in this regard is the original 2.9.0 bigscreen patch which is still available on mirrors of the old thangorodrim ftp site in the /patches/ directory.

On the other hand while I have subsequently been able to apply bigscreening to other previously 66x22locked variants they are all of the post 2.9.3 generation and I still haven't worked backwards to succesfully bigscreen any of ben harrison's version or their variants.

[Dean Anderson]

It's not difficult - I know exactly what needs doing to decouple the dungeon size from the screen size. It's just that it's a lot more effort than I think it's worth to do so, because it gives basically no (short term) gain over simply tweaking the panel/dungeon size to match the new screen size.

So I'm going to be lazy for the moment, and then if - some time later - I do need to decouple them I'll do it then.

[Dean Anderson]

Does the shift+direction keys for running work again in your dev version too?
I'm currently playing a vanilla game, waiting for the shift to work again to run and dive into Cthangband. Using the period is painful on my azerty-keyboard.

I've not done that yet, but it's not difficult. I'll do it before I release 6.3.

One thing that was a weird side-effect of the screen size change is that the various static screens containing ASCII art (splash screen, death screen, victory screen) no longer fit.

Take the one on the splash screen, for example, the Cthulhu head. On the old screen there wasn't room to put the whole thing on, so I had to truncate it, chopping off the top of the head and the bottom of the tentacles. Now, with the screen so much bigger the truncated version just looks silly. I spent quite a few hours over the weekend looking for the original ASCII art Cthulhu head to use that, but of course it's getting on for twenty years since I originally found it and it's now nowhere to be seen on any ASCII art site.

So instead, I swapped out the ASCII art splash screen for a fully graphical one.

The way the current display system works, I've got my grid of tiles sitting on top of a canvas. In 6.2, the canvas was always simply left blank (and black), but there's no reason that has to be the case. So for the splash screen I now place a texture on that canvas so that instead of a blank screen behind the text, there's a full graphic of Cthulhu's head and a fancy splash-screen title.

Of course, that's started a slippery slope. Now that I have a full-screen graphic for the splash screen, I have to replace it with something else when the splash screen goes away, because otherwise it would sit there constantly. So I've put in a second texture to sit behind the menu. And a third to sit behind the game screen.

And I'm going to need more to sit behind the various other screens (character generation, journal, etc.) and more to replace the old death and victory screens...

[Aszazin]

So instead, I swapped out the ASCII art splash screen for a fully graphical one.

Oh nice!
I'm completely into playing Angband-like games into ASCII, it makes the game more fun and more efficient in ascii. But adding to that graphical elements only makes it great.

I love to search the internet for an image of any monster I meet where I do not know what it actually can be.

Mixing graphical elements in a ~band game can be great I think. From a apart window vanilla 4.2-style with a picture of what you are "targeting" or "looking" at, up to using the black background in translucent overlay to give a graphical impression of your target, sight or environment.

And to make it complete: a ~band game with synthesized atmospheric music would be completely crazy. For instance by introducing some kind of SID-emulator using C64 Cyber tracker to compose the music.

(OK, sorry, just letting my fantasy go, I guess you know where to put your time in for now already

[Dean Anderson]

I've encountered an unexpected problem with shift-to-run.

Basically, it's a limitation of the way the WPF Framework handles keyboard input.

When one or more keys are pressed, the WPF Framework tells me what has been pressed. However, it doesn't give me raw keyboard input - instead it tries to be clever and assumes that I want the raw input translated into functional keypresses.

The problem here is that handling of the numpad is therefore ambiguous.

If NumLock is off, the numpad gives me "Home", "Up", "PgUp", and so on - the functions that those keys have with NumLock off. If the shift key is pressed, I also get given the "Shift" modifier. This is fine, because I can treat those key values as directions and if I also get the "Shift" modifier then I can treat them as "Run" directions.

However, if NumLock is on (which is most of the time in my experience), things are different. In this case, a simple press of a numpad key gives me the number; but if the shift key is pressed I do not get given the number with a "Shift" modifier! Instead I get the key that I would have got if NumLock were off - i.e. "Home", "Up", "PgUp", and so on. What's worse, it doesn't even set the "Shift" modifier but just gives me those key codes without it.

This causes a problem, because I have four possible states which need two different behaviours, but two of the states that require different behaviours give the same input. Based solely on the above, I get either:

• A number without shift - I know the user hasn't pressed shift, so the character should WALK
• A direction (e.g. "Left") with shift - I know the user has pressed shift, regardless of whether the "Left" came from the numpad or the cursor keys, so the character should RUN
• A direction (e.g. "Left") without shift - This could be because...
  1. the user has pressed shift with NumLock on, in which case the character should RUN
  2. the user has not pressed shift and NumLock is off, in which case the character should WALK
  3. the user has pressed a cursor key with NumLock on, in which case the character should WALK
  4. the user has pressed a cursor key with NumLock off, in which case the character should WALK

The problem is with the ambiguity in this last case. As far as I can tell (from the WPF documentation and from searching online) there's simply no way to distinguish between the four scenarios in the last case - which means there's no way to know whether the character should run or walk. Well, I can tell whether NumLock is on or off, so I can tell whether we're in scenario a/c or scenario b/d, but not which specific one within either of those pairs.

In the case of scenario b/d it doesn't matter. In either case, the character should walk. However, in the case of scenario a/c I have to decide whether to make the character run or walk without knowing which of the two combinations it is, and that means sometimes I'll be wrong.

I seem to have two choices.

1. Assume we're in (c) and always treat a direction without Shift as WALK. This means that the user will have to turn NumLock off if they want to use shift-to-run. That's a pain because most people have NumLock on all the time, and having to remember to turn it off for this program and back on again after they've finished playing is annoying.
2. Assume we're in (a) and treat a direction without Shift but with NumLock on as RUN. This means that the numpad will always work correctly, but if NumLock is on (which is likely as most people have it on all the time) then pressing the cursor keys will always run even if shift is not being pressed.

I think I'm going to go for the latter as the lesser evil, but I don't like it. I assume very few people use the cursor keys to move because you can't do diagonals with them, but having them always run will be confusing for the minority that do.

[Gwarl]

I've encountered an unexpected problem with shift-to-run.

Basically, it's a limitation of the way the WPF Framework handles keyboard input.

When one or more keys are pressed, the WPF Framework tells me what has been pressed. However, it doesn't give me raw keyboard input - instead it tries to be clever and assumes that I want the raw input translated into functional keypresses.

The problem here is that handling of the numpad is therefore ambiguous.

If NumLock is off, the numpad gives me "Home", "Up", "PgUp", and so on - the functions that those keys have with NumLock off. If the shift key is pressed, I also get given the "Shift" modifier. This is fine, because I can treat those key values as directions and if I also get the "Shift" modifier then I can treat them as "Run" directions.

However, if NumLock is on (which is most of the time in my experience), things are different. In this case, a simple press of a numpad key gives me the number; but if the shift key is pressed I do not get given the number with a "Shift" modifier! Instead I get the key that I would have got if NumLock were off - i.e. "Home", "Up", "PgUp", and so on. What's worse, it doesn't even set the "Shift" modifier but just gives me those key codes without it.

This causes a problem, because I have four possible states which need two different behaviours, but two of the states that require different behaviours give the same input. Based solely on the above, I get either:

• A number without shift - I know the user hasn't pressed shift, so the character should WALK
• A direction (e.g. "Left") with shift - I know the user has pressed shift, regardless of whether the "Left" came from the numpad or the cursor keys, so the character should RUN
• A direction (e.g. "Left") without shift - This could be because...
  1. the user has pressed shift with NumLock on, in which case the character should RUN
  2. the user has not pressed shift and NumLock is off, in which case the character should WALK
  3. the user has pressed a cursor key with NumLock on, in which case the character should WALK
  4. the user has pressed a cursor key with NumLock off, in which case the character should WALK

The problem is with the ambiguity in this last case. As far as I can tell (from the WPF documentation and from searching online) there's simply no way to distinguish between the four scenarios in the last case - which means there's no way to know whether the character should run or walk. Well, I can tell whether NumLock is on or off, so I can tell whether we're in scenario a/c or scenario b/d, but not which specific one within either of those pairs.

In the case of scenario b/d it doesn't matter. In either case, the character should walk. However, in the case of scenario a/c I have to decide whether to make the character run or walk without knowing which of the two combinations it is, and that means sometimes I'll be wrong.

I seem to have two choices.

1. Assume we're in (c) and always treat a direction without Shift as WALK. This means that the user will have to turn NumLock off if they want to use shift-to-run. That's a pain because most people have NumLock on all the time, and having to remember to turn it off for this program and back on again after they've finished playing is annoying.
2. Assume we're in (a) and treat a direction without Shift but with NumLock on as RUN. This means that the numpad will always work correctly, but if NumLock is on (which is likely as most people have it on all the time) then pressing the cursor keys will always run even if shift is not being pressed.

I think I'm going to go for the latter as the lesser evil, but I don't like it. I assume very few people use the cursor keys to move because you can't do diagonals with them, but having them always run will be confusing for the minority that do.

Practical experience with angband.live;

I encountered issues similar in nature if not the specifics making shiftrun work on the curses port. The compromise for a long time and still the case in most versions hosted was to require numlock to be on and the use of a numpad. I note here in all caps that by far the most common scenario is people arriving with numlock OFF, which is how my PC boots up and I have to switch it on every time I play.

I've reverted that policy non-retroactively, instead I have a file called runlock.prf which works for almost every variant that I add to the pref folders which replicates the situation I described above without enabling shiftrunning. Almost every version also contains a bug where the message 'failed to load runlock.prf' is printed, but it works all the same.

My advice then would be to use pref files and have a menu option that loads the set of macros for each desired behaviour to make the option stand out to players.

[Aszazin]

All ~bands I play require the NumLock to be off to be able to run with the shift-key and the numpad.
So I always turn NumLock off.

I guess it's not a big issue to turn NumLock off or on, isnt it?