Skip to content
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

refactor: Reduce/remove entity pointers as means of addressing entities #1406

Closed
wants to merge 91 commits into from

Conversation

jadebenn
Copy link
Collaborator

Working toward an object ID system instead. Entity pointers should not be assumed to be constant, as it would be useful to have the capability to move their locations in memory.

@jadebenn
Copy link
Collaborator Author

jadebenn commented Jan 10, 2024

Managed to get components no longer storing an entity pointer as a member. There is no nice way to say it: This is going to be a major pain when it comes to editing the function calls themselves.

* @param objectId Object ID
* @param entityPtr Entity pointer
*/
void AddEntity(const LWOOBJID objectId, Entity* entityPtr) { m_Entities.insert_or_assign(objectId, entityPtr); };
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im not sure how much of a fan I am of exposing this API as it implies anyone and thing can add an entity when in reality every single entity must go through create entity first.

Copy link
Collaborator

@EmosewaMC EmosewaMC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a request it would be preferred to see a perf impact of before and after the change in real world and stress scenarios

@@ -50,5 +50,5 @@ class Component
/**
* The entity that owns this component
*/
Entity* m_Parent;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being changed? I had thought the agreement was to move this to a ref instead of an objectID

void GameMessages::SendPlayFXEffect(Entity* entity, int32_t effectID, const std::u16string& effectType, const std::string& name, LWOOBJID secondary, float priority, float scale, bool serialize) {
SendPlayFXEffect(entity->GetObjectID(), effectID, effectType, name, secondary, priority, scale, serialize);
}

void GameMessages::SendPlayFXEffect(const LWOOBJID& entity, int32_t effectID, const std::u16string& effectType, const std::string& name, LWOOBJID secondary, float priority, float scale, bool serialize) {
void GameMessages::SendPlayFXEffect(const LWOOBJID entityId, const int32_t effectId, const std::u16string& effectType, const std::string& name, const LWOOBJID secondary, const float priority, const float scale, const bool serialize) {
Copy link
Collaborator

@EmosewaMC EmosewaMC Jan 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LWOOBJID should be passed by ref as it generally doesn't fit into a register is faster to pass anything larger than 4 bytes by reference than to copy it

@EmosewaMC
Copy link
Collaborator

There are a lot of miscelaneous changes in this PR afte doing a quick scan of it, could this be split into some more focussed ones instead to make the review process easier?

@jadebenn
Copy link
Collaborator Author

jadebenn commented Dec 14, 2024

I might revisit this, but if so, it won't be with this branch. Closing.

@jadebenn jadebenn closed this Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants