[FEATURE] Transparent mode and adaptive colors
Closed this issue · 18 comments
Is your feature request related to a problem? Please describe.
I want to be able to play this game in the transparent background.
Describe the solution you'd like
If possible; Please add:
- A configuration option which can enable/disable transparent mode.
- The game should not change color of terminal background in transparent mode
- Use adaptive colors based on current background in transparent mode
Describe alternatives you've considered
Alternatively, just remove the use of background colors using a build time flag.
Additional context
- While playing, screen becomes transparent for some of the menus.
Not sure if this is a bug or intended behavior. I actually want this game to stay transparent.
I looked into this a bit and it may be doable.
Current situation
ATM, the default terminal colors stay put until we request a reset of the color pairs (to use our own for the game's palette).
While playing, screen becomes transparent for some of the menus.
Could you elaborate? Which screens make the background go back to transparent, after it turns opaque?
References
From this and this it seems possible to explicitly request for the default background to be saved, so that it can be used in the application. What I think it's hinting at, is using the default background obtained to replace the curses-default one.
I need to look better into this.
This would probably be handled in sprites4curses, even though nothing stops the game code from storing that info.
I am thinking the handling of color pairs is something to relegate to that module, since for now init_s4c_color_pair() is the entrypoint for this step.
Conclusion (for now)
I will have to look further in this, but it definitely is an interesting feature, and there's some kind of support for it.
Terminal capabilites are a messy subject, but this is definitely something we could try.
I will update this, in some time, when I have more news. Thanks!
Could you elaborate? Which screens make the background go back to transparent, after it turns opaque?
Only referring to initial prompts after starting the game with ./helapordo -D
I should have been more clear about that.
- Welcome screen is transparent
- Select save is transparent
- Select save slot is opaque (check attached gif file)
- Prompt for Entering name and class is transparent
- After that game becomes opaque till we quit
After that game runs smoothly. Sorry i was not very clear in the post.
I will have to look further in this, but it definitely is an interesting feature, and there's some kind of support for it.
Terminal capabilites are a messy subject, but this is definitely something we could try.
I will update this, in some time, when I have more news
Thank you for considering this.
* After that game becomes opaque till we quit
This seems to confirm my idea that the current color preparation does not account for the default terminal background.
The prompts for name and class are transparent because they are done outside of curses, in plain terminal.
Curses mode is resumed later.
The funky behaviour on save slot selection is due to it being added at a later point. Originally, that step in the launch flow was not present, and it was shoehorned in later. I'll try to put a link to this change, just for the curious.
Coincidentally, I am currently updating that section so that it too will use curses mode, so in any case at the very least the abrupt change might be avoided.
Funny enough, just dropping this line should allow the saveslot selection to still use the default color regardless of any further fix.
I have to note that I was not really bothered by losing my background transparency as I am kind of used to the dark tint the game takes for the background. That's because for me, the background is a deep purple, not this gray you have shown in the gif.
What I'm thinking is, we should call use_default_colors() after entering curses mode, so that anything we don't touch is filled with the terminal's default background color.
I don't know if it will work, but maybe that would be enough.
I'll look further into this in the coming days, it might be slow but I'll try to update.
Edit:
Update
I made a commit on devel branch with the bare minimum for this. There's still some artifacts, which would indeed need a sprites4curses update to be fixed.
So, all in all, I'd say this could be merged as soon as the underlying lib is updated to account for this.
I'll try to find time in the coming days, for now, please enjoy the development branch if you want.
Just, don't expect the current commits to stay. I'll try to implement this better, but it may take some time.
Use adaptive colors based on current background in transparent mode
About this: do you mean the text should be colored using some information from the things rendered behind the terminal? I don't think that would be doable. I just don't think ncurses may expose anything useful for this kind of stuff, since I guess even the terminal itself has no idea about that. Most likely, it's just declaring itself as transparent to the window manager.
I'm just wildly speculating, but I'm afraid I haven't even really understood the requirement.
do you mean the text should be colored using some information from the things rendered behind the terminal? I don't think that would be doable.
Yes i meant the same with adaptive colors. I agree that wouldn't be doable.
Do consider adding whatever is possible whenever you find it fit to implement doable things mentioned in this feature request.
Thanks again this is a lovely game. Thank you for making this.
Do consider adding whatever is possible whenever you find it fit to implement doable things mentioned in this feature request.
If you checkout the current devel branch, you can run with -X to check out the basic implementation of you request. Will be polished with options.
I had edited my previous reply already.
Thanks again this is a lovely game. Thank you for making this.
Thank you for your help!
I have briefly tested the current status of devel and it seems to me it could use some more refinement.
For example, by having a light background, I noticed the map gets a little hazy and hard to see when in transparent mode.
Do you also feel this could be a problem?
Other than adding the option to turn this on/off without -X, I feel like some special care could be taken to draw the "empty room" cells for the map view with more guaranteed contrast when in transparent mode.
Do you feel it would help? We could also pick a specific background for the empty rooms and ensure non-empty ones ar drawn as that background + their colored text foreground.
For example, by having a light background, I noticed the map gets a little hazy and hard to see when in transparent mode.
Do you also feel this could be a problem?
It is expected. I have custom setup to deal with this and it should not be the responsibility of this game to provide a better view in transparent mode. I would highly suggest to not be bothered about it even for a bit. (more on this later)
I really liked your changes in devel branch it is precisely what i wanted.
Now, i am able to multitask while playing this game... :) (not kidding)
map view with more guaranteed contrast when in transparent mode
Do you feel it would help? We could also pick a specific background
background + their colored text foreground
I see you have already considered to improve user experience in transparent mode.
I will simply be selfish and say, i want full transparency and bad user experience. See, my point being i want to be able to see what is in the background as well. (this is the reason to request this feature in the first place)
Now as a user it is my responsibility to decide how much transparent i want this game to be.
If i don't want to see the background i will change the transparency of the terminal running this game to see it better.
EDIT:
Here is a demonstration of me playing helapordo 👍 with different backgrounds
External link to Demo
Alternative link to same Demo
So, full transparency for me personally. I also think users trying transparent feature would expect full transparency rather than visibility.
If you still want to do something, please do it in layers like:
| -X0 | Fully Transparent | No Background/Blur |
|---|---|---|
| -X1 | Partially Transparent | Blur level 1 + No Background |
| -X2 | Partially Transparent | Blur level 2 + No Background |
I want full transparency and bad user experience. See, my point being i want to be able to see what is in the background as well.
My idea was to not use transparency only for the map tiles (in short, the background for all tiles would be solid).
This would be to aid visibility only for those tiles.
Unfortunately, I think this would need some slightly redesign of the palette usage logic, since we would basically need to use special color pairs only for those tiles... A bit of a headache for little profit, at this point in time.
I'd say I'll try to keep it as on/off transparency for now, and probably a few options for different background colors.
If i don't want to see the background i will change the transparency of the terminal running this game to see it better.
That's a valid point. I just felt the need to outline the possibility of having mixed transpared and colored background color pairs, to achieve better, per-color-pair transparency control (the current API may permit this, but the boilerplate needed to add support for the mixed pairs would be better off being offloaded to s4c). I may open a feature issue on s4c for this later, will refer to this one.
If you still want to do something, please do it in layers like:
-X0 Fully Transparent No Background/Blur
-X1 Partially Transparent Blur level 1 + No Background
-X2 Partially Transparent Blur level 2 + No Background
I'm not fully sure what you mean by "blur level", could you clarify? But I think I got the general gist of it. As per the above mention of offloading, I'd say supporting meaningful color configs like this one needs some support code, so I can't really do this granular selection for now.
On a side note, you may have not noticed that -X turns on all experimental features, not just the transparency, hence there would need to be a separate flag for this. Not that it really matters, just saying.
I'm not fully sure what you mean by "blur level", could you clarify? But I think I got the general gist of it. As per the above mention of offloading, I'd say supporting meaningful color configs like this one needs some support code, so I can't really do this granular selection for now.
Blur is a terminal feature (background blur - opposite of transparency). I am controlling this by defining some key bindings supported by my terminal.
Running ./helapordo -X in devel branch worked like a charm for me. As i previously mentioned it is everything i needed. I don't need anything else and this issue can be closed.
On a side note, you may have not noticed that
-Xturns on all experimental features, not just the transparency, hence there would need to be a separate flag for this. Not that it really matters, just saying.
Yes, i missed it. It works for me. I don't mind if it stays this way until this feature is closed.
My idea was to now use transparency only for the map tiles (in short, the background for all tiles would be solid).
This would be to aid visibility only for those tiles.
I don't want any background. But this might be useful for other players/users.
I'd say I'll try to keep it as on/off transparency for now, and probably a few options for different background colors.
I loved last checked state of it (the one i used in demo video above). Please whatever you decide; kindly include some way of me being able to use transparent helapordo. Thank you in advance.
@khushal-banks There's been a few changes on devel, and now there's working prototype of the options interface.
You can see it in the map menu (opens with m), when running with -X and selecting the Options menu item.
Edit: you can now also see it in the first menu. , and just as per above, only when running with -X it will try to give you the prompt.
At the moment the saved options status is:
- updating the
Gamestate - being used to switch runtime behaviour
- being stored between runs
- being constructed from parsing a config file
I got to this point and went thinking:
If we want to "toggle" the transparency, I will have to add a bit of logic wrapping the re-init of color pairs. Not a big deal.- Edit 2: this is now implemented. Took a couple of tries, but it now seems to work as intended to me.
Right now, theGameOptionsinit happens together with the otherGamestate-level inits, but it would be a level "above" if it could be changed from the save selection menu, for example. If the options can be changed before instantiating aGamestate, a bit of logic to pass the selections to the current initialisation will be needed.- This was already changed so that a single static instance of
GameOptionsexists and can be manipulated also before picking a name and class (there's now anOptionsmenu item in the first menu). However, there is still code missing leading to the next points.
- This was already changed so that a single static instance of
Point 2 is going to be achieved pretty soon and without too much effort, just the aforementioned helper routine will be needed and then just refactor to use the options in place of other expressions.
- Update: as an example, do_autosave option influence on runtime behaviour has been implemented.
Point 3 is going to be achieved in not too much time, there's some definitions and helpers still missing.
As of now, all things should be in place for the current settings to persist between runs.
Point 4, as it stands, is unlikely to be shipped in the same patch as the other changes we're lining up. It will probably have to come in a separate patch later.
To expand on Point 3, I'd note that at the moment there's no storage at all of game options selection and any new execution will always start from the same default values.
Soon, there should be a separate savefile just for the options, so that they can be loaded at runtime if they exist (or just fallback to current behaviour is they don't).
Edit:
@khushal-banks
The options store/load between runs was just implemented, but I haven't had much time to test it good.
I happen to test devel branch. This is what happened.
I happen to test devel branch. This is what happened.
I came into this a bunch while testing, but there was a specific terminal setting leading me to this. Can you recreate how this starts out?
Also, please, link to external hosting instead of putting gifs directly in here...
Edit: sometimes I seem to get this too, but I can't pinpoint why. Can you help? It seems to be a "misaligned" state from the binary file. There's a bunch of values holding the status for this flag so it could be going wrong at different points.
Can you recreate how this starts out?
No idea how it started. This was very frequent when it started. Closing the game with Ctrl+c didn't fix it on my machine. (terminal i used for above gif is alacritty)
I closed the terminal and restarted in new one. Everything is working as expected now. So, this is gone for me for now.
Also, please, link to external hosting instead of putting gifs directly in here...
Bro, honestly speaking I thought it was expected to put this tiny gif here. I am really sorry to do this like i had no idea of the consequences. (still don't. But i will google)
I am new to this platform github i will correct such silly mistakes for the time to come.
Thanks for pointing this out.
Bro, honestly speaking I thought it was expected to put this tiny gif here. I am really sorry to do this like i had no idea of the consequences. (still don't. But i will google) I am new to this platform
githubi will correct such silly mistakes for the time to come. Thanks for pointing this out.
I am not sure there's any inherent mistake done here, don't worry. I was just asking because I don't like the auto-preview. But maybe github will still display a preview for outside links, I don't know.
No idea how it started. This was very frequent when it started. Closing the game with
Ctrl+cdidn't fix it on my machine. (terminal i used for above gif isalacritty) I closed the terminal and restarted in new one. Everything is working as expected now. So, this is gone for me for now.
I think it's because the stored flag in the settings binfile was not aligned with the expectations in some way, but haven't really been able to tell it straight. I was able to recreate it by fiddling with the settings but can not do it consistently. I guess it must be releated to what I said but I would need more time to be sure...
I just noticed reset_color_pairs() needs ncurses 6.x, and Ubuntu is still shipping 5.
(Edit: maybe they ship 5 for the dev package only? I have no idea. This seems strange)
Adding this support correctly will need some checks to ensure the missing functionality is handled.
Edit: on closer inspection, it seems that doing
#if NCURSES_VERSION_MAJOR < 6
is not enough to catch problematic builds (since it seems the reported version is above 6.x, but the build fails for this missing support nevertheless).
Doing
#ifndef reset_color_pairsseems to work, but is not ideal.
Edit:
I ended up adding this to the pull release draft, but I would like to better express this in the code too:
- Needs support from your ncurses library for reset_color_pairs(), which is an extension to ncurses. It may be available when building using ncurses's ABI 6.
- Builds missing this support are unable to use this option. If your build is stuck with this option off, you may try to rebuild your ncurses library from source.In any case, this function is an extension to ncurses and it may not be available to all implementations.