-
Notifications
You must be signed in to change notification settings - Fork 399
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
Patch - Introduce mapviewcontrol based on Mehah method #1098
base: master
Are you sure you want to change the base?
Conversation
Better manage of view range
Current OTClient drawFlags solution is left intact
Mehah solution
Mehah solution
Hi, I pushed some minor changes to your PR branch but since the original PR was closed I'll address the concerns that @iryont had here.
As far as I can tell at a quick glance it's only used when resetting and then it's not even updated when AwareRange is changed but as far as I can tell neither is the
This is a fair point, I just tried by doing the following, however there seems to be inconsistent black tile flickering on the edges of the map view when walking: diff --git a/src/client/mapview.cpp b/src/client/mapview.cpp
index 24186244..83425b36 100644
--- a/src/client/mapview.cpp
+++ b/src/client/mapview.cpp
@@ -133,10 +133,6 @@ void MapView::draw(const Rect& rect)
}
g_painter->setColor(Color::white);
- const LocalPlayerPtr player = g_game.getLocalPlayer();
- const bool isWalking = player->isWalking() || player->isPreWalking() || player->isServerWalking();
- const auto& mapViewControl = isWalking ? m_mapViewControl[player->getDirection()] : m_mapViewControl[Otc::InvalidDirection];
-
auto it = m_cachedVisibleTiles.begin();
auto end = m_cachedVisibleTiles.end();
for(int z=m_cachedLastVisibleFloor;z>=m_cachedFirstVisibleFloor;--z) {
@@ -148,9 +144,6 @@ void MapView::draw(const Rect& rect)
else
++it;
- if(!mapViewControl.isValid(tile, cameraPosition))
- continue;
-
if (g_map.isCovered(tilePos, m_cachedFirstVisibleFloor))
tile->draw(transformPositionTo2D(tilePos, cameraPosition), scaleFactor, drawFlags);
else
@@ -322,6 +315,10 @@ void MapView::updateVisibleTilesCache(int start)
if(!cameraPosition.isValid())
return;
+ const LocalPlayerPtr player = g_game.getLocalPlayer();
+ const bool isWalking = player->isWalking() || player->isPreWalking() || player->isServerWalking();
+ const auto& mapViewControl = isWalking ? m_mapViewControl[player->getDirection()] : m_mapViewControl[Otc::InvalidDirection];
+
bool stop = false;
// clear current visible tiles cache
@@ -363,6 +360,8 @@ void MapView::updateVisibleTilesCache(int start)
// skip tiles that are completely behind another tile
if(g_map.isCompletelyCovered(tilePos, m_cachedFirstVisibleFloor))
continue;
+ if(!mapViewControl.isValid(tile, cameraPosition))
+ continue;
m_cachedVisibleTiles.push_back(tile);
}
m_updateTilesPos++;
@@ -412,7 +411,7 @@ void MapView::updateVisibleTilesCache(int start)
Position tilePos = cameraPosition.translated(p.x - m_virtualCenterOffset.x, p.y - m_virtualCenterOffset.y);
tilePos.coveredUp(cameraPosition.z - iz);
if(const TilePtr& tile = g_map.getTile(tilePos)) {
- if(tile->isDrawable())
+ if(tile->isDrawable() && mapViewControl.isValid(tile, cameraPosition))
m_cachedVisibleTiles.push_back(tile);
}
} |
Then we might as well just take the aware range itself and make calculations based on values within it.
The issue here might be with views which do not rely on the same ratio as Tibia does compared to its aware range. The current code assumes that, but we should only rely on the visible range of MapView since tiles beyond that viewport are the ones which need to be discarded. Imagine a scenario where you have zoomed in view, but tiles just beyond the view are still being drawn because the code takes aware range rather than the view range itself.
The cache must be refreshed when the creature begins the walk and after it is done with the walk. |
That seems to have worked but I'm not sure if I missed any places where it should be called. |
@iryont |
@4drik I could, but I honestly don't like this code at all. Personally I believe this repository should be left alone with such questionable "fixes" and only quality PRs should be merged. This is why forks should be used instead, so no one is stopping anyone from using it. Though the idea behind this code is good, the implementation is rather bad. The issue with @diath example is that Anyway, this whole idea can be really simplified and put under So basically with this PR you are breaking more things which will eventually have to fixed by someone in the future. Though using this idea with a proper implementation is a good thing. If I find some time I will gladly create PR with with my own implementation. |
@iryont |
@4drik I am sorry, but I am no longer interested in working on OTC. A lot of things have changed, unfortunately. I don't have time nor willingness to work on it. You are free to do whatever you want at this point. I am out of this repository. |
No description provided.