1
SFML projects / Re: SFNUL
« on: April 10, 2014, 02:21:53 am »
So ive implemented this library for a prototype to test the features i need to making a working solution for my game.
At the moment i see a problem when try to remove a synchronized object that is not the last object that was pushed to the list. Its not working proper.
There is no way to use pointers for the synchronizer, so i have to carry around values.
When using _synchronizerServer.CreateObject<Entity>();
Also, the copy constructor will be called 2 times. With a pointer it shouldnt be such a cost problem.
But the main problem is that Synchroned Objects are values which i get over the CreateObject-Method where i cant really make a reference from, beside the list where the synchronized objects stored.
The memory allocation is changing automaticly when objects are removed form the STL containers, i guess.
I cant see how the STL container-classes manage the allocation of memory, but i see that something is wrong when i try to make something like:
So when i try to use entityA later, after i removed some other objects out of the _entities-list, it will shows that the reference is not valid anymore.
I think without modifying the synchronizer it wont work. I need pointers. Interrupt me, when im wrong, but is see no other way for the problem.
So ive manipulated the synchronizer.inl file like this and use now _synchronizerServer->CreateObject2<Entity>()
And now it works for me like it should.
I see two architecture hurdles,
A) Synchronization of sub-syncObjects of a syncObject.
B) Different views. At the moment i see that all syncObjects are there for synchronize all clients with the same objects, but why should objects be synchronized with clients/players where the object is currently dont visible. So i need more than one synchronizer (for each client (player)) that only synchronize the visible objects for a client.
So at the end it cant be solved in the way that the synchronizer handles the creation of the SyncObjects like it do with the CreateObject-Method.
With this way there is for each synchronizer a represenation of a SyncObject on Server-Side. So i have to remove the CreateObject-Method and give the synchronizer directly the SyncObject to make it possible to share the syncObject with all synchronizer (for each client) on the server.
At the moment i see a problem when try to remove a synchronized object that is not the last object that was pushed to the list. Its not working proper.
There is no way to use pointers for the synchronizer, so i have to carry around values.
When using _synchronizerServer.CreateObject<Entity>();
Also, the copy constructor will be called 2 times. With a pointer it shouldnt be such a cost problem.
But the main problem is that Synchroned Objects are values which i get over the CreateObject-Method where i cant really make a reference from, beside the list where the synchronized objects stored.
The memory allocation is changing automaticly when objects are removed form the STL containers, i guess.
I cant see how the STL container-classes manage the allocation of memory, but i see that something is wrong when i try to make something like:
_entities.push_back(_synchronizerServer->CreateObject<Entity>());
Entity& entityA = _entities.back();
Entity& entityA = _entities.back();
So when i try to use entityA later, after i removed some other objects out of the _entities-list, it will shows that the reference is not valid anymore.
I think without modifying the synchronizer it wont work. I need pointers. Interrupt me, when im wrong, but is see no other way for the problem.
So ive manipulated the synchronizer.inl file like this and use now _synchronizerServer->CreateObject2<Entity>()
template<typename T, typename... Args>
T* SynchronizerServer::CreateObject2(Args&&... args) {
T* object = new T(std::forward<Args>(args)...);
object->SetSynchronizer(this);
return object;
}
T* SynchronizerServer::CreateObject2(Args&&... args) {
T* object = new T(std::forward<Args>(args)...);
object->SetSynchronizer(this);
return object;
}
And now it works for me like it should.
I see two architecture hurdles,
A) Synchronization of sub-syncObjects of a syncObject.
B) Different views. At the moment i see that all syncObjects are there for synchronize all clients with the same objects, but why should objects be synchronized with clients/players where the object is currently dont visible. So i need more than one synchronizer (for each client (player)) that only synchronize the visible objects for a client.
So at the end it cant be solved in the way that the synchronizer handles the creation of the SyncObjects like it do with the CreateObject-Method.
With this way there is for each synchronizer a represenation of a SyncObject on Server-Side. So i have to remove the CreateObject-Method and give the synchronizer directly the SyncObject to make it possible to share the syncObject with all synchronizer (for each client) on the server.