Week 19/2013: Scripted Info
Last week I was working on the UI framework.
As requested, I removed the arbitary fixed upper limit on the number of submodels that a model can have. The submodel limit was one of those things where the influence of the original C language implementation shows: the cost of implementing a dynamic array for the submodels in C was too high, so the submodels remained in a simple fixed-size array. However, now that we have switched to C++, it was rather a straightforward matter to replace the arrays with suitable dynamic ones, removing the limit on submodels.
As I was considering the options for defining the UI style used by the engine (comprising such things as fonts, colors, images, and lengths), I came to the conclusion that some work toward DED 2.0 was needed. The plan is for the UI style to be a resource package containing all the information and files. However, the existing DED parser is too inflexible for adding completely new definitions for this purpose.
Some time ago, the declarative Snowberry Info parser was ported from the launcher's Python implementation to libdeng2. This was a good starting point for DED 2.0. A crucial requirement for DED 2.0 is that the definitions should be fully compatible with Doomsday Script, the new scripting language of Doomsday 2. Thus I proceeded to write a combination of Doomsday Script and Info that is analogous to having snippets of JavaScript embedded in an XML document.
(If you are wondering why aren't we just using standard technologies like JavaScript and XML, the answer is that having been designed for a different domain, their syntax would be cumbersome for use in Doomsday, and integrating them fully into the engine would not be as elegant as with our own custom-designed components; also, creating a scripting language of my own has long been something I'm passionate about.)
In its current from, ScriptedInfo cannot yet fully address all the needs of DED 2.0, but it provides a solid foundation for future work and allows me much flexibility for defining the parameters of the UI style. On the whole, I am excited about the possibilities scripting will allow when used as part of the definitions. It is nice to see the libdeng2-based subsystems starting to integrate deeper into the engine.
While I was working on ScriptedInfo, I also fixed a number of bugs in the Doomsday Script implementation and added some useful features like the eval() function that takes any piece of text and executes it as a script — very useful for dynamic scripting.
My plan for this week is to continue work on new GUI widgets for the client.
As requested, I removed the arbitary fixed upper limit on the number of submodels that a model can have. The submodel limit was one of those things where the influence of the original C language implementation shows: the cost of implementing a dynamic array for the submodels in C was too high, so the submodels remained in a simple fixed-size array. However, now that we have switched to C++, it was rather a straightforward matter to replace the arrays with suitable dynamic ones, removing the limit on submodels.
As I was considering the options for defining the UI style used by the engine (comprising such things as fonts, colors, images, and lengths), I came to the conclusion that some work toward DED 2.0 was needed. The plan is for the UI style to be a resource package containing all the information and files. However, the existing DED parser is too inflexible for adding completely new definitions for this purpose.
Some time ago, the declarative Snowberry Info parser was ported from the launcher's Python implementation to libdeng2. This was a good starting point for DED 2.0. A crucial requirement for DED 2.0 is that the definitions should be fully compatible with Doomsday Script, the new scripting language of Doomsday 2. Thus I proceeded to write a combination of Doomsday Script and Info that is analogous to having snippets of JavaScript embedded in an XML document.
(If you are wondering why aren't we just using standard technologies like JavaScript and XML, the answer is that having been designed for a different domain, their syntax would be cumbersome for use in Doomsday, and integrating them fully into the engine would not be as elegant as with our own custom-designed components; also, creating a scripting language of my own has long been something I'm passionate about.)
In its current from, ScriptedInfo cannot yet fully address all the needs of DED 2.0, but it provides a solid foundation for future work and allows me much flexibility for defining the parameters of the UI style. On the whole, I am excited about the possibilities scripting will allow when used as part of the definitions. It is nice to see the libdeng2-based subsystems starting to integrate deeper into the engine.
While I was working on ScriptedInfo, I also fixed a number of bugs in the Doomsday Script implementation and added some useful features like the eval() function that takes any piece of text and executes it as a script — very useful for dynamic scripting.
My plan for this week is to continue work on new GUI widgets for the client.
Comments
It turned out I had considerably less time available for Doomsday than I had expected at the start of the week. So while there has been some significant progress, the map geometry generation is still somewhat entangled with the map renderer.
Much of the geometry generation logic within the map renderer has now been consolidated into a handful of utility routines. What was somewhat surprising is the extent at which this logic had become interwoven into the logic of the map renderer itself. Over the course of the week the focus of this work progressively expanded to reimplementation. The more logic I consolidated the more bugs and/or doom.exe software renderer incompatibilities I discovered (many of which have since been resolved, btw).
Prompted by these discoveries I decided to spend some quality time analysing the exact behavior of Chocolate Doom's renderer. Although I had a pretty good working knowledge of the mechanics of the DOOM map renderer, I thought it best to crystallize this mental model before going further.
I plan to spend this week continuing to revise the map geometry generation.