Someone contacted me this morning asking about the Brush Primitives texture format. So since the q2bsp wiki was down, I dug out some very old-fashioned paper notes I'd made a few months ago, dusted them off and turned them into a PDF using LyX. Ah, nothing like TeX for typesetting mathematics.
In other news, we were planning to launch rockets this morning, but there was some sort of pony camp going on in the field we were intending to launch from. So we couldn't.
Although we did successfully build a two-stage rocket last week, we've had to postpone launching it until next weekend. Not only has it been raining on and off for the whole of this weekend, but being unable to find a suitable launch site and the lack of transport didn't get resolved in time. Hopefully our luck will change soon!
After improvising some drinking straws and a few wooden skewers into a 'launch pad', assembling the motors into the rockets and doing some final assembly, we proceeded to launch Mike's rocket, 'Colin 1'. He'd designed his to be very minimalistic: without any sort of recovery mechanism, it consisted of nothing more than a paper tube with fins, a rocket motor and an acrylic plug for the nosecone. Nevertheless, it performed well: on ignition, it went straight up and disappeared. We never saw it again! We think it might have landed in the grounds of Jesus College, judging by the wind. We'd gathered quite a few onlookers by this point, and we think they were quite amused.
The actual launch exposed some shortcomings with my design: firstly, the glue was plenty strong enough to hold my fins on. Unfortunately, the paper I'd made the fuselage out of wasn't! My rocket lost three fins, and thus tumbled out of control after the motor had burnt out rather than following a parabolic trajectory. Secondly, the parachute wasn't attached correctly. Rather than having a piece of elastic from the fuselage to the nosecone, and then a long thread from the nosecone to the parachute, I should have had a long thread attached to a piece of elastic connecting the nosecone to the fuselage, and then a short thread onward to the parachute. As it was, the parachute just sat in the fuselage and melted in the hot gas from the ejection charge, rather than deploying.
Just when I needed still, sunny weather to launch a rocket, the clouds opened: it's been raining more or less non-stop for the whole weekend so far. So I've been stuck indoors playing Red Orchestra and The Ocarina of Time. mupen64 is a great project! Unfortunately it only supports x86 systems, so I've had to run it under Windows (this is probably a good thing, considering that its Direct3D backend seems to work much better than its OpenGL backend on my system).
I spent most of the summer term working quite hard, and it paid off: I got a II.1 in my part IA exams, and I was only 1% off a First! If I hadn't spent so long playing GTA San Andreas when I should have been revising, I might have got that 1%. But Materials is such a boring topic! Also, Half-Life 2: Episode One came out, and that took a fairly major toll on my revision for a couple of days. It's a marvellous game: some of the best character interaction I've seen in any single-player game, as well as awesome graphics, especially the characters' facial animation and texturing.
Anyway, after relaxing during May Week, I went home for a couple of weeks, and spent some time working at DFx Technologies (an electronics firm). I was doing test & repair on their production floor, and it was suprisingly well paid! I learnt a lot about what to do (and what not to do) when debugging faulty electronics -- but several PCBs died to bring me this knowledge. I'm hoping to find similar work here in Cambridge this Christmas vac.
"'Here in Cambridge?' But it's the middle of the long vacation!" I hear you exclaim. Yes, I'm living at Wolfson Court at the moment, and working at the department. Dr Peter Long is paying me to work on gEDA, a suite of Open Source tools for doing electronic design. It's nice to get paid to work on stuff that I'd probably be working on in my spare time anyway! Unfortunately, I'm currently suffering a bit from RSI -- probably my typing technique at fault -- and it's causing a few problems. I've started using Workrave to help me cope with it, and it seems to be helping; I recommend it to anyone suffering from similar problems.
As far as the topic of this post is concerned, I just finished building a small model rocket out of paper, cereal packets, glue and sticky tape, and it looks like it'll work -- once I add the solid rocket motor! The parachute was fun to make, and I was dubious about its chances of working, but some tests involving throwing it up in the air attached to a small weight indicate that it should be okay. We'll launch it tomorrow or Saturday, and see how it performs, and I'll post some photos then.
I found out why the sky wasn't working: it turns out that q2bsp (the new name for qbsp3) gets the flags that tell it if a face is part of the skybox by reading the headers of the texture files. It wasn't able to load the textures, so it couldn't work out that the sky-textured bits were actually sky.
One thing led to another, and I ended up rewriting not only the PAK loader, but just about all the code that messes around with filenames and directories.
A PAK file is basically a linear collapse of a directory tree into a binary object (it's entirely uncompressed) and I believe that the reason for doing it was to avoid the overhead of opening, reading and closing a lot of files. Anyway, in order to find a file such as a texture, the tools need to look in up to four different places, including scanning through PAK files containing thousands of files. I decided that it would be fairly straightforward to get rid of the necessity of scanning for files more than once: the tools now scan through all the places textures could be as they start up, and store the locations of the files in a hashtable, along with the file pointer of the PAK file they're in. So not only do I only read the header of each PAK file once, I only do a full scan once, and after that its just an O(1) lookup to find a file.
Anyway, the upshot of this all is that all the tools now compile and run without errors on Windows/Cygwin and on 64-bit Linux, and even create playable maps! Get the latest release now, and tell me about any problems you find.
Except q2rad, that is, because the default settings of q2rad are rubbish -- they leave the map totally unlit. Oh, for the ability to merge my code with ArghRad...
I think I've finally cracked the maths behind the Brush Primitives format, which is a good start. I've written it up on the buildutils wiki. Now I just need to work out the maths behind the other two formats that I need to support (Classic Quake and QuArK ETP) and all will be well.
I took the time to move the tools over to using GNU getopt to parse command line options -- something I've been meaning to do for a while, because not only is it easier to maintain, but it needs a lot less code: you can see what each of the command-line options do at the code level much more easily now.
I also renamed them: the package is now buildutils-q2bsp and the four tools are q2bsp, q2vis, q2rad and q2bspinfo.
I have, however, just noticed a somewhat worrying problem. When I load a map I've compiled in Quake II, the sky doesn't work; I just see a flat texture. However, when I load one the Quake II game proper (for example), the skybox works just fine. I'll investigate further, but not now because it's the middle of the night...
Well, it's a while since I posted on the subject of compiling maps for Quake II, but I'm pleased to announce that things have started moving again. I was contacted yesterday by whitelynx of the Precursors project, asking what was going on.
Anyway, one thing lead to another, and now there's a Trac site for the project: wiki, subversion repository and bugtracker. I'm very grateful to servegame.org for the hosting (AutoPackage is hosted on the same server, I was suprised to learn). However, the package will continue to be distributed from here.
whitelynx has decided that it would be a good idea to bring lots of different tools "under one roof", so the package is now called "buildutils", with the Quake II compilers called "q2bsp". The new name for the Quake II package is of course inspired by the Quake II build tool, "q3bsp" (which we're trying to get source code for as well). In fact, whitelynx wants to merge in tools for as many different games as possible; I think that's a bit ambitious, so I'm going to watch with interest.
I've made a few small changes in the last few hours; the tools now get linked against libm (which helps), and I've fixed all outstanding compile-time warnings on 64-bit Linux (yay). Lots of stuff to do still, though! I still need to implement Brush Primitives support, for instance...
