-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix graphical overmap notes displays & mission arrow #50190
Conversation
Pinging @KorGgenT for a review. |
Other menus such as the keybindings menu and note list menu are also quirky when overmap is open. Drawing the note next to the selected tile does look nice, but for other menus to work, the overmap UI code still needs to be fixed.
Refreshing is required when the note editing window is open and the game window is resized. |
I tried invalidating the ui_adapter and forcing a redraw at the end of the SDL draw call: Both cases ended up in an infinite recursion as the ui_adaptor that is being invalidated is the same that does the invalidation. I'll take a closer look at the code and see if it's possible to create a new ui_adaptor to trigger the draw calls for the SDL buffer so it can be added to the stack to control the drawing order. |
Ok, I think I have a proper solution now. I had to flag the overmap ui_adaptor as It's working with any windows I could open from the overmap (keybinds, notes list, create note and so on). I'll do some more testing now with resizing and other interactions. EDIT: Resizing works partially. It works for the overlaid windows but the actual map turns black. I'll see if I can fix it by forcing a draw call from on_resize(). EDIT2: Resizing also causes issues with other windows that only redraw partially but I think it's not as big an issue as the note creation window disappearing while typing the note text. I think the resizing part should be tackled on a different PR. For now this appears to be working fine until the window is resized, and then the problem is just a visual glitch that's easily fixed by closing and reopening the window. The other adaptors might need to be flagged as |
I'll have to flag the keybind window as But before that I'll give creating an exclusive adaptor for the overmap another try. That way I might be able to control better when it should be redrawn. |
I removed the city name drawing code and the keybindings menu seemed to render correctly, so there might be something wrong with city name drawing. I'll look into it. |
Hmm... there is this comment EDIT: Wow, that was it. I don't know what made you suspect the city labels but you were spot-on. Removing the viewport clipping calls is working perfectly for me with all overlay windows. EDIT2: Well, now there is a new problem: NPCs aren't rendered on the overmap. I'll check that out. |
@Qrox Can you repeat your tests after pulling the last commit? I'm trying to reproduce a problem I had where NPCs disappeared from the overmap but I'm not able to. What I noticed is that NPCs are rendered in all Z levels instead of their current level. I'll fix that and if you can't find any other issues I'll consider the redrawing issue fixed and start working on the color tags in map notes. |
I think I know what's wrong here: When drawing the submap terrain, However, that call is missing from the When first opening a menu in the overmap UI, Resetting the clip rect at the end of |
Ok, I added the missing Thanks for the help. |
Co-authored-by: Jianxiang Wang (王健翔) <[email protected]>
I've pushed a PR to your branch to fix some issues with label and note position: GoLoT#1. I'll solve the conflicts later. |
don't know if you know already but while you're at it, the fast travel preview (shift+W) and map search (/) where also not working last i tried. |
Fast travel preview needs to be implemented for the tiles version. Map search is fixed by this PR already. |
Fix city label & note locations
for( const auto &npc : overmap_buffer.get_npcs_near_omt( center, 0 ) ) { | ||
if( !npc->marked_for_death ) { | ||
corner_text.emplace_back( npc->basic_symbol_color(), npc->name ); | ||
if( has_debug_vision || overmap_buffer.seen( center ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this part be moved to a new PR so it can be backported?
You can use |
|
||
const int starting_x = draw_point.x; | ||
|
||
for( auto &line : notes_window_text ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for( auto &line : notes_window_text ) { | |
for( std::pair<nc_color, std::string> &line : notes_window_text ) { |
we generally like to limit our usage of auto.
const int starting_x = draw_point.x; | ||
|
||
for( auto &line : notes_window_text ) { | ||
const auto color_segments = split_by_color( line.second ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const auto color_segments = split_by_color( line.second ); | |
const std::vector<std::string> color_segments = split_by_color( line.second ); |
as here
draw_point.x = starting_x; | ||
|
||
int line_length = 0; | ||
for( auto seg : color_segments ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for( auto seg : color_segments ) { | |
for( std::string seg : color_segments ) { |
and here
geometry->rect( renderer, background_rect, SDL_Color{ 0, 0, 0, 175 } ); | ||
|
||
// Draw colored text segments | ||
for( auto &colored_line : colored_lines ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for( auto &colored_line : colored_lines ) { | |
for( std::pair<nc_color, std::string> &colored_line : colored_lines ) { |
Summary
Bugfixes "Fix graphical overmap notes displays & mission arrow"
Purpose of change
The new graphical overmap is not displaying the notes preview window (top-left corner) and when creating/editing notes it only displays the creation window until a key is pressed, then it disappears (while still taking inputs and working as expected, only without any feedback).
There is also an issue with the mission marker that causes errors when the map Z level is different from the mission target Z level (I think a difference >2).
Describe the solution
This PR fixes the creation note window by preventing refreshing the overmap while the note editing window is open. Previously the draw call order would cause the overmap redraw to draw on top of the window. The window refreshes automatically on keypresses, that's why the window was only displayed right after being opened and before typing anything.EDIT: Previous description was slightly wrong. The issue wasn't the draw order but the sum of two different issues: There were unnecessary calls to
SDL_RenderSetClipRect()
that clipped the viewport causing rendering problems indraw_om()
and on top of that the clipping rectangle wasn't being reset at the end of the function so the clipping bounds were affecting the draw calls for the overlaid windows. Removing the unneeded calls and adding the clipping rectangle reset at the end ofdraw_om()
fixed the issues.A new note text window is now rendered next to the currently selected tile, instead of using the old top-left corner window. This is a very basic display at the moment as I'm not good at designing UIs. Feel free to give any feedback or tweak it.
Then there is the issue of the arrow marker causing errors because of the Z level difference. Fixing the Z level when pathfinding does the trick.
EDIT: Also added fixes to align labels properly to the tile grid (Thanks @Qrox ), enabled display of paths for auto-travel and fixed NPC notes displaying for un-seen NPCs.
Describe alternatives you've considered
Trying to reuse the old corner window for notes. It should be as easy as creating a new window and using the same drawing code at the end of the draw_om() function. I thought that an SDL-based window would look better (if designed properly) so I went with that instead.
Testing