Effekseer #3283
Effekseer #3283
Conversation
| void CCore::DestroyEffekseer() | ||
| { | ||
| WriteDebugEvent("CCore::DestroyEffekseer"); | ||
| if (m_pEffekseer) |
|
|
||
| private: | ||
| CClientManager* m_pManager; | ||
| std::list<CClientEffekseerEffect*> m_List; |
There was a problem hiding this comment.
std::vector would be more efficient here. You can use swap-and-pop idiom to remove elements with O(1).
|
|
||
| void CEffekseerManager::Remove(CEffekseerEffect* effect) | ||
| { | ||
| delete static_cast<CEffekseerEffectImpl*>(effect); |
There was a problem hiding this comment.
Isn't it better to make a destructor virtual and avoid the cast?
|
|
||
| CClientEffekseerEffectHandler* CClientEffekseerEffect::Play(const CVector& pos) | ||
| { | ||
| auto handle = m_pEffect->Play(pos); |
There was a problem hiding this comment.
handle can be potentially invalid
| SetTypeName("effekseer-effect"); | ||
|
|
||
| m_pManager = pManager; | ||
| m_pEffect = nullptr; |
There was a problem hiding this comment.
m_pEffect can be nulled in the member initializer list(or even better as a default member value).
| // Effect will be removed here | ||
| m_pInterface->StopEffect(m_Handle); | ||
| // Free handler too | ||
| delete this; |
There was a problem hiding this comment.
Can we avoid this self destruction?
|
This is only concept @tederis . PR isn't ready for review. Сode quality is very low at this point and things don't work correctly. |
Oh, those are just comments. I'm just giving you insights(I hope). |
| @@ -71,3 +76,68 @@ float CEffekseerEffectHandlerImpl::GetDynamicInput(int32_t index) | |||
| { | |||
| return m_pInterface->GetDynamicInput(m_Handle, index); | |||
| } | |||
|
|
|||
| void CEffekseerEffectHandlerImpl::SetRandomSeed(int32_t seed) | |||
There was a problem hiding this comment.
Is there a reason for creating a whole interface over effekseer?
I guess it's so than effekseer can be a dll, but I don't think there's any benefit from that.
There was a problem hiding this comment.
Is there a reason for creating a whole interface over effekseer?
This is an adapter between MTA types and Effekseer types.
- Main integration part is under one project.
- From an architecture perspective that makes future vendor updates much easier.
- Effekseer namespaces brings an additional mess in MTA projects.
- Dependency on interfaces is better than on implementation.
I guess it's so than effekseer can be a dll, but I don't think there's any benefit from that.
I use dynamic linking for Effekseer over static because i need that Interface in both Client Core and Client Deathmatch projects. I can be heavily wrong, but that cause compiled code duplication in this projects with static linking. I saw this two years ago, when i was truing to compile Effekseer first time. I didn't remember all details.
I would prefer to link Effekseer with Client core project, when i can. I don't know if this is possible yet.
|
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically. |
|
Any update on this? |
Effekseer is a particle effect editing tool. It can be added to have rich effects in MTA. Effekseer includes material editor and effect editor.
Demo with free samples: https://youtu.be/Qk2xIfkzEfw
Pros:
Cons:
Current state:
Notes: