On Tue, Feb 14, 2012 at 12:27 PM, StyxD <sty...@gmail.com> wrote: > Yeah, it seems mapview-relative coordinates would simplify things a > lot for widgets bound to map objects. I was doing the translation > manually, but with more widgets that would soon become cumbersome. > > It would also solve the problem of widgets going out of sync with the > mapview once and for all. > > I suppose it could be done with a bool variable in manager_child and a > mapview variable in window_manager. I'm not sure what would set the > latter - is changing mapviews managed by schedules?
I could imagine that the window_manager could become responsible for drawing (and updating) the mapview. Maybe handle it as a special kind of window that could be added to the window_manager (since in theory it would be possible to have multiple mapviews). Then any mapview-relative windows would have to be drawn once for each mapview they would be visible in. That would best match the design around the separation of map, renderer and mapview. All information about size and position of a mapview would be available in the window_manager. Mapviews will normally be added from scripts (although right now a single mapview is hardcoded in world::area_manager). I.e. when you start a new game from the main menu, an initial mapview would get generated at the end of an intro script. Saving a game could save (part of) the window_manager state and automatically restore the mapview on loading. Spell or item scripts could open additional, temporary, mapviews (like using a telescope or watching the world through another creature's eyes). But the initial mapview would probably never change once set (unless maybe some cut-scene script would remove it while showing). The map displayed by the mapview could change, however, although right now the idea is to have everything on the same map. Also, with the current implementation, all mapviews would have to display the same map. So maybe mapview-relative windows need to be bound to a specific map or rather mapobject. Since mapobjects know the map they are on, this could be used to decide if a given relative window is relevant for the active map. And should we ever have a 1:1 relation between map and mapview, this would still continue to work. > Also, we'd need to consider, whether the mapview should be optional in > window_manager, so that it would still work in cases when there's no > mapview, like main menu. It would probably mean some kind of exception > should be returned when the user tries to add a mapview-relative > window when the mapview is not set. Or the window_manager would simply skip drawing any mapview-relative window when no mapview is available. That would give us something like the following: window_manager contains a list of mapview windows. window_manager contains a list of mapview-relative windows, bound to a specific mapobject window_manager contains a list of regular windows. Drawing will then first loop over the mapviews. For each mapview it would loop over the mapview-relative windows and draw them, if they are visible in the given view. Finally, after all mapviews and mapview-relative windows are drawn, it loops over the regular windows. That should give exactly the z-order one would expect and keep all the flexibility that was initially planned. (I guess area_manager has somewhat taken away that flexibility, which wasn't really intented.) Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel