movement
0 views
Skip to first unread message
Mo Morsi
Jan 25, 2014, 1:27:39 PM1/25/14
to Nicolás Satragno, omega...@googlegroups.com
Sending this conversation to list, background from #omegaverse on
IRC [1]:
(11:25:03 AM) Nico95: hi Mo!
(11:30:11 AM) Nico95: oh I love how omega runs much smoother now
(11:33:20 AM) Nico95: Movement seems broken thoguh
(11:33:26 AM) Nico95: *though
(11:35:55 AM) Nico95: Ping me when you're back OK ;)
Sorry missed the ping, was out at Aikido, no practice like Saturday morning practice!
The reason why things are smoother is I shortend the effects player loop interval [2]
Thus more animations are run per second and things looks smoother. Obviously the trade off is a higher strain on your computer's resources, need something w/ a better gfx card myself!
Note we're most likely going to want to change this at some point, eg this wont' suffice during stretches of massive battles and such when the scene will have to continuously animated. But should work for now until we (or someone else) decides to improve.
On the same note I feel the location runner in motel and the command runner in the central Omega module can be looked at. I'm not fully sure (and could be completely wrong) but modifying them to use the central eventmachine [3] reactor might significantly improve performance. Not that it's bad now, but the more that it's improved means the more systems and galaxies we can squeeze in per node.
Essentially right now these mechanisms work through customizable operation loops that will be iterated over at intervals determined by the entities at hand, eg the next invocation of the movement loop will depend on which location is due to move next. Eventmachine is perfect for this sort of thing and since we're using it for RJR [4] anyways it might be a natural fit.
*phew*...went on a bit of a tangent but it's good to get this stuff down. Even though there is alot there the framework should be solid and we can slowely improve on bits as we go along. Every major open source project from Linux to Qt has worked like this and hopefully improving small little aspects in different components will attact a variety of devs.
In any getting back to $topic, I'm curious as to what is b0rked w/ movement, seems to work locally (recorded this video [5] from the latest repo HEAD). We can debug here or on irc.
Take care,
-Mo
[1] http://webchat.freenode.net/?channels=omegaverse
[2] https://github.com/movitto/omega/commit/49e2332d368d14185957fe337ae233f6508c2e8d#diff-1
[3] http://rubyeventmachine.com/
[4] https://github.com/movitto/rjr
[5] https://www.youtube.com/watch?v=hKGr6idoLx4
(11:25:03 AM) Nico95: hi Mo!
(11:30:11 AM) Nico95: oh I love how omega runs much smoother now
(11:33:20 AM) Nico95: Movement seems broken thoguh
(11:33:26 AM) Nico95: *though
(11:35:55 AM) Nico95: Ping me when you're back OK ;)
Sorry missed the ping, was out at Aikido, no practice like Saturday morning practice!
The reason why things are smoother is I shortend the effects player loop interval [2]
Thus more animations are run per second and things looks smoother. Obviously the trade off is a higher strain on your computer's resources, need something w/ a better gfx card myself!
Note we're most likely going to want to change this at some point, eg this wont' suffice during stretches of massive battles and such when the scene will have to continuously animated. But should work for now until we (or someone else) decides to improve.
On the same note I feel the location runner in motel and the command runner in the central Omega module can be looked at. I'm not fully sure (and could be completely wrong) but modifying them to use the central eventmachine [3] reactor might significantly improve performance. Not that it's bad now, but the more that it's improved means the more systems and galaxies we can squeeze in per node.
Essentially right now these mechanisms work through customizable operation loops that will be iterated over at intervals determined by the entities at hand, eg the next invocation of the movement loop will depend on which location is due to move next. Eventmachine is perfect for this sort of thing and since we're using it for RJR [4] anyways it might be a natural fit.
*phew*...went on a bit of a tangent but it's good to get this stuff down. Even though there is alot there the framework should be solid and we can slowely improve on bits as we go along. Every major open source project from Linux to Qt has worked like this and hopefully improving small little aspects in different components will attact a variety of devs.
In any getting back to $topic, I'm curious as to what is b0rked w/ movement, seems to work locally (recorded this video [5] from the latest repo HEAD). We can debug here or on irc.
Take care,
-Mo
[1] http://webchat.freenode.net/?channels=omegaverse
[2] https://github.com/movitto/omega/commit/49e2332d368d14185957fe337ae233f6508c2e8d#diff-1
[3] http://rubyeventmachine.com/
[4] https://github.com/movitto/rjr
[5] https://www.youtube.com/watch?v=hKGr6idoLx4
Nicolas Satragno
Jan 25, 2014, 2:00:39 PM1/25/14
to Mo Morsi, omega...@googlegroups.com
Mo Morsi
Jan 25, 2014, 3:36:45 PM1/25/14
to omega...@googlegroups.com
Noticed it occurs when the ship was
moving then you issued another movement command. Also noticed that
during the movement the ship's coordinates in the entity container
(the container with the 'move', 'dock', 'mine', etc commands)
aren't being updated as they should.
As discussed on irc, I suspect this is due to a client side caching issue where entities are retrieved before the user logs in, then the user logs in but some entity persists / lingers somewhere, causing a weird artifact on gfx updates.
Not 100% sure, could be a server side issue (though most likely the former), need to investigate further.
-Mo
As discussed on irc, I suspect this is due to a client side caching issue where entities are retrieved before the user logs in, then the user logs in but some entity persists / lingers somewhere, causing a weird artifact on gfx updates.
Not 100% sure, could be a server side issue (though most likely the former), need to investigate further.
-Mo
On 01/25/2014 02:00 PM, Nicolas Satragno wrote:
Mo Morsi
Jan 26, 2014, 8:22:36 AM1/26/14
to omega...@googlegroups.com
On 01/25/2014 01:27 PM, Mo Morsi wrote:
Recorded this video [5] from the latest repo HEAD). We can debug here or on irc.
[5] https://www.youtube.com/watch?v=hKGr6idoLx4
Just sharing another video I threw together, this time around docking ships & transferring resources:
https://www.youtube.com/watch?v=TtP4tUfspfc
All in all these videos are really simple to throw together. See this for a quick howto on Linux:
http://blog.omegaverse.info/posts/simulation-videos.html
-Mo
Reply all
Reply to author
Forward
0 new messages