Textui reform (warning: long and full of C)

[t4nk]

On colour reform, there's a general belief that the game should use a limited colour palette so that the colours are distinguishable, at least in ASCII mode, so I'm not sure using rgba gains much.

Well, maybe that's true for Angband, but Angband is not the only game that is possible to create using Angband's engine, is it

With tiles and transparency, I think it would be good to be able to draw more than two tiles on a grid - so you can draw, e.g. the floor, a trap/an object, and a monster, one on top of the other. And like you say, it would be good to be able to apply tints of various kinds to the tiles. This could maybe remove the need to have 4 different tiles per terrain feature.

Hmm, that's an interesting idea. I recall that Crawl can display an object on a trap at least... Now that grid cells are structs it's easy to add more stuff to them.

With regard to input, I guess it makes sense for keypresses to be global but mouse clicks are on particular sections of the screen. Maybe that means that mouseclicks get passed along in the ui_event struct with a pointer to the term they were triggered on.

Yes, I thought about that. Something like that will probably be necessary to make right mouse click menus work ("run towards" etc).

[takkaria]

Well, maybe that's true for Angband, but Angband is not the only game that is possible to create using Angband's engine, is it

True.

I am really impressed with your work so far!

[Pete Mack]

Yeah, but the basic problem remains: in text mode, only a relatively small number of colors can be distinguished by eye. It is not unique to angband. Boldface, italic, flickering is a better option in general here. Certainly there's room for a few more colors. But not 256, or even 64, let alone "millions". Now it's certainly reasonable to render graphics in many colors, but that is already done in most of the ports (X11 and gcu being the obvious exceptions.)

Well, maybe that's true for Angband, but Angband is not the only game that is possible to create using Angband's engine, is it

[t4nk]

I am really impressed with your work so far!

What My method is extremely questionable. Initially I planned to leave the Term API more of less as it is, and just do some minimal updates to textui, to get it to work as quickly as possible. And, of course, I ended up redesigning ui-term.c entirely, and I'm rewriting huge parts of textui So, naturally, when I'll finally manage to compile it, it just won't work, and then I'll have to fix it! We'll see. I simply can't resist the temptation. Right now I'm thinking what to do with ui-object.c... such a pile of nonsense... (btw, debo, I saw horrible things, but I still think inkey() is the worst )

Yeah, but the basic problem remains: in text mode, only a relatively small number of colors can be distinguished by eye. It is not unique to angband. Boldface, italic, flickering is a better option in general here. Certainly there's room for a few more colors. But not 256, or even 64, let alone "millions". Now it's certainly reasonable to render graphics in many colors, but that is already done in most of the ports (X11 and gcu being the obvious exceptions.)

See Brogue for an example! I know that some people call it "clown vomit", I don't care

[Pete Mack]

@t4nk--
If you think angband's code is archaic, then take a look at poschengband. That really does contain very much of the original code from angband v 2.7-2.8 from which it was forked. There is code in there that says "I borrowed the idea from v3.5 but rewrote it from scratch" on undocumented code with variable names like "o", "l", and "t". Very, very old school stuff.

[takkaria]

What My method is extremely questionable. Initially I planned to leave the Term API more of less as it is, and just do some minimal updates to textui, to get it to work as quickly as possible. And, of course, I ended up redesigning ui-term.c entirely, and I'm rewriting huge parts of textui So, naturally, when I'll finally manage to compile it, it just won't work, and then I'll have to fix it! We'll see. I simply can't resist the temptation. Right now I'm thinking what to do with ui-object.c... such a pile of nonsense... (btw, debo, I saw horrible things, but I still think inkey() is the worst )

Well to me it looks like a solid start - some of the refactoring/rewriting, as you note, is sorely necessary - I've been avoiding untangling ui-target.c for years. And the term redesign looks a lot more compact than its predecessor. Keep going

[Pete Mack]

@t4nk--
is some of this on GitHub?

[t4nk]

If you think angband's code is archaic, then take a look at poschengband.

Actually, I don't think it's TOO archaic. Some parts of it are (ui-object.c mentions Koeneke), but not even most of it. And the difference between more modern code (like, your stuff - assuming it's the same Pete Mack and takkaria's stuff) and old code (Harrison etc.) is huge... So far the worst parts were inkey(), ui-target.c (just too much spaghetti) and now ui-object.c. Other then that, I'm mostly removing unused things, renaming variables and reformating things the way I like it (just to entertain myself while I'm reading the code, no offence )
The code is on github, https://github.com/t4nk074/angband - the "textui2" branch (see ui2-* files).

[Pete Mack]

Thanks. I'll keep an eye on it. Looks like you haven't pushed any changes yet.

[t4nk]

What? I pushed tons of commits already!

[Carnivean]

(like, your stuff - assuming it's the same Pete Mack

It's the same one.

[Nick]

What? I pushed tons of commits already!

Wow, yeah, I haven't been watching - 120 commits ahead. I should read some of them

[Pete Mack]

My bad. I missed it in the scroll list for branches.
Question: what's the benefit to abandoning null-terminated strings, and adding the length field as a struct? (This was widely frowned upon, back in the day, because in the long run, it tended to break up the heap.)

What? I pushed tons of commits already!

[t4nk]

My bad. I missed it in the scroll list for branches.
Question: what's the benefit to abandoning null-terminated strings, and adding the length field as a struct? (This was widely frowned upon, back in the day, because in the long run, it tended to break up the heap.)

There are numerous advantages in doing it this way, that's why all programming languages that have real strings (that is, not C) do it like that... what's really broken is C-style "strings"! I think I only have it in ui2-object.c, though? That's just a small optimization... since everything in there depends on max_len anyway (so changing these strings after building the object list is totally not recommended )
Besides, they ARE null terminated!

[t4nk]

...... . ...!!! TILE/GLYPH PICKER I'll just nuke this garbage. Tile picker won't work anyway.