Week 41/2013: Trackers and Raspberry Pi

edited 2013 Oct 15 in Developers
Before embarking on anything rendering-related, I felt there was a need to do some project infrastructure improvements. As you know, we presently use SourceForge for our bug tracking and feature requests. However, due to SourceForge's massive scale, the trackers are slow and cumbersome to use. Also, their web UI could use several improvements. Therefore, some months ago we decided to start looking for an alternative. We've now settled on Redmine, and last week I installed it for our internal testing. After we've finished setting things up, we're hoping this will prove to be a significant improvement, and also allow us to manage the Roadmap inside the same tracker.

The ultimate goal is to have Redmine running here on dengine.net, however until we've resolved a couple of technical problems, we are running it on a private server. The last major hurdle is to import all the existing (and closed) bugs and feature requests from the SourceForge trackers. These are quite an important piece of the historical record of the project.

Another little side project during last week was related to Raspberry Pi. At the moment, most of our graphics code is incompatible with OpenGL ES 2.0, so unfortunately it isn't possible to run a Doomsday client on Raspberry Pi. However, after a few fixes I did manage to get the Doomsday server running on this little Linux machine. Going forward, Raspberry Pi will be a very interesting development platform for our longer term mobile aspirations, as it is easy to run custom stuff on it, and the graphics API is the same as on iOS and Android.

My plan for the immediate future is to finish setting up the new bug/feature tracker and import all the old tickets into it.

Comments

  • Last week I began work on revising the map API ahead of more fundamental architectural changes coming in the shift to unified networking and the new world renderer.

    My main area of focus this week was to begin to tackle some of the architectural legacies, involving how the games traverse and manipulate map elements/objects. There are also some outstanding performance issues which need to be addressed now before we start building up a new renderer.

    Architecturally speaking, we've now largely outgrown the current property-centric approach to map updates. In the future we need to be moving the abstraction level higher. Rather than manipulating individual map element properties directly, such as the height of a plane, the engine should provide an API comprised of components that effect logical changes, like animating the movement of a plane without direct manipulation from the game.

    There are however some significant hurdles to overcome. Not the least of which being the games' less than stellar organization of map traversal and update logics. The main offender being the AI code, which, reminds one of a bowl of spaghetti. This is what I'm currently working on. In particular, untangling the usage of global state variables in the object and plane movement logics. I expect I'll continue working on this until such time that the wood becomes distinct enough from the trees (if you'll pardon my mixing of metaphors).
  • I'm looking forward to hosting an aussie server on my raspberry pi
Sign In or Register to comment.