I have set up the basic building blocks for native packaging within Doomsday 2.
The guiding principles for this design are maximal utilization of existing functionality — FS2,
Record and Doomsday Script — and keeping everything simple yet flexible. Continue reading Packaging fundamentals
While working towards the next-gen 3D model renderer, I now have a more detailed step-by-step plan for moving forward. Continue reading Planning ahead
I’ve had little mental bandwidth for Doomsday recently. This is not unexpected during the weeks leading up to the summer vacation. Looking at the calendar, there is still time until the end of July to wrap up any new code for 1.15. This should be enough for putting together a basic package loading mechanism and set up a simple model pacakge.
Continue reading Schedule wrt. model rendering
Doomsday Script (DS) is the Doomsday 2 scripting language, built right into the core of the engine. Its syntax is heavily Python-inspired, however with a somewhat smaller set of language features. Recently I’ve been improving DS with future needs in mind.
Continue reading Progress with Doomsday Script
Xcode is growing on me. Especially Xcode 6 on Yosemite is looking fantastic. Qt Creator is a very capable editor, however I plan to make another effort to write a generator script for a “native” Doomsday Xcode project. A sensible goal would be to produce a Snowberry-free build using Qt 5.3.
It has been a busy week without much time for Doomsday. Sometimes after a break it is easier to return to the project by looking at a completely different topic than what I was working on before. This allows one to ease into the code again in a more comfortable way.
The log history widget was among the first that I wrote on the new UI framework. Since then, I’ve added a handy utility class called
TextDrawable for drawing and laying out UI text. It has nice features like automatic background threading if there is a large amount of text. However,
LogWidget being quite old, I had implemented a separate multithreaded text rendering mechanism there. I decided to replace this with
TextDrawable so there wouldn’t be unnecessary redundancy in the code base.
Continue reading Detour into scripting and log history
My next step is to devise the actual format of a next-gen (model) package. I am not going to worry about backwards compatibility at this stage, and instead think of a clean-room ideal solution. Existing packages need to be handled separately, or perhaps automatically imported/converted to the new format and rules.
Continue reading About next-gen resource packaging
After updating all code that deals with DED Model definitions to use the new
Record based storage, I was slightly disappointed — although not surprised — to see that loading up a resource pack and trying to use it would result in a crash.
This is a pattern that I’ve come to accept as the norm: after working on a set of significant changes, my initial design and plan are shown to be valid, but I have to spend a couple of hours tracking down bugs that, in the end, prove to be trivial. In other words, one can’t expect to write bug free code.
Continue reading A tale of model definition bug hunting
While working on the
Record based definitions, I noticed that there is a clear redundancy in the
get*() methods: they pop up in
Config, and now I also needed them in a utility class that manipulates model definition data stored in a
The solution was to add a new class called
RecordAccessor that contains nothing but these
get*() methods. This new class can then be inherited into any other class that benefits from providing native access to a
RecordAccessor is currently specific to
Record instances, it could still be generalized into an
IAccessor class that queries values from an abstract source where values are addressed using paths — this would make it possible to use it also with
Speaking of mobile Doomsday, having played around with Qt 5.3 on iOS and Android, I now have a bit more concrete picture of what Doomsday will look like as a mobile build.
Supporting mobile platforms is something I think is very much necessary for the future. I see desktop computing becoming more of a niche thing, as most people’s needs will be met by various forms of phones and tablets. Still, DOOM was born in the age of desktop PC gaming and Doomsday will naturally respect this; not only will we continue to develop the project on desktop (or laptop) computers, that is the environment the game was originally designed for.
Continue reading Mobile Doomsday