Feature Request : Rhythmic blinking

[konijn_]

Greetings,

I was thinking that Uniques in the monster list could blink, but like the mac light when its sleeping. Twould be cool and useful ( at least for me ).

T.

[Hariolor]

Greetings,

I was thinking that Uniques in the monster list could blink, but like the mac light when its sleeping. Twould be cool and useful ( at least for me ).

T.

This could be cool - but I think it may look odd when creatures are moving. It'd be a neat effect when everything's standing still, though, especially for the unique balrogs and the Nine.

[Derakon]

I've often wondered if it'd be worth adding color-shifting effects that would occur in-between turns. Multi-hued units would benefit from a smooth rainbow effect, and yeah, you could hit up uniques with it too. Maybe you could augment the G: line in monster.txt with a set of colors to cycle through and the rate at which they cycle. The biggest problem would probably be updating the render code to run continuously.

[Magnate]

Greetings,

I was thinking that Uniques in the monster list could blink, but like the mac light when its sleeping. Twould be cool and useful ( at least for me ).

T.

God no, please please no. Blinking is incredibly, hugely irritating. Absolutely definitely not.

Not that I'm ambivalent or anything.

[Derakon]

The Mac "blink" is more of a slow brightening/dimming effect. So for example, over the course of two seconds it ramps smoothly from #333333 to #FFFFFF, and then over the next two seconds it ramps back down. I don't think that'd be anywhere near as annoying as a true blink, though it might still be sufficiently distracting as to not be worth using.

[Magnate]

The Mac "blink" is more of a slow brightening/dimming effect. So for example, over the course of two seconds it ramps smoothly from #333333 to #FFFFFF, and then over the next two seconds it ramps back down. I don't think that'd be anywhere near as annoying as a true blink, though it might still be sufficiently distracting as to not be worth using.

Ah. Thanks for the explanation. That might not be quite so awful (but I could still think of a hundred or so other things I'd rather see changed).

[takkaria]

The biggest problem would probably be updating the render code to run continuously.

That would indeed would be technically challenging. I quite like the idea of adding the ability to change background colours as well as foreground colours though (so you could have black on white, or just plot walls as blocks of grey without needing special characters on Windows).

[Nightmarjoo]

That would indeed would be technically challenging. I quite like the idea of adding the ability to change background colours as well as foreground colours though (so you could have black on white, or just plot walls as blocks of grey without needing special characters on Windows).

lol I never understood why people don't like # as walls, I can't stand those blocky things.

[Hariolor]

I have customized the crap out of the character set for dungeon features precisely because I can't stand # for walls. My dungeons are very pleasing to look at now, though I would *love* solid-color walls as Takkaria suggests.

The # wasn't so bad on my old AtariST monitor ages ago, but seeing them in white on black on a big Mac screen just makes me cry.

[d_m]

I quite like the idea of adding the ability to change background colours as well as foreground colours though (so you could have black on white, or just plot walls as blocks of grey without needing special characters on Windows).

Agreed. I think if we can get this implemented it will make a *lot* of things much nicer.

[andrewdoull]

That would indeed would be technically challenging. I quite like the idea of adding the ability to change background colours as well as foreground colours though (so you could have black on white, or just plot walls as blocks of grey without needing special characters on Windows).

Have you given any thought to adopting libcotd as an interface, given that that library supports foreground and background colours?

Andrew

[takkaria]

Have you given any thought to adopting libcotd as an interface, given that that library supports foreground and background colours?

I'm pretty sure that adding background colours to Angband's terminal package would be significantly easier than moving it across to using another library— the change should be mostly localisable to z-term and the main-* files, most of which we have maintainers for thesedays. Moving to libcotd seems like it would be a hell of a lot of work for not a huge amount of gain.

[d_m]

Have you given any thought to adopting libcotd as an interface, given that that library supports foreground and background colours?

Andrew

Wouldn't adopting libcotd mean giving up on the GCU port? From what I could tell libcotdwould replace all the other display styles.