Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old January 10, 2020, 09:14   #21
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 142
Dean Anderson is on a distinguished road
Quote:
Originally Posted by Aszazin View Post
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.

Quote:
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.

Quote:
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.

Last edited by Dean Anderson; January 10, 2020 at 13:42.
Dean Anderson is offline   Reply With Quote
Old January 11, 2020, 23:43   #22
Aszazin
Rookie
 
Join Date: Jun 2018
Posts: 20
Aszazin is on a distinguished road
Thanks for the explanation.
Changing the dungeon/display relation indeed must be a hell of a job for little gain.

Quote:
Originally Posted by Dean Anderson View Post
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.
Aszazin is offline   Reply With Quote
Old January 12, 2020, 00:49   #23
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,503
Donated: $40
Pete Mack is on a distinguished road
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.
Pete Mack is online now   Reply With Quote
Old January 12, 2020, 18:20   #24
Gwarl
Knight
 
Join Date: Jan 2017
Posts: 800
Gwarl will become famous soon enough
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.
Gwarl is offline   Reply With Quote
Old January 12, 2020, 21:07   #25
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 142
Dean Anderson is on a distinguished road
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 is offline   Reply With Quote
Old January 12, 2020, 22:16   #26
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 142
Dean Anderson is on a distinguished road
Quote:
Originally Posted by Aszazin View Post
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...

Last edited by Dean Anderson; January 12, 2020 at 23:51.
Dean Anderson is offline   Reply With Quote
Old January 13, 2020, 20:23   #27
Aszazin
Rookie
 
Join Date: Jun 2018
Posts: 20
Aszazin is on a distinguished road
Quote:
Originally Posted by Dean Anderson View Post
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
Aszazin is offline   Reply With Quote
Old January 14, 2020, 13:41   #28
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 142
Dean Anderson is on a distinguished road
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.

Last edited by Dean Anderson; January 14, 2020 at 14:12.
Dean Anderson is offline   Reply With Quote
Old January 14, 2020, 16:59   #29
Gwarl
Knight
 
Join Date: Jan 2017
Posts: 800
Gwarl will become famous soon enough
Quote:
Originally Posted by Dean Anderson View Post
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.
Gwarl is offline   Reply With Quote
Old January 14, 2020, 22:10   #30
Aszazin
Rookie
 
Join Date: Jun 2018
Posts: 20
Aszazin is on a distinguished road
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?
Aszazin is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[Announce] Composband 7.1.2 release Gwarl Variants 12 September 4, 2019 13:01
Cthangband 6.1 Release Dean Anderson Variants 8 September 3, 2019 03:03
[Announce] Composband 7.1.1 release Gwarl Variants 15 June 3, 2019 11:29
[Announce] Cthangband 6.0 ("20th Anniversary Edition") Released Dean Anderson Variants 27 August 26, 2018 12:46
[Announce] Cthangband 5.0.0 Released Dean Anderson Variants 67 March 31, 2016 14:16


All times are GMT +1. The time now is 04:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.