Sebastian\’s Coding Blog

Archive for the ‘Sofu’ Category

Candydoc, Sofud progress

Posted by randomz on March 22, 2007

The usual DDOC outputs aren’t very pretty or attractive. Plain black text in the default size and the default font, with no means to navigate between the files. However, the DDOC system leaves much room for extending, as demonstrated by Candydoc, which gives the documentation files a nice formatting, and a package navigation tree.

I applied Candydoc to the Sofud documentation, and I am very pleased with the results, which I have uploaded for your viewing pleasure. Keep in mind that the docs are a work in progress, though I did write a lot of docs recently.

To use Candydoc, I had to introduce a custom build script that renames the files appropriately (because Candydoc wants the HTML files to be in the same directory, which is different from DMD’s default). I also modified Candydoc to work with my modified file name format (Package.Module.html). All in all, it wasn’t much work for the results (long live open source).

I started my first steps towards implementing a feature that I have been to lazy to do for a couple of versions: Preserving comments and indentions. Up until now, when a loaded and modified file was being written back to disk, all of this was lost (the indentations and new lines were created anew by the saving code). Today, I only started writing the classes (and extending the stumps I had left in the code earlier on), so no effects are to be seen yet. It still remains to modify the lexer (to not simply throw away white space) and of course the saving code.

I’m concerning myself with cosmetical changes now: That means that most parts of Sofud 0.3 are in place and working well. After finishing this, I want to perform some interface cleanup and optimization of the inner workings of the library. Most importantly, I want to enable the user to specify a default encoding to save strings in, and probably also cache strings that have been converted to other encodings, to reduce conversion overhead.

And since I’m aiming this to be a “complete” release of Sofud and I’m not planning to introduce any revolutionary features after this, I’m currently considering to renaming the release “0.3” to “1.0”.

Posted in Sofu | Leave a Comment »

No future for references

Posted by randomz on February 26, 2007

I have been hesitant the whole time whether the concept of references could contribute to Sofu. And I have come to the conclusion that for the purposes of Sofu, the costs of adding references outweigh the benefits.

What are the costs? References add a whole new layer of complexity to any Sofu file that uses them. A Sofu file can now be semantically incorrect; before, the semantics of a Sofu file where solely defined by the library user.

What are the benefits? In my opinion, they are pretty small. It is always possible to refer to a Sofu object by using its name. Of course, in this case, you are limited to referring to objects inside a certain application-defined Sofu structure (as opposed to somewhere inside the file); on the plus side, this structure can even be in a different Sofu file, which would be a security risk to allow with references. And if you really want it, you can still build complete reference paths by creating lists of strings and numbers. (You have to do the dereferencing yourself, though.)

All the mechanics for dereferencing reference paths that I have already implemented inside Sofud will probably stay. For example, it is very useful to have a reference path inside an error message (instead of just line and column number). The whole ReferencePath class (source) will probably also be part of the public interface, also probably a rarely used part.

Posted in Sofu | Leave a Comment »

touch Sofud

Posted by randomz on December 28, 2006

I picked up Sofud development again today, after a 4-month break. Actually, I just looked at the source code and tried to remember what I was trying to accomplish… but from a glimpse, it looked like there might not be too much coding work until feature completion of 0.3. But since I’m trying to make 0.3 a “real” release, I’ll also have to clean up code, write code documentation, and write something entirely novel: A complete user’s manual. I’m also thinking of writing a Sofu file editor as an example application, because I’d really like to have one… plus it would be the best imaginable test for the library.

Add to that the fact that I’ll be very occupied over the next few days and the busy second half of the semester after that, and you know that Sofud 0.3 will be released about the time you finish playing Duke Nukem Forever.

Posted in Sofu | Leave a Comment »

Heightmap and further plans

Posted by randomz on October 12, 2006

I got together with Maluku last weekend and we coded a nice, smoothly textured and lit heightmap implementation. Check out his blog post (complete with a pretty cool video demonstration).

I’m also halfway through implementing Quake 3 (.md3) model loading… but there’s no telling how long this is gonna take me. However, once we have both heightmap and model rendering in place, we will have a good platform to start realizing our long-planned game by the name of Crystal Shards.

Meanwhile, Sofu development has somewhat stalled. I can’t promise that I’ll release something this year. University is starting next week and is going to make me terribly busy, as it always does.

Posted in Crystal Shards, Sofu | Leave a Comment »

GUI? Heightmap? Where to start…

Posted by randomz on July 23, 2006

I spent a nice time with the internals of the evilness engine today. Actually, I was looking to code a small heightmap test scene, similar to what I did before, but in a more general way and better integrated with the engine. Well, I basically ended up changing a couple of things in the engine here and there…

By far the most tedious change to make was that I came to think that the Vec2d class should instead be a struct. It’s really small – only consisting of two doubles – and is instantiated dozens of times each frame. So allocating (and garbage collecting) all those small objects on the heap has probably burnt some processor cycles. Of course, this optimization is pretty much against the book, because I didn’t profile or anything to verify that I get better results after the optimization. I’m a rogue coder after all… =)

I really like D’s new import mechanics. Saying “import Vec2d : Vec2d = Vec2d;” finally has allowed me to avoid qualifying Vec2d’s module whenever I’m calling a member function. Since I tend to name my classes the same as the containing modules (which would be considered good style by most people anyway), I’ve been waiting for something like this for a while. (Of course, I could have just aliased, but I was kind of too lazy for that ^^)

I also realized that I should start to whip up a little GUI system for the evilness engine to ease creating scenes (and eliminate the need for the horrible ReadScene in many places). This is gonna be quite a lot of work, even if I restrict myself noly to the really necessary classes at first, but I don’t really see a premade GUI kit that does what I want – it would have to be written in C or D and use OpenGL.

In the process of working on evilness, I also discovered two bugs in Sofud, one of which I believe to have fixed already, but seem to have lost that change… and of course, I ended up immediately making a new Sofud release after fixing the first bug, so I actually made two Sofud releases today. I updated the web site, too – I’m really proud of myself.

Posted in D, Sofu, the Evilness engine | Leave a Comment »

D enums != type safety

Posted by randomz on June 28, 2006

I’ll post here the last post from my old coding blog, since I just wrote it a couple of minutes ago:

Copy & Paste struck on me again, as it often does. I had written a function to take a Sofu.Encoding.Encoding enum value (which is one of the possible Unicode encodings) and return the endianness that will be used by that encoding, as an Endian enum value.
However, I had pasted this from code that used std.stream’s BOM enum type. So, I had written:

switch(encoding) {
  case BOM.UTF16LE: case BOM.UTF32LE: return Endian.LittleEndian;
  [...]

Of course, I should have written

switch(encoding) {
  case Encoding.UTF16LE: case Encoding.UTF32LE: return Endian.LittleEndian;

This actually caused little and big endian to be exactly reversed.

I guess this is a serious downside of having the enums be actual int variables. The compiler wasn’t able to see that I was comparing an Encoding enum value to a BOM enum value.

Oh, and BTW, the SDL_mixer bug has been fixed and I was able to check the new DLLs into the Evilness SVN. 🙂
(Not that anything has changed over the old version…)

Posted in D, Sofu, the Evilness engine | Leave a Comment »