-
Notifications
You must be signed in to change notification settings - Fork 103
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
GuiTraceRay from theater ray intersection instead of camera position. #1782
base: master
Are you sure you want to change the base?
Changes from 14 commits
2a0a27e
fab8808
940bc8c
76e69d4
146709b
9d167ce
d89a16d
5773b9b
9850d92
cc626ec
8b8c81e
01c3ef0
b15e68a
0e190f8
3af3c51
ad030ea
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -10,6 +10,7 @@ | |||||||||||||
#include "Sim/Ecs/Registry.h" | ||||||||||||||
#include "Sim/Misc/QuadField.h" | ||||||||||||||
#include "Sim/Units/CommandAI/BuilderCAI.h" | ||||||||||||||
#include "Sim/Units/UnitHandler.h" | ||||||||||||||
#include "System/creg/STL_Set.h" | ||||||||||||||
#include "System/EventHandler.h" | ||||||||||||||
#include "System/TimeProfiler.h" | ||||||||||||||
|
@@ -39,6 +40,7 @@ void CFeatureHandler::Init() { | |||||||||||||
features.resize(MAX_FEATURES, nullptr); | ||||||||||||||
activeFeatureIDs.reserve(MAX_FEATURES); // internal table size must be constant | ||||||||||||||
featureMemPool.reserve(128); | ||||||||||||||
maxFeatureAltitude = readMap->GetCurrMaxHeight(); | ||||||||||||||
|
||||||||||||||
idPool.Clear(); | ||||||||||||||
idPool.Expand(0, MAX_FEATURES); | ||||||||||||||
|
@@ -58,6 +60,7 @@ void CFeatureHandler::Kill() { | |||||||||||||
deletedFeatureIDs.clear(); | ||||||||||||||
features.clear(); | ||||||||||||||
updateFeatures.clear(); | ||||||||||||||
maxFeatureAltitude = std::numeric_limits<float>::lowest(); | ||||||||||||||
} | ||||||||||||||
|
||||||||||||||
|
||||||||||||||
|
@@ -141,6 +144,7 @@ bool CFeatureHandler::AddFeature(CFeature* feature) | |||||||||||||
|
||||||||||||||
InsertActiveFeature(feature); | ||||||||||||||
SetFeatureUpdateable(feature); | ||||||||||||||
MovedFeature(feature); | ||||||||||||||
return true; | ||||||||||||||
} | ||||||||||||||
|
||||||||||||||
|
@@ -186,6 +190,19 @@ CFeature* CFeatureHandler::CreateWreckage(const FeatureLoadParams& cparams) | |||||||||||||
} | ||||||||||||||
|
||||||||||||||
|
||||||||||||||
void CFeatureHandler::RecalculateMaxAltitude() | ||||||||||||||
{ | ||||||||||||||
if (maxFeatureAltitude < std::max(readMap->GetCurrMaxHeight(), unitHandler.MaxUnitAltitude())) | ||||||||||||||
return; | ||||||||||||||
|
||||||||||||||
maxFeatureAltitude = readMap->GetCurrMaxHeight(); | ||||||||||||||
|
||||||||||||||
for (const int featureID: activeFeatureIDs) { | ||||||||||||||
CFeature* f = features[featureID]; | ||||||||||||||
MovedFeature(f); | ||||||||||||||
} | ||||||||||||||
} | ||||||||||||||
|
||||||||||||||
|
||||||||||||||
void CFeatureHandler::Update() | ||||||||||||||
{ | ||||||||||||||
|
@@ -203,6 +220,9 @@ void CFeatureHandler::Update() | |||||||||||||
|
||||||||||||||
updateFeatures.erase(iter, updateFeatures.end()); | ||||||||||||||
} | ||||||||||||||
if ((gs->frameNum & 63) == 0) { | ||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
How about
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shouldn't we also change the check above this for destroyed features for consistency too? Otherwise it feels a bit ad-hoc. I did it like this for internal consistency in the class tbh. Also one concern here is everyone doing checks on frameNum % (n * GAME_SPEED), then all n multipliers of game speed would see perf hit with everyone queueing to do extra work there. So maybe want to add an offset here. Right now all modules choose "slots" quite randomly resulting in random frames with increased load I guess. Ideally maybe everyone should query for free/next update slots with some given period stepping so work is distributed among those, probably neither % or & standalone are really good in the end. Maybe smth like: // example for doing specific slot in 32 (2⁵ frame groups).
static constexpr int PERIOD_STEPPING = 5;
static constexpr int UPDATE_MASK = std::pow(2, PERIOD_STEPPING)-1;
auto slot = engine->getNextSlot(PERIOD_STEPPING);
if ((frameNum+slot) & UPDATE_MASK))
// do work.. I think it could even be improved to sync between different periods. Lua could also use the mechanism, the only issue would be methods who want to do it right now and then with a specific period, but for those probably best would be to actually do it right now somehow, and then conform to the slot assigned by the engine. Right now here, I think the consistency is important so the function uses the same method for both checks. Later maybe a method like above could be used to properly distribute load among processes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Eventually yes. There are many
Sure. I don't mind either way.
Sure. Most of this sort of periodic work is reasonably light though, I'd expect everything just has an offset of 0 but there aren't really spikes every second. Also there may be hidden assumptions so again it would take some care to make sure not to break things (e.g. handler A's periodic update must run right after handler B's and it's not made explicit anywhere, but it sort of happens to work because they just currently have the same offset and period - I remember something like this in resource income stat collection but there may be others).
Lua is a monolith from engine PoV so it is up to Lua to arrange work for individual wupgets, e.g. they could sign up dynamically to the wupgetHandler or use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Indeed, any such rework would have to be done with extreme care to understand everything going on.
Current situation is fragile tho, because there might be such a situation happening and might be hard to notice, and any day someone may change some of the periods but then break any such assumptions, like if we decide to change both periods at featureHandler in this PR. |
||||||||||||||
RecalculateMaxAltitude(); | ||||||||||||||
} | ||||||||||||||
} | ||||||||||||||
|
||||||||||||||
|
||||||||||||||
|
@@ -287,3 +307,9 @@ void CFeatureHandler::TerrainChanged(int x1, int y1, int x2, int y2) | |||||||||||||
} | ||||||||||||||
} | ||||||||||||||
|
||||||||||||||
void CFeatureHandler::MovedFeature(const CFeature* feature) | ||||||||||||||
{ | ||||||||||||||
const CollisionVolume& cv = feature->selectionVolume; | ||||||||||||||
const float top = cv.GetWorldSpacePos(feature).y + cv.GetBoundingRadius(); | ||||||||||||||
maxFeatureAltitude = std::max(top, maxFeatureAltitude); | ||||||||||||||
} |
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.
epscmp
exists, perhaps use that? Maybestd::numerlic_limits<T>::epsilon()
could even become the default for its 3rd arg:spring/rts/System/SpringMath.h
Line 141 in a2dd682