Rogue-Developer.com

It is September again. I'm back at school. I didn't quite realize how much I missed it. The odd, and usually trivial discussions about esoteric subjects, and well intentioned bohemian complaints. It is all in good fun, and harms no one, so what the hell. The oddball teachers and students who more or less make the rest of us feel normal and well adjusted (no matter the truth). What I don't miss is sitting at my computer staring at an assignment I really don't wan t to write (thus this entry). That is never fun.

Okay, Sooner than later I'll be able to lavish attention on you my pretty website. I'm so sorry I neglected you for so long. But I've been busy...

Okay, here is the update, Yes I'm going to Guelph in September, to start my masters computer science. W00t, or whatever the kids are saying these days. I'm excited to get started.

I had my wisdom teeth out. No pain - he didn't put me under. Three teeth, and a root canal in like 45 minutes. The dentist at the Kortright plaza is good.

Work is Work.

Check out Sarah's blog, here.

I figure its about time I added something new here. Since my last post a variety of interesting things have happened. First, my term as a research assistant has come to its natural conclusion, and second I've resumed working construction. Plan is that I'll be working for my father for about a year, until next september, at which point I'll begin graduate studies. I'm looking to start in the masters program at U of Guelph, and look forward to doing some cool stuff there. In the meantime most of my limited spare time is consumed by more mundane pursuits, and I doubt I'll have much time to update here, but I'll try and post semi-regularly.

I'm still, however, continuing research on Hadamard Matrices, and interestingly enough generating result sets that stress filesystem limits. Turns out the C stdlib uses `int` type to store file system position. The solution that is most common on linux/unix systems is the LFS (large file system) standard. The way it operates is quite interesting - thus I'm mentioning it here. Instead of breaking compatibility what the standard proposes is a sort of compile time trickery which is especially convenient. Before including stdio the programmer sets specific defines (or uses gcc's -D switch) the compiler will replace references to the 32-bit functions with 64-bit (or other) functional equivalents. The 64-bit functions are available under different names (prefixed, or postfixed with file size limit iirc), but this bit of compiler trickery means that a simple recompile and a little diligence about using proper typing makes any such problems disappear. I filled up a 150gb hd in no time flat, but rather to my chagrin found that compression reduces the data size by nearly 90%! At last, I'll leave you with this little bash snippet I used to reprocess a compressed file [using an algorithm which I put together based upon knowing the dataset, and gz-compressed on top of that, about say 1gb] to a gz compressed output [without my custom alg, say about 10gb] without creating the very, very large uncompressed intermediate file [100gb]. Witness the power of the pipe!

zcat dbl-compressed.gz | mydecompress | gzip > recompressed.gz

I finished up the SDL joystick code, which was interesting to say the least. Turns out that the various axis motions are simply mapped to button presses - so much for analog controls! There is some interesting stuff - like in unix/unix_main.c we have Sys_MonkeyShouldBeSpanked(). Right now, I've peeled through the unix_main stuff, trying for cross-platform compatibility, but am having some trouble with some console handling code, which behaves oddly. I thought the in-game console was fed by the main event handling loop, but when I close out the unix console functions it just plain stops responding to input. Well, back to the salt mines. Have a good one.

Well, I cheated. BlackAura, at quake3src.org had already written some nice openal code for the engine, so I've integrated that into my own tree. I've move some of the files around and created SConstruct files for most of the utils. The only thing missing (scons wise) is q3radiant - but I don't plan on working on that anyway. GTKradiant has more features and is currently supported for doom3 etc, so I think the work would be wasted. Also I've not yet tried to compile the game code - that might get hairy.

SDL_Input works, both keyboard and mouse. I'm not sure if I'm going to port to sdl_net.. I'll have to take a closer look. Sound is still not working- I don't have any experience in that area, and it looks daunting.

I've rewritten completed the sdl video core - the build no longer requires X11. Input is next on the list.

I've managed to cleanly compile quake 3 with scons! Well, almost... Turns out that the source uses some inline(with cpp) assembly code which gcc-3.4 don't like too much. Luckily, only a single file fouls the build, and replacing those functions with stubs works fine for now - Unfortunately that means losing sound. Not to worry, that code had to be removed anyway. Make way for SDL quake 3.

I've been working my way around the Quake 3 source code which was released just this past week, and trying to clean up the build infrastructure, updating to scons from cons. Before I started looking at the source I had often found myself complaining about the various (and many) shortcomings of the standard config/make cycle. SCons has shown me the light. Like any software system SCons has a variety of quirks that at times make it difficult to work with, but I have very few qualms about dumping the autogen suite of tools. I would recommend them to any project.

My tact at this point is to understand the underlying structure of the codebase, and after I have a clean build running I plan on working on content creation type tools. The first task may take some time - I want to upgrade the code to compile relatively cleanly on gcc 3.4. At the moment the code will only compile on the 2.95 branch, so I can foresee fun times ahead. Another goal is to remove all the assembly language routines- many of the optimizations are no longer needed on modern hardware, and its presence makes porting more difficult than need be.

I was thinking about the last post, and I figured that one point needed more explanation. When I said SVG has the potential to fix many problems this is what I mean:

Imagine a world in which traditional web browsers have been stripped down to simple svg viewers. Given that, all the traditional html elements that are being used today can be implemented as calls to svg elements. In effect, svg is the rendering engine for html- and as long as the browsers SVG viewing capabilities are well defined across browsers and their versions, we can share the layout and drawing api between systems, and also have the added benefits of free versioning (multiple version of the rendering engine can coexist). The beauty of the scheme is that after the relatively short time that the SVG implementations take to become dependable, the coder can focus on *content* rather than chasing implementation specific uglyness.

At this point in time, SVG is being used in the opposite respect, as an embedded element of html. Certainly other technologies are required to complete the package. First I'd like to see EMCAscript replaced - it is one thing to build a clock, or warning dialog, or some similarly prosaic example that really is shallow in terms of implementation semantics. To implement a html rendering engine, there needs to be stronger and more clearly defined language rules. A good first step is compilation/syntax verification - being able to whip up a quick script is not as important as correctness, and compatibility - which EMCAscript gives absolutely no formal methods of checking.