Oops - too far

The hiding spot behind the couch for Maki is too far away from the router. A file server with no networking is a little dumb. Going to keep it on the desk for now, then move it into a thrift-store nightstand/drawers thing.

I also discovered that closing the Toshiba puts it into some hardware-specific standby not through Windows. Right after I started a shutdown last night, I closed it thinking it would just finish while closed. When I opened it this morning, it promptly woke up, then finished the shut down :P

A modern computer and the legacy of the toaster box.

For the first time in a long time, I have a somewhere near modern computer. A Toshiba M700, it features such amenities such as a processor over 1GHz, full DirectX 9c compatibility, and an 84-key keyboard. Less ironically advanced is the 2GB of RAM and the dual active/passive digitizer screen, which allows use of a wacom pen and finger touch and is able to switch between the two rather seamlessly. With this power at my fingertips (hurr hurr touchscreen joke), I've decided to make the laptop my primary computer.

Which brings us to the long-standing champion of Casa del Del: the toaster box, Maki. An early model Shuttle, Maki is not much bigger than your average toaster, unlike today's "small form factor" PCs which are 25-50% bigger. She runs a 1.1 Ghz Athlon and has a massive 512 MB of RAM. Her Radeon 9500 PRO was the top gpu of 2002, but does not have the now standard feature of a hot CG chick on the side. Previous host to two versions of Windows and long-time top OS Gentoo Linux, the toaster-box computer would live on as a file server.

Last time I installed Debian, it was a confusing install, thanks to a noticable lack of documentation. Emulating its younger sibling Ubuntu, the current Debian install is smooth, automated, and fairly clear. I found it kind of anticlimactic when I finished installing it on the toaster. Good thing I unwisely selected the "Desktop Environment" package that adds a myriad of bloaty gnome junk: gave me the opportunity to at least reinstall. My life, including an archive of over 27000 spam emails, fit on 11 DVDs and was copied over to my home folder with only 1 file lost to sketchy linux disc burning (though I had to copy one disc over the network from my new computer thanks to sketchy linux disc reading). Samba is set up and serving out data. Maki's new home is behind the couch, leaving me with a desk with way too much open space on it.

In other news, Qix project's on hold for now. I didn't get too far on the project originally. VS2008 came out and I'm using it at work extensively; there's a lot of great new stuff in it this time around. Unfortunately, XNA is not supported in 2008 - you can hack it in, but you lose a lot of functionality. I'm not going to bother with XNA again until I can use it with '08. Currently looking at Java & OpenGL to get my jollies.

Oh yah: I'm not doing tech support anymore!

Tattered notebooks of code

Things are fairly slow on the home front and I find it hard to get into projects as I used to. I have fit some time in for some "paper programming", though.

I've pretty much figured out all the geometric algorithms for the Qix game. The current plan is to do it using the new XNA framework with a 3d object as a "cover" and actually picking away at it to reveal what's underneath. The cover's just a rectangle right now, but in the future, I'd like to extend it be raised somewhat to hint at what's being covered (like a vague mountain shape if the picture is a mountain).

I've also started paperwork on my accounting program. In deciding what to do with the data access-side of things I've discovered the wonderful world of "Dynamic Sql vs. Stored Procedures". I like the idea of having a direct mapping of programming object to business object and making the data layer invisible, but I also appreciate the incredible usefulness of stored procedures and that you have to acknowledge a database layer at some point. I think I'm going to end up creating some sort of hybrid thing that uses stored procedures then translates it into business objects. Or I'll just stop at typed datasets, I dunno yet.

In both cases, my programming is going to be picking up. I've bought a used laptop that I've designated "the Windows(tm) machine". A lot of my not-programming-ness stems from having to reboot out of linux just to get to Visual Studio. Now I just have to shift 30 degrees to the left and there's Windows. It's also not powerful enough to run the latest games, so that'll be no distraction. Unfortunately all I play on my computer is Eve and Defcon anyway.

Qix and the art of computational geometry

It's been a long time since an update, but for good reason. I've returned to my old nemesis for employment: residential internet tech support. The strain and variation of computer-scheduled shifts has left me tired and scrambling to find time for my own personal development. Machines don't understand that ending a shift at midnight then starting again at 8am - while legal - is not exactly good for the staff.

I persist, however. Every-so-often, my mind drifts back to my old friend, Qix. I once asked on an internet forum if changing to vectors for my drawing would be a good idea. Vectorised edges would simplify collision detection against them and ease calculating appropriate bounce-off of player and monster sprites. Naturally I was told the math was too complicated for the application. I accepted this advice for a while until I remembered that I'm the guy who wants to make a game with voxels, so I looked into it again.

Qix is a rather special thing as the way the game works produces special cases that greatly simplify the math involved. The first case is the merging of two polygons. To merge two polygons, we take the vertices in winding order and follow along adding each vertice to a seperate "completed" polygon. Anytime we get to a place where the two polygons intersect, we switch to the other polygon and continue. In Qix, we are given the intersections without needing to check for them at all; we start drawing on part of the original polyogon and stop the moment we intersect with it again.

My big hurdle right now is determining the winding order of the drawn polygon. Since thhis polygon is created by the player, the game has no control over whether the vertices are created in clockwise or counter-clockwise order (the player can move in either way he chooses). This, however is another special case to Qix. The "inside" of the drawing polygon is determined by the location of the Qix itself. As a result, the Qix determines the winding order of the newly drawn polygon. My only thought for this is to create two polygons and check against both: one polygon merged to the already finished area with the new draw vertices in one order and a second which is the same, only with the new draw vertices reversed. I'd like to find a more elegant solution, but I can't think of one.

The only thing to do would be to code it all up and try it. The nice thing is that it's all math with little in the way of graphics (yay vectors) and I can code it in whatever I please. Internets said I couldn't do it. I'll show them. I'll show them all!.

P.S. I've removed the sandbox. No one ever looked at it anyway.

New project started: basic accounting

As part of my effort to become more familliar with .NET 2, I'm starting a project that encapsulates everything I want to learn. The idea is to make a simple accounting program to track my finances and allow better budgeting.

The main idea on this one is to develop a good data access layer that allows me to put the data in any format I want. This way, I can try out using SQL Server, XML access, web services, etc. The bonus - as always - is that I can use the program myself later :)