Closed AndriyAstakhov closed 7 years ago
Kreso, what do you think? I think it's fine.
Um, guys, I'm not sure this is good. This could cause a thread safety isssue. The manager calls this in another thread (locked by workMutex.)
It's ok if you know what you're doing, but maybe we should leave _update() and make a threadSave update()?
@Boris: don't merge pull requests before we reach an unanimous decision.
It's ok if you know what you're doing, but maybe we should leave _update() and make a threadSave update()?
I think this is good idea to have threadSaveUpdate() function since some of library users (e.g. me :) ) really need possibility to update (or not update) each clip manually based on game logic.
agreed :) But would you prefer to use the threadSafeUpdate() or does your logic rely on directly updating the video clips without the video manager maybe?
Since all calls in my game engine to the library is from one thread (thus avoiding thread safety issue you've mentioned before) I just call GetVideoClip()->update(dt); directly without using Manager.
@kspes Sure, no problem. The merge request's just been out there for a while so I assumed you had nothing against it since you didn't say anything.
VideoClip::_update() function made public and renamed to VideoClip::update(). User should have possibility to update each individual clip manually instead of always be forced to use Manager::update() for all clips at once. VideoClip::update() is used to be in public section until commit 49bf03bc06482e54f1e8ac240bdfa3731f561cbc.