The Pedigree Project Dev Blog: Matthew Iselin

Pedigree's 'pup' package manager

2011-10-10T16:19:00.003+10:00

Recently there's been a lot of activity in the project repositories related to the 'pup' package manager.

I've been working at getting our binaries and other ported application-related files out of each repository and move towards only having the specific binaries we need for building Pedigree from scratch, and the remainder being source code and tools.

So now a checkout of Pedigree and an Easy Build run will leave you with quite a bare build of Pedigree - you'll get bash, coreutils, and not too much else. This allows you to choose what goes into your build of Pedigree; if you just want Python and Lynx for web browsing, that's totally alright with us.

'pup' is written in Python and will be available to run in Pedigree as well as on the build machine. At the moment however our Python build is a little broken as we are working on bringing proper shared library support to our userspace ports.

In my opinion there's no reason for everybody to download over 250 MB just to get a simple checkout of Pedigree. That's what 'pup' integration is all about.

Minecraft: Fix for Error (4): null

2011-10-10T16:11:00.003+10:00

Been having this issue on and off for a while now, but finally nailed the source of the problem today. I run Minecraft behind a Squid 2.7 proxy, which appears to have trouble handling ETags properly.

In particular, it seems to have to do with the If-Match-None header.

Upgraded to Squid 3.0 and I'm able to update Minecraft without using a browser - awesome! :)

And now for something COMPLETELY different!

2011-06-01T10:25:00.000+10:00

I know this is technically a Pedigree devblog, but I also do sysadmin work and this might be handy for someone else out there.

In a Windows network environment, folder redirection comes in handy for things such as server-side My Documents and such. We use folder redirection for the Desktop and Start Menu as well, to provide a set of icons to each user that we can manage centrally.

However, it turns out Folder Redirection can't always redirect to a mapped network drive (ie, M:). The order of GPO processing means the drive mapping takes place later on, after the folder redirection takes place. So if you've mapped a bunch of network drives for the user and want to redirect to one, without using a UNC path, it won't work. This doesn't work for us as we map some drives to different locations based on the computer's organisational unit.

So the fix comes from Group Policy Preferences: all that "Folder Redirection" does is set a few registry keys. Group Policy Preferences lets us set those registry keys manually, with the added bonus of the extremely powerful granular targeting (Item-Level targeting). The targeting lets us apply different registry keys to Admin users instead of Teachers, for example.

The relevant keys for the Desktop and Start Menu are:

All Users - common across every user logged into the machine
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Keys: Common Programs ("All Programs"), Common Start Menu (Icons outside of "All Programs"), Common Startup ("Startup" folder), Common Desktop (the desktop).

Individual Users
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Keys: Desktop, Start Menu, Startup, Programs - all the same purpose as above.

So, by setting a combination of these keys, we were able to get the desktop and start menu completely redirected to a network share that's unique per organisational unit. This means modifying the icons for a room involves a simple copy & paste on the file share rather than rebooting a computer for the startup script to take effect.

Live Streaming some code!

2011-05-15T19:07:00.000+10:00

I've set up a Justin.tv channel to which I can stream live coding and debugging of issues in Pedigree and other projects. I gave it a go this afternoon with about an hour's worth of playing around with Pedigree's memset, and I hope to regularly stream new stuff - there's certainly enough to do, after all!

Package Management & Workflow

2011-02-03T17:16:00.001+10:00

For those who don't know, one of my "mini-projects" (of which there are many!) on the Pedigree project is the 'pup' package manager. The idea behind pup is to create a Python-oriented package manager that works great on Pedigree but can also be used for any other operating system that happens to have Python ported. Essentially all of the backend is just standard HTTP GET requests, the packages are just .tar.gz files, and building a package is dead simple (assuming the environment is okay).

The problem with 'pup' is that it current works out of a git repository which holds every package that will be in a master repository. This is great for editing the build scripts and versioning the pup source code, but when it comes to any form of management it's a nightmare. The solution for this is to write a web-based user interface for managing a package repository.

That's where it gets exciting.

Actually managing packages in their built state is very, very easy. You simply modify the SQLite database containing package information where necessary, and move the package files around. The difficulty comes from building and creating packages. The easiest way to convince users to port more software to Pedigree is to make it extremely easy to - this is the goal of pup and the build scripts in our Pedigree-Apps repository. So any web interface for management has to handle both managing existing packages (update/remove/rename/edit attributes) as well as handle bringing new packages into the system.

The workflow I came up with in my head for this is as follows:

User creates a build.sh and related scripts to build the relevant port. This is hopefully tested by the user and works on that system. Creating these scripts is already documented.
These scripts are uploaded to the web interface
The permissions of the user are checked; depending on these the package will be automatically built on the server straight away, or added to a queue for moderation (we'll assume it was permitted to be built here).
As the build continues, its status is made available to the user.
Once the build completes, the user is notified of the status of the build. Most likely an IRC bot is also present to notify developers/interested parties of the build status.
The package is added to the system and mirrored from the master repository to various other mirrors, ready for users to download the update/new package via pup on their Pedigree installation.

Here's the problem - as far as I can tell nothing like this exists.

So I'm looking at writing this myself, most likely in Python. It should be a fun project for when all the other projects are hitting dead ends, and has the added bonus of reducing my workload on Pedigree when done!

As an aside, notable changes since the last blog post:

We released a feature-test release - Foster Milestone #1.
SSE in the kernel, oh my! memset takes this very well, memcpy not so much due to floating point state issues. These are being resolved at the moment.
A variety of changes across the POSIX subsystem and within the network stack for improved stability.

Also, We're looking for anyone who's got a few year's worth of OS development under their belt to come on board and work on the project - if you feel like something new and a C++ kernel doesn't worry you, find us in #pedigree on Freenode IRC.

Updates! Pedigree-Apps and POSIX stuff.

2010-11-25T08:58:00.000+10:00

Over the past couple of months I've been working less on Pedigree as a whole and working on less intensive projects, such as playing video games, or writing small userspace applications. There is nothing that sorts out early burnout symptoms faster than taking a short break - and that means getting away from low-level programming completely! So progress is definitely slowing down, but that doesn't mean things aren't getting done.

As for the "Pedigree Team." Eduard (eddyb) has now started high school and so has a lot less time to contribute to Pedigree. He's still got a fair few ideas flying through his mind though and that's always a good thing. Can't deny it - since he first showed up in our IRC channel his behaviour (not to mention his English) has improved significantly. Just have to hope that doesn't go to his head ;-).

I still consider Pedigree a unique project: proof of what can happen when a group of mostly like-minded individuals come together and use their combined skillset to make something really significant. It's a shame people like James and Joerg have left us, but this is just the way things work. I don't know about Joerg, but James has certainly used Pedigree as a springboard into some pretty amazing work with his Horizon project.

Enough talk about logistics and teamwork though! Let's talk about code.

The first and foremost thing I really want to talk about is the "Pedigree-Apps" repository. This was set up a while back as a place for all of our ported packages to sit, and as a staging point for a master package repository for whichever package manager we ended up using.

History lesson time! We initially started using "pacman", Arch Linux's package manager. It's a nice piece of software, and does the job very well. The dependencies it asks for are not quite as nice (especially libdownload, which is essentially impossible to find) however. It also doesn't lend itself well necessarily to cross-compiling packages.

So recently I put together a new piece of software called "pup" - "Package Updater for Pedigree." It takes a path to a directory containing a Pedigree-style tree of directories that it tarballs and compresses and adds to a package repository somewhere. The databases used on both the server (for synchronising local "available package" lists) and on the client side ("installed packages") are nice and simple sqlite databases that Python has modules to read out of the box. Oh yes, that's right - pup is completely written in Python. Why write pup in Python? The answer is simple: Python is already a Pedigree build dependency. You have to have Python to build Pedigree.

In the future the main Pedigree repository will ship with a copy of pup ready to run, and instead of distributing hundreds of megabytes worth of binary files for a hard disk image, anyone who builds Pedigree will be allowed to choose which packages to add to their hard disk image. This will hopefully improve the size of source snapshots and shallow clones, and also make it easier to customise a hard disk image to a specific testcase.

As for Pedigree-Apps itself, it now has a shiny build system that caters directly to both cross-compiling and automated builds. Package maintainers just provide patches and a set of scripts (for each phase of the build - prebuild, configuration, build, install, and for packages which provide libraries that future package builds might depend on, a script to set up library links for the cross-compiler) and the rest falls into place. Compared to the old system, this is much easier for package maintainers and also significantly reduces the total size of the repository, which is fantastic for those with slower internet connections.

Now that all that is aside, I have a quick few things to add about a few changes that have gone through the POSIX subsystem. And by quick, I mean bullet points! Yay!

Brand new pthread locks

I got fairly sick of having every pthread lock function call into the kernel, and it seriously hammered performance. So I spent a few hours rewriting both the spinlock and mutex functions to use atomic operations all the way out in userspace, only calling into the kernel to put a thread to sleep or wake a thread up. The resulting performance boost is significant: a few mutex tests that I ran as a benchmark averaged a completion time very close to that of Linux. Obviously it's hard to truly benchmark such an OS-specific thing, but I think that if a VM is hitting speeds close to that of Linux for a similar construct, I've done pretty well.

Rework of statfs/statvfs

Only one of these functions is actually standardised - statvfs. The other is not. So I've removed statfs completely and stuck with statvfs, and so far nothing has complained. I'm yet to actually implement either of these functions, but I finally have a method of enumerating mounted filesystems in the VFS making an implementation of these functions fairly simple.

Condition variables

I'm hesitant to put this here because I really don't like the implementation I wrote, but I'll do it anyway. Condition variables of the pthread variety are now implemented. Badly. There is very little in the way of atomicity, and they end up being two mutexes tied together that are locked and unlocked unatomically. It's pretty nasty all up. Eventually I'll just rewrite these functions to use their own specific implementation without building upon the existing mutex implementation, but that will probably only really come when this implementation causes a bug.

All up there's a lot still going on with Pedigree. Most tasks are now becoming longer subprojects - this is just a part of building such a massive piece of software and is to be expected.

We're looking at possibly doing a "milestone" release in a month or two just to get our current code out into the wild (which does well for finding both bugs and feature requests). Stay tuned!

New Core Features

2010-05-09T11:20:00.000+10:00

It's been a long time since I posted anything here. Moving to a new city has slowed my development down significantly, but things are getting back to normal again.

Recently there has been a fair bit of activity, and I'll summarise what's been going on in this post. There's a couple new features, some changes to Pedigree itself, and some bug fixes. In-depth discussion of each, where necessary, follows the list.

ZombieQueue (commit d5314bf7)
Using > 4 GB of RAM now works, with the x86_64 port (commit bb6b954b)
MemoryPool (commit 64454975)
UdpLogger (versatile log callbacks) (commit ff5fddba)

ZombieQueue

ZombieQueue solves a problem that has been lying around for quite some time. Things such as signals require that a Process object is deleted as part of it being killed, so it is no longer schedulable. However, this was dealt with originally by a "delete this;" line. Any form of "delete this" can be dangerous when the next line is not a return statement. Even when the next line is a return statement, a reschedule out of the current context and into another, which allocates memory, may overwrite the existing object... making "this" invalid. That said, it did suffice for quite some time.

The idea of ZombieQueue is that you queue these deletions, allowing the thread to be rescheduled (or the call that needs deletion to return) and the object to be deleted at a later time, when it's safe to do so. Eventually ZombieQueue might also have a "delay" parameter, which ensures that it never deletes an object until after a specific time period has passed. This could easily be used for things such as TIME_WAIT handling in the TCP stack.

ZombieQueue has already been implemented into Process, Pipe, and Socket, all of which needed to delete themselves somehow. Now they call into ZombieQueue, which is able to safely delete the object.

x86_64 port using > 4 GB of RAM

A TODO all through the physical memory manager for quite some time has been to handle regions above 4 GB in the x86_64 port. Until this change was made, no ranges of memory above 4 GB were actually accessible. In fact, using the x86_64 port on a system with over 4 GB of memory actually caused anything from a panic to a triple fault and reboot.

This has been rectified now. I'm still not sure it'll handle a full 64-bit physical address space yet, but it will handle a massive amount of memory nonetheless.

MemoryPool

This one is something I'm surprised hasn't been implemented yet. The idea of MemoryPool is to take buffer allocation out of the kernel heap, where it consumes far too much memory - and sometimes even consumed the full size of the heap.

MemoryPool takes a block of memory, outside of the heap, and splits it up into buffers of a specified size. These buffers are distributed to modules and applications where necessary, and returned to the pool when they are no longer needed. Buffers in, for example, the network stack, are around 2048 bytes (rounded up to the next power of 2 from 1500). Rather than have every incoming packet cause an allocation on the kernel heap of, on average, 800 bytes, this moves the processing into a pool of memory dedicated to the job.

A key feature to MemoryPool is its blocking nature. If an allocation cannot be satisfied by the current pool of memory (ie, all buffers are allocated out), it will block until a buffer becomes available. Compared to the heap, this means a constant memory usage is enforced. Effectively, the pool provides a strict contract on its memory consumption: a pool will never resize to fit a new allocation.

This does bring up a minor problem: some code can't block - an interrupt handler for example. For this situation, a non-blocking allocation method is available, which merely returns NULL if no buffers are available.

UdpLogger

It has long been possible to install custom Log callbacks which take log entries and write them to a destination. Callbacks that already exist include the Serial logger, and a callback is used for the loading screen log dump. For testing on real machines, however, neither of these suffice. None of my test machines have a serial port, for example. They are all networked via Ethernet, however.

UdpLogger is able to be installed after the route table is installed, so it's only really useful for debugging if you can actually boot to a shell on the test machine. It dumps all log entries to a given IP address and port. A test machine can then dump all its debugging output to a development machine running netcat.

Here it is, in action:

Log::installCallback has now also been updated to dump all the old log entries to the new callback, so every logging destination should have the same data once they are all installed.

These are just a couple of exciting new features and fixes that have happened in the past couple of weeks. At this stage we have not planned a second release - we're still working through the bugs from Foster and finally getting around to fixing all those TODOs scattered in the code.

At the moment git master is being kept "stable" - that is, it builds and runs to the bash shell (apart from x86_64) - so feel free to grab the latest code and have a play!

Pedigree's "Services" Feature

2009-09-02T12:39:00.011+10:00

Well, the Pedigree team is currently in bug fixing mode as we prepare for our first release, codenamed "Foster" and as such, there's not been a lot to talk about innovation-wise in the kernel. So I've decided instead to chat about a feature of the kernel, which was implemented recently.

For our "live CDs" we realised we would need a read/write file system, in memory, with a set of applications and files to allow people to try Pedigree out without making changes to their computers. This meant that we needed a way to mount a disk image as a usable disk, which is a feature we lacked at that stage in Pedigree. So I spent a couple of hours whipping up a module to support such a feature. However, this module required a couple of tricky design decisions: Cache, and write support.

Cache is a must-have in such a module, as without it each read from the disk image ends up in a read to its parent hardware - not so great if a slow CD drive needs to seek! However, the cache must also be big enough to hold at least one sector of disk data (preferably more). I eventually settled upon a 4096-byte buffer cache, which holds two full CD sectors, and eight hard disk sectors. Initial reads will miss the cache and read straight from the hardware into the cache. Further reads come from that buffer in cache. For an image formatted as FAT, for example, this improves read times from the file allocation table and root directory (high-use areas) significantly.

Writing to the virtual disk makes things slightly more complicated. I decided upon an implementation, which gave the option for the virtual disk to be write-through, or totally in RAM. These options need a bit of explanation. A write-through virtual disk will place writes into cache, and write to the real disk image itself. This is an ideal setup for something like Linux-style loopback disks. However, consider the "live CD" situation: we can't write back to a CD! So the second option writes only into the cache without affecting the original file. This means all changes are kept as long as the system is running, and do not persist. Implementing these two write options generalised the module - a massive bonus.

However, all is not well at this stage. A module to provide a disk is one part of the battle. At this stage, all we have is an abstraction of a disk - no partitions, no file systems - it's useless for normal usage. At the time of implementation, Pedigree had no way to dynamically detect and mount such disks. This simply cannot do for a modern operating system where storage devices are hardly static - USB mass storage devices come and go, hot-pluggable hard disks exist, and so on.

I didn't want to have my loopback disk module talk directly to the partition driver though. Exposing the internals of the partitioner to other modules makes changing the partitioner’s interface awfully complicated, and creates an explicit dependency on a specific module.

I decided instead to implement what I call Pedigree’s service manager. This kernel feature sits between different parts of the operating system and provides a standardised interface to other modules. Each service provides the following types of functionality (at the time of writing):

Write: Send data to the module
Read: Read data from the module
Touch: Inform the module of new state
Probe: Probe the module for a specific state or piece of information

Each service decides which features it provides, so it is possible for a service to provide only read as a function. The service manager takes these potential features and provides a generic interface for drivers and modules to talk to named services. In effect, this idea of services is a method of inter-process communication using named destinations. Therefore, with this new service manager, I was able to modify the partitioner to add support for the touch service. There is no need for a partitioner to support read, write, or probe, as the only notification to be sent to the partitioner is to inform it of a new disk.

With a quick modification to the loopback disk code, I was able to inform the partitioner of the presence of the new disk with error handling and no direct partitioner-specific functionality used:

// Chat to the partition service and let it pick up that we're around now
ServiceFeatures *pFeatures = ServiceManager::instance().enumerateOperations(String("partition"));
Service         *pService  = ServiceManager::instance().getService(String("partition"));
NOTICE("Asking if the partition provider supports touch");
if(pFeatures->provides(ServiceFeatures::touch))
{
NOTICE("It does, attempting to inform the partitioner of our presence...");
if(pService)
{
if(pService->serve(ServiceFeatures::touch, reinterpret_cast(this), sizeof(FileDisk)))
NOTICE("Successful.");
else
ERROR("Failed.");
}
else
ERROR("FileDisk: Couldn't tell the partition service about the new disk presence");
}
else
ERROR("FileDisk: Partition service doesn't appear to support touch");

This feature has already been added to other areas of the kernel (mainly talking to the partitioner), but has the potential to even be expanded to call applications that the user runs. This means it would be theoretically possible to replace the partitioner at runtime, or replace a component of the network stack to provide a different level of service. That means that Pedigree can be modular and flexible, even though it uses the conventionally rigid “monolithic kernel” design. Now that’s something to write home about!

NOTE: Blogger simply will not let that code sample work without wrapping it (it looks right in the preview and text editor). You should be able to get the idea that I'm trying to convey though.

Pedigree Progress

2009-06-13T12:17:00.004+10:00

When I last posted I chatted a bit about CDs and the Pedigree installer. Since then, I have successfully written a driver, and that means Pedigree now installs off a CD without a hitch. Naturally, there's still bugs and minor things that need fixing (such as creating a default user!), but it's at least mostly complete.

Since then though, we've been refactoring the POSIX subsystem a fair bit. Rather than have a lot of POSIX-specific functionality at the kernel level, I've developed a Subsystem abstraction that sits between the kernel and the individual subsystems (POSIX, native, DOS, etc...). As a result of this new abstraction the POSIX subsystem has been significantly changed - it's now far neater, and a lot of sneaky bugs have been fixed.

The biggest test of Pedigree itself so far has been our brand new Apache port. Through attempting to run Apache (over and over again) I've found some pretty big bugs, as well as a fair few incorrectly implemented functions. At the moment I'm working on file locking in order to allow Apache to actually serve a document.

This file locking concept introduces some serious design choices. One of the biggest is whether to implement it generically, and have it available to the kernel, or implement it specifically for the POSIX subsystem. Both have their pros and cons.

Generic Kernel-Wide Interface

Pros:

Global - can be accessed and used anywhere in the kernel
Cleaner - no subsystem-specific code, #defines, or functions makes the final interface cleaner
Can wrap around already-existing objects

Cons:

Potentially very slow - locks on ranges of bytes need to be checked on every file operation, as the subsystem doesn't control the lock (subsystems would be able to decide better which file operations to lock)
May end up biased towards one subsystem rather than being truly generic

Subsystem-Specific Interface

Pros:

Keeps a complicated, and potentially very subsystem-specific, interface out of the kernel
Faster as it can use the subsystem's structures and functions when needed

Cons:

A real pain to implement - requires changing every file-based operation in the subsystem to use the proper locking mechanism, rather than just replacing the file object
Code duplication for locking in other subsystems

Two very plausible interfaces - each with equally valid pros and cons. However, the final decision is made based on the point Code duplication for locking in other subsystems. Why should such a generic concept as file locking be duplicated based on a different subsystem?

There is a compromise to be made here though. Note that I have mentioned the generic interface has a serious problem: "Potentially very slow - locks on ranges of bytes need to be checked on every file operation". This means that on every read, every write, the range of bytes being affected must be checked against every lock that the file has active. In the case of multiple shared locks, this is an O(n) search.

A simple solution exists. Whereas it is a definite deviation from the POSIX definition of a file lock, removing the ability to lock individual ranges of bytes and instead lock the entire file allows housekeeping in the kernel to be kept to a minimum - the lock can be kept as a simple Mutex rather than a list of locked ranges - and only slightly affects runtime speed.

I consider this an appropriate compromise to make, as I believe it is ineffective to lock small regions of files (and I expect that the majority of file locks in POSIX applications are made for the entire file). I also feel that implementing the ranges of bytes properly is merely an introduction of more POSIX functionality into the kernel, which is something we're trying to avoid.

EDIT:

The use of a generic interface means it's also possible to distinguish advisory and mandatory locking in the same object without requiring major changes. For instance, adding advisory locking with the generic interface to the POSIX subsystem was a 10 minute job, as it only involved editing the FileDescriptor object and (naturally) fcntl. In this implementation, mandatory locking is just an additional function call in file I/O functions, rather than multiple calls and checks per function.

The Plot Thickens (and the trail lengthens)

2009-05-11T18:50:00.004+10:00

I started work on the Pedigree installer scripts recently, and whilst now I have an extremely powerful Python + ncurses installer script (copies files from a to b with installer pages and destination selection, with MD5 verification of installed files) I have realised that Pedigree isn't quite ready for it yet.

You see, for all of our testing we've been booting the kernel off a floppy disk with an initrd and using the hard disk to store all of our files (applications, config, etc). However, that approach doesn't quite work so well when we don't actually have a Pedigree-ready system state.

So I sat down and whipped up some ISO generation scripts, which means we now have Pedigree installer CDs. However, we don't have any method to read CD disks in Pedigree yet. What started as a simple concept (Python installer) has now developed into developing drivers for the CD drive and the on-disk filesystem format.

There's nothing wrong with that, of course, but it is slightly frustrating to not be able to jump straight into testing my installation scripts on Pedigree. If you're really interested, you can check out the progress of the installation side of Pedigree.

For all those excited about the concept of a Python + ncurses installer (highly customisable too :) ), you can see the most up-to-date scripts here. Keep in mind Pedigree has some unique requirements, and I haven't documented anything at the time of posting, so you're totally on your own if you do try them out.

More Updates!

2009-05-07T15:45:00.002+10:00

My 3C90X emulation for QEMU works - and by works I mean I tried multiple guest operating systems and they all connected to the internet correctly via my emulation.

You can patch your QEMU 0.10.3 source tree with the patches at http://lists.gnu.org/archive/html/qemu-devel/2009-05/msg00205.html to enable the emulation.

And in Pedigree-related news, I've started work on a basic installer system which uses Python to copy the files to the disk. This will let me create a quick and easy install method which is highly customisable.

The installer will be under Pedigree's license and should be portable enough to apply in numerous other environments.

Something Unusual...

2009-05-01T00:14:00.003+10:00

A lot has happened since I last posted here. I've dropped Mattise and rejoined the Pedigree project (http://code.google.com/p/pedigree).

The Pedigree project has allowed me to do some pretty crazy things - writing all sorts of code including a fully functional TCP/IP implementation.

And that's what's brought me back here.

I've got a few 3Com 3C90x NICs lying around the place here, and I thought it'd be nice to write a driver for them so I could test out Pedigree on some of the boxes I have around the house. However, I struck a problem very quickly - no emulator for x86 has a 3Com card emulated!

A quick Google search showed me that PearPC had an emulation of one, but because it's a PPC emulator it wasn't useful to me (our PPC port is still a bit behind, unfortunately). PearPC's emulation is licensed under the GPLv2, as is QEMU's (our emulator of choice). So I thought it'd be fun to port it across.

The first hurdle was that PearPC was in C++ and QEMU in C, and their entire interface to the virtual state was different. After an hour or two I'd fixed that up. However, I ran into a slight problem - the emulation was incomplete. So for the past day and a half I've been reading the specification for the card and updating my emulation code, while also updating my own driver.

So I've been working on a driver for (and an emulation of) this NIC, which has been a huge challenge and all up, a lot of fun!

It's an amazing feeling when you successfully create and close your first TCP connection. You can imagine how much more incredible it is when you watch "lynx" (the text-based browser) running through your NIC driver, controlling your emulated NIC, do a full request and print the page.

I will be submitting the 3C90x emulation as soon as it's more complete, cleaned up a bit, and most importantly - tested!

The iPhone

2008-10-15T14:49:00.001+10:00

I'm writing this from my brand new iPhone. So far the experience has been totally positive. Setup was seamless and it's quite easy to use.

If you have the cash I highly recommend it - it's definitely worth the money.

Google Chrome

2008-09-07T20:20:00.005+10:00

Google entered the fray with nothing more than a simple search engine - but it revolutionised the way we think of the internet. Since then, the company has grown exponentially. With the onset of Gmail - a revolution in online email - Picassa, Google Earth, Google Maps, among many other products, Google is a household name.

One of the biggest advantages to Google's products is that every single one is free - their advertising schemes provide enough revenue to allow them to release everything for free.

And so, the newest entry in the world of Google betas is their browser - Google Chrome. You can check out the Google blog entry here, and if you just can't wait you can grab it here.

I could bore you all with all the technological workings, but I won't - just know that it's fast, secure, and so far I haven't been able to fault it. It's far better than Firefox or IE (or ) in my opinion. It's even open source - so the entire development open source community has free access to it as a base for future projcts.

Check it out if you haven't already.

Foot Photos Continued!

2008-06-09T14:09:00.002+10:00

Yes, that's right. I'm keeping the tradition with yet another photo of my feet at an unusual place. I went ice skating on Saturday, and so I figured I'd get another foot photo in:

This could be an interesting idea to look back on in 10 years time...

Mattise Progress (and blog updates)

2008-05-18T13:50:00.002+10:00

Well, it's been a while since I talked about Mattise here, and although I'm not sure exactly how many people follow its development I think it helps me as much as it helps everyone else to know exactly what's going on...

The current working copy of Mattise (ie, Mattise 3.0) has the following features:

Powerful bitmap-based page allocator
Simple kernel heap allocator (possibly changed to dlmalloc in the future)
Paging support, with reference counting for mappings
ELF binary support (loading modules, which are basically object files, and linked binaries)
Rudimentary VFS (currently just performs replacement based on a prefix/device binding, soon will replace the old device manager)
Device manager (soon to be replaced with VFS)
ATA driver (hard drive I/O)
Console driver (/dev/tty basically, though no terminal compatibility at all yet)
FAT32 support (no other FATs though)
Tiny bash-like shell
Functional newlib port
Runs NASM, binutils

The last point is what I'm most proud of.

Also, to avoid making multiple entries within the space of such a short amount of time, I'm going to mention some new things that I'll be bringing into this blog:

More personal stuff (photos, anecdotes, etc...)
Updates on projects
Informational articles
(Rarely) A discussion about some concept (eg, "Gaming: Pick up and Play or The Epic?")

Enjoy!

Thailand/Laos Trip: Foot Photos!

2008-05-17T18:24:00.009+10:00

In my not-so-recent-anymore Thailand/Laos trip, I had a thing where I took photos of my feet at different places. It's about time I actually put these up somewhere, so here they are!

This is outside a temple, if I remember correctly:

This isn't really a foot shot per se, but it looks cool.

This here is at the Plain of Jars (Site 1) in Laos.

This is at a bus station in Thailand, just before a long and tedious 12 hour bus trip. I dunno why we sat around waiting, because it would've been smarter to use up all of our energy and then get on the bus and sleep away the hours...

This is in Chiang Mai International Airport (who knows, you might stand on this exact spot one day...) waiting for our flight (in the checkin area though).

Next overseas trip I do I'll make it a goal to get a shot of my feet in all situations I'm in, so I can continue this idea.

By the way, I did actually remove those shoes during the trip - they just happened to be more comfortable than my pluggers every single day.

A final foot shot...

None of those are my feet, but it goes to show what motorbiking in rural areas can do to your feet.

Seagate's External Hard Drives

2008-05-17T18:00:00.004+10:00

I recently purchased a Seagate FreeAgent Desktop (500 GB) to store my music, disk images, and video editing scratch data. It was fast enough (even over USB) to suit my needs, and I was extremely happy with it - and it even looks stylish in comparison to some of the "bricks" you can get these days. I was a very happy customer.

Until Wednesday.

Turns out I've now experienced something a lot of other FreeAgent Desktop owners have experienced - the drive simply doesn't get recognized anymore. This of course causes no end of frustration as I have a couple of hours of video I can't ever get back (that's *extremely* important), several disk images for different operating systems (multiple Linux distributions), and my entire music library stored on a now unaccessible drive.

Every troubleshooter I've done points to internal failure, and at the moment I'm pretty sure the internal controller is fried or something. I've seen many people put up pictures showing how to pull apart the case and get the hard drive, but it's completely useless to me because I don't have another enclosure (and I need it for my laptop).

I highly suggest not getting a FreeAgent Desktop if you're looking for an external hard drive solution, but instead I would point you to a FreeAgent Pro, which doesn't seem to suffer from this problem.

EDIT: To update with what's going on, it turns out I need to send my faulty drive to Seagate and they'll ship out a replacement to me. Of course, I need to pay to send the drive to them. Data recovery isn't included in any of this, so I'll have to pay extra to get my critical data off the stupid thing. Obviously the warranty is totally useless to me because it doesn't cover any data on the drive, so I may as well crack the case and shove the drive itself into another computer (or buy an enclosure).

I'll say it now, I used to have faith in Seagate as a brand, but right now I'm drawing a line in the sand and saying that I will never be buying another Seagate device again. Sorry, Seagate, try harder next time.

The Forum User Problem and Taking it On

2008-03-20T15:57:00.003+10:00

Recently I've been reading around on osdev.org, and have been unhappy with what I've seen. It would appear that a wave of people are joining the forum, and in some way or another turning the forum against them. I'm not going to name any specific usernames, though...

I'm sick of these people posting to a thread with no knowledge of the subject to pick apart the original topic, and point out what's wrong with it - even after a moderator or a more experienced member has posted with assistance. Further, I find it frustrating when a user is told an answer and replies along the lines of "laziness" or something like that and yet continue to complain about their issue.

In fact, in a recent discussion assisting lukem_95 with his PCI Numeration code, he posted a "Smart Question" (which increased my respect for him/her) in which he explained the problem he was having well, provided his problem code, and showed evidence of attempting to figure out what went wrong himself. An answer was given, all seemed well, until another member decided he didn't like the question.

Here starts a flame war that continues on and on, and includes a statement "I don't think there are any real programmers here" (paraphrased) - an extremely inappropriate statement considering we have a university lecturer (slash doctorate) as a moderator (Combuster) and several industry programmers (ie, JamesM, omin0us, et al).

So what can we do to tackle this problem, when threats of a ban, comments about a member's behaviour, and generally going against the community doesn't stop anything?

I believe there are several ways to solve the problem:

User suspensions: suspension for a week (or longer/shorter depending on severity of issue) that gives the member time to think over what he/she did and lets any flamewars cool down
Thread locking: a feature of most forum systems that I believe isn't used enough. Locking a thread stops both parties from continuing the fight
Personal messaging: let the two concerned parties continue with the discussion in a personal message chain. I know that PHPBB2 forums support multi-user personal message sending, so this is not difficult. A problem with this approach is a lack of moderation.
User bans: ban users who break the rules.

I dislike the last option, because it's final and harsh, but it is definitely justified after several warnings.

Forums are online communities - let's try to get along with each other - and think twice before hitting that "Post" button.

OS Development and Debugging

2008-01-26T21:16:00.000+10:00

Well, I've finally gotten back into my OS developing - this is now the third rewrite of Mattise (titled "Mattise 3.0") and I'm truly starting from scratch on this one. I'm spending a lot longer getting the basic x86 code implemented (stuff like paging and the descriptor tables) and putting it through a lot of tests to verify that it's ready to do the job. Once I've finished with these tests I can add layers to it, such as context switching (threads and processes, although processes are really just a set of threads) or a driver system.

Debugging all this is proving to be the hardest thing out of all the code I've written. At the moment I have to use a whole bunch of printing calls to output state until I finally figure out the source of the problem (and hope it's not those same printing calls). I've heard of people writing a dprintf interface to the Bochs port E9 hack but I personally think that sounds pretty, well, hacky, and means testing in other emulators is harder. My favorite idea is a debugging system that talks to the kernel via a serial line, but I'd still need to verify that the serial line works properly. A serial driver could even be written inline, not using a proper driver interface, to make life easier.

I'm happy with my first couple of days re-entering the fray that is OS development on the x86 architecture. All I need to do is wait for the Intel Manuals to arrive in the mail and I'm set. I'll make an effort to keep this blog up to date with all that's happening as a reference point not only for everyone else but for myself.

The project page hasn't been modified yet but it's at http://www.sourceforge.net/projects/mattise.

WikiForAll - a wiki devoted to comedy

2007-10-28T18:07:00.002+10:00

Yes, that's right, a new wiki enters the world...

http://www.wikiforall.net/

If you're in need of some humour, this wiki is the place for you.

On Dvorak Layout and Game Design

2007-10-14T20:10:00.000+10:00

After a mate suggested I try out Dvorak because, I quote, "your fingers fly, man!", I figured I had nothing to lose and setup the Windows language bar to let me switch input modes from the standard US keyboard to US-Dvorak keyboard layouts. Needless to say, the switch has not been seamless. It is so much more difficult to learn a new layout when I've been typing on the standard US layout for such a long time (it may also have something to do with the lack of proper labels on my US-style keyboard). Even having an image in front of me of the layout doesn't help much.

And, to make it worse, I keep hitting the key combination to o,cyjd mre.o (switch modes) accidentally. One day when I get really bored I'll just open up Notepad and type "The quick brown fox jumps over the lazy dog" over and over until I can get it nice and fast. But who has time to spare, in this fast-paced world?

Me, obviously. After all, I have taken on a project at school to write a multi-player RPG for my class to play when assessment finishes. As of the time of writing, it currently supports scrolling the map when the local player moves too close to the edge, drawing other players (although I have not yet plugged in the networking code to update these other players), an inventory manager (though no pickups yet or anything like that), and am in the progress of implementing a statistics manager (experience points and such).

When complete, I hope to do a test run with the class and if successful recruit some of the more artistic members to draw the tiles for the game (as it is a 2D, top-down, tile based game). After creating some nicer tiles, I can then proceed to optimize the code like crazy, making it run really quickly locally so that network latency is not as much of a problem as it could be in a 3D game where the local version must update the frame and wait for input from the network.

I actually have had an ingenious inspiration relating to NPCs in the game as well. Instead of having them built into the game, which increases code bloat and makes life harder, NPCs will be programmed as clients to the server, meaning that an NPC is nothing more than a basic program with AI logic in it to respond to game events, that connects to a specific server as if it was a human player. This method allows the NPCs to be easily customized on the fly, and makes testing the program much easier (once the server is started, it doesn't need to be quit again just to fix an AI bug).

The only thing I can't figure out is what to call the game. If you like, you can post tile ideas as a comment to this post. Who knows, maybe your suggestion will become the name of the game!

On Game Development

2007-09-29T14:58:00.000+10:00

Due to my recent lack of success in game development (a 3D FPS is quite a challenge at times - more on this later), I've decided to go back to the first game I wrote - a simple "Pong" clone with a couple more features and a nasty AI.

My 3D FPS works nicely, it loads levels and you can move around in them, but I never got collision detection setup in the engine, or any guns or any FPS-related stuff. I was mainly concentrating on getting a scripting engine setup for it, and after I got boost::python to work in the engine I realized most parts of the engine needed to be rewritten anyway because they were slow and causing massive code bloat.

My old Pong game works nicely as well. You can load it up, select the difficulty level from the (extremely) rudimentary menu, and the AI can get tough. Unfortunately it was plagued by my lack of knowledge of the DirectX APIs and hence code is scattered everywhere in an attempt to make a working game.

The new one will use a simple structure to do its work - not one massive procedure called every time the screen needs to be rendered. With a separate procedure for AI, physics, and drawing, the internal code base becomes much simpler and easier to work with. Monolithic functions (ie, those with > 100 lines of code) will be split into multiple (smaller) procedures.

And, possibly one of the most important things, the menu will be separated from the main game loop.

I don't know what I was thinking when I wrote the first revision of Pong, but for some weird reason I decided it'd be a good idea to put the menu code into a conditional block:

if( inMenu )
{
   // do menu stuff
}
else
{
   // do game stuff
}

The initialization for the menu was a bunch of hacks to get a bunch of strings into an array - now I know better methods for doing this. Often the menu strings would mingle with each other and end up becoming quite confusing.

The new game will hopefully fix all these bugs in the initial code base and utilize the full power of DirectX 8 (instead of DirectX 1 which I was using before). The final planned feature is something that all my friends suggested after playing the first version - "Add networking". It should be fun to write a basic protocol that updates paddle and ball position for a single client. Or even to have a fancy "spectator" view and a "tournament" mode for those who wish to have a LAN party with a bunch of mates.

It shouldn't take too long (hopefully no more than a month) and I'll post a link to the final binary when I'm done.

Gaming: Pick up and Play or The Epic?

2007-09-28T15:49:00.000+10:00

Has anyone noticed a trend lately in game development?

We have near-realism in our graphics (see some screen shots of F.E.A.R or Half-Life - they look incredible), with advanced sound systems that allows us to hear something "behind" us, and artificial intelligence that makes your enemies seem that much more real. Games almost make us feel like we are playing a movie.

Who cares?

Why is it that a simple game, with terrible graphics yet a fun concept, can leave the player entertained for hours?

Yet, after viewing screenshots and attempting to play a game called "Ragdoll Smasher" (see here), I realized that this guy had figured it out. The graphics are simple (at best) and sometimes a bit jerky, and there's no story, but you can sit there for hours throwing bodies around trying to knock over the obstacles.

Another simple yet fun game is "Thermonuclear War" (see here) - basically, you have a bunch of nukes and blackness in which to nuke. Take out all your enemy's cities, you win. It's written using the Windows console, so it's not gorgeous, but interesting nonetheless.

Small and simple games like these can become quite addictive, because you don't need to spend a long time at the computer to be engaged in the gameplay. They're literally pick up and play games. For a casual gamer, such games as Ragdoll Smasher (for the violent types) and Thermonuclear War (for the control freaks) can often be a quick boredom buster.

I don't want to discount the success of Half-Life (or other similarly successful games). They are excellent games and a lot of hard work has been put into them. But if I just want to play for a half an hour, I won't be satisfied with my progress in Half-Life as compared to a win in Thermonuclear War.

Direct3D Mistakes

2007-06-11T09:45:00.000+10:00

My stupid pyramid shape was rendering wrong, and I was getting somewhat confused at this until I actually asked some people over at GameDev.net and got some help. Nothing they did helped, so I looked through my code. After some searching, I found I was disabling depth buffering! Enabling it was a quick fix to my problem.

Read your code often!

Frustrating Forum Users

2007-06-10T11:13:00.000+10:00

This really frustrates me: http://www.developerfusion.co.uk/forums/thread/153675/#153675

The person asks for some help to learn the language and instead gets given hundreds of lines of code, which is poorly commented and in no way helps him.

To make it worse, it's an assignment this guy is doing, and to get given code like that can get him in trouble for cheating on his assignment. I just don't think it's fair on him for such a person as "Mohammad Rastkar" to give him all that code, and not give him any real understanding of what it does, and why it does it.

Rant finished.

My OS and 3D Graphics (not related)

2007-06-08T20:42:00.000+10:00

I was talking to a fellow devver on AIM this morning, and he asked to see my OS GUI, which of course I agreed to. I'm going to post it here so I can look back in a year's time and see how far I've come (click to see it in full size, it's 800x600):

The cursor you can see is the one in my OS, and the wallpaper is that of a fave band of mine. So far so good, I'm going to rewrite my window manager because at the moment it crashes. Once done, I can post the image of windows in my OS here.

Anyway, other than that, I've been toying with Direct3D, which I was talking about a couple of months ago. After giving up I've decided it's time to try again, and I've succeeded! I can create (and, most importantly, modify) a spinning pyramid! I'm really pleased, and I'm about to texture it, which will make me even more pleased.

In other news, I'm planning on porting Descent 1 to my OS, and once complete it will be the first 'official' game for my OS.

And now, I must go because I need sleep.

Compilers and Such

2007-06-04T13:06:00.001+10:00

Since the last time I posted, a lot has happened in my development life.

At the moment, I have 3 main projects which I am working on:

My hobby operating system (Mattise - http://mattise.sf.net/)
The TI-Basic compiler, for Texas Instruments graphics calculators (http://tibasic.sf.net/)
Neural Network System ('learning' AI)

Add in exams and school, and I'm pretty busy! So I decided to save myself a lot of time, and wrote a simple linked list class, that I'm going to post here.

//--------------- CLinkedList: Linked lists for any type ---------------//
// Copyright 2007 _____________
// Created 29-5-07
// License: GPL

//--------------- Includes ---------------//
#include
#include

//--------------- Class Definition ---------------//

/**
The CLinkedList class basically is a shell around a certain data
type. It allows linked lists to be created for any data type,
hence saving coding time.
**/

// main class
template<> class CLinkedList
{
public:

// initializes the list
CLinkedList();

// destroys all data in the list
~CLinkedList();

// dumps the list
void Dump();

// clears the list
void Clear();

// inserts data at the given offset, shifting everything else
int Insert( _T, int );

// pushes data onto the end of the list
int Push( _T );

// pops data off the end of the list
_T Pop();

// gets data from the list
_T Get( int );

// deletes an item
void Delete( int );

private:

// the list type
struct myType
{
_T data;
struct myType* next;
struct myType* prev;
};

// the start of the list
struct myType start;
};

template<> CLinkedList<_t>::CLinkedList()
{
// set the next and prev fields of start to null
start.next = start.prev = (struct myType*) NULL;
}

template<> CLinkedList<_t>::~CLinkedList()
{
// clear the list, free the memory
Clear();
}

template<> void CLinkedList<_t>::Dump()
{
// iterate through the list, displaying information about each item

// running pointer
struct myType* curr = start.next;

// running accumulator
unsigned int i = 0;

// delete each item
while( curr != (struct myType*) NULL )
{
// print it
cout << "LIST[" <<>data <<>

// get the next pointer
curr = curr->next;
}
}

template<> int CLinkedList<_t>::Push( _T d )
{
// find the end of the list, then append the data

// running pointers
struct myType* prev, *curr = &start;

// wait until curr is null
while( curr != (struct myType*) NULL )
{
// save the current pointer
prev = curr;

// load the next one
curr = curr->next;
}

// check that the one we want to add to isn't null
if( prev == (struct myType*) NULL )
{
// fail!
return -1;
}

// safe, so append - we need to make a structure first
struct myType* m = (struct myType*) malloc( sizeof( struct myType ) );
m->prev = prev;
m->next = (struct myType*) NULL;
m->data = d;

// fill it in
prev->next = m;

// success!
return 0;
}

template<> _T CLinkedList<_t>::Pop()
{
// find the end of the list, and remove it after saving its data

// running pointers
struct myType* prev, *curr = &start;

// wait until curr is null
while( curr != (struct myType*) NULL )
{
// save the current pointer
prev = curr;

// load the next one
curr = curr->next;
}

// check that prev isn't null
if( prev == (struct myType*) NULL )
{
// return start's data
return start.data;
}

// prev holds the data we want
_T ret = prev->data;

// now unlink prev (the previous one's next is NULL)
prev->prev->next = (struct myType*) NULL;

// and free the pointer
free( prev );

// return the data
return ret;
}

template<> _T CLinkedList<_t>::Get( int offset )
{
// loop through the list until we hit either NULL or the offset

// offset into the list
int o = 0;

// running pointer
struct myType* curr = start.next;

// keep on going
while( o++ != offset && curr != (struct myType*) NULL )
curr = curr->next;

// we've hit the offset or NULL
if( curr == (struct myType*) NULL )
return start.data;

// return the data
return curr->data;
}

template<> void CLinkedList<_t>::Delete( int offset )
{
// loop through the list until we hit either NULL or the offset
// then unlink it

// offset into the list
int o = 0;

// running pointer
struct myType* curr = start.next;

// keep on going
while( o++ != offset && curr != (struct myType*) NULL )
curr = curr->next;

// we've hit the offset or NULL
if( curr == (struct myType*) NULL )
return;

// unlink the item
curr->prev->next = curr->next;

// free the memory
free( curr );
}

template<> int CLinkedList<_t>::Insert( _T d, int offset )
{
// loop through the list until we hit either NULL or the offset
// then append data to it

// offset into the list
int o = 0;

// running pointer
struct myType* curr = start.next;

// keep on going
while( o++ != offset && curr != (struct myType*) NULL )
curr = curr->next;

// we've hit the offset or NULL
if( curr == (struct myType*) NULL )
return -1;

// create a new item
struct myType* m = (struct myType*) malloc( sizeof( struct myType ) );
m->data = d;
m->next = curr->next;
m->prev = curr;

// link it into the list
curr->next = m;

// success!
return 0;
}

template<> void CLinkedList<_t>::Clear()
{
// iterate through the list, freeing memory as we go

// running pointers - never start at 'start' because it isn't heap allocated
struct myType* savnext, *curr = start.next;

// delete each item
while( curr != (struct myType*) NULL )
{
// save this one's next
savnext = curr->next;

// delete this one
free( curr );

// get the next pointer
curr = savnext;
}

// and make sure start is setup properly
start.next = (struct myType*) NULL;
start.prev = (struct myType*) NULL;
}

It's extremely simple to use:
CLinkedList ll;
ll.Push( 5 );
ll.Push( 6 );
ll.Push( 7 );
ll.Delete( 1 );

You might say, 'what about std::vector?' The above class is more portable, and works without modification in my own OS.

I'm gearing up to post a multitasking tutorial someday, so keep your eyes peeled!

Bye for now, not forever!

Operating System Development...

2007-04-09T16:53:00.000+10:00

It's been a while since I've posted here... Been too busy working on my newest project: Mattise, my hobby operating system. You can see a couple of screenshots and download it at http://www.sourceforge.net/projects/mattise. Many thanks to all the people over at OSDev.org for helping me with all the problems I had with it.

The other project I'm embarking on alongside my operating system is a physics class which can be inherited by other classes. For instance, the physics class is called 'PhysicsObject'. If a user wanted a box, he creates a class called 'PhysicsBox' that is derived from 'PhysicsObject'. At the moment it is extremely experimental but covers velocity changes and acceleration.

If I get around to it I may post some little tutorials on operating system development here. Keep your eyes peeled.

Programming Languages

2006-10-30T09:49:00.000+10:00

Well, yesterday I was happy to see that I was the number 1 most active user on Developer Fusion... Not that that's an achievement! Apart from that, my newest project is a programming language (interpreted, as I couldn't be bothered writing a compiler). It's really simple, and has the same sort of functionality as, say, BASIC... But it's a programming language, and I made it, so that's all that matters.

I've also written an email sending system on my server that connects to small via libgmailer and allows me to send emails without much effort! I also finally got around to making my forms look good with good old CSS so I now have good looking forms (using a bit of a hack... Using a DIV in the background with the input box on top).

Finally, I am continuing to work on my Winsock class - next thing to add to it: server-side stuff! I can't believe I forgot all that! Once that's done, I'm going to write a web server and hope for the best.

Bye for now, not forever...

Microsoft makes it intentionally vague...

2006-10-22T15:39:00.000+10:00

I've finally given up on looking and now I'm writing a class for sockets - so far it works for connecting to my home web server so hopefully I've done someting right.

Yesterday I learnt how to use Amazon Web Services so now I'll be able to extend some of my websites to include searches for Amazon stuff (I'm already using it with ISBN numbers on a website!)

I'll keep you all filled in on the happenings of my programming and may even get around to posting some code, if you're all lucky!

Hey, we all make mistakes

2006-10-18T17:25:00.000+10:00

Ok, ok... I have been greatly mistaken. It was almost going to happen, wasn't it. I actually searched the DirectX SDK directory and, lo and behold, found a help file with everything I need to know to make anything in Direct3D.

Moral of the story? Read the manual.

In other news, I'm writing a discussion board system that runs completely off XML files. When its done I'll put the link into one of these posts. In fact, I think I might write a simple website just to hold the projects I'm working on so that anyone can download them.

Farewell for now.

DirectTutorial - Game Programming with Direct3D 9

2006-10-17T14:15:00.000+10:00

DirectTutorial - Game Programming with Direct3D 9

My mistake, there is actually a tutorial on the net, this will easily be converted to Direct3D 8 with a bit of editing... It's for Visual C++ 2005 (or one of the Express Editions, which is what I have).

Just shows what Google can do, doesn't it (search Simple Direct3D Tutorial C++ in Google)

First Game Completed: Pong

2006-10-17T11:30:00.000+10:00

Well, we all have to start somewhere, so I decided to write a simple game to learn the basics behind game design before I went to some more complicated project. It definitely paid off, with my first game being a clone of the hit game 'Pong'. Ok, maybe not a hit, but close enough :D. My next project is to write an Asteroids clone... it would be nice to show those asteroids in real 3D, not just wimpy 2D renderings of 3D models for my DirectDraw engine... why must they make it so hard to do anything in Direct3D? I've searched for ages just to find a tutorial just to initialize Direct3D - not even draw anything... I found some thing called D3DX, but couldn't be bothered downloading anything and I read that it only comes with the SDK after version 9 - I just so happen to be using version 8... if you have any idea how to do Direct3D, please send an email pcmattman@gmail.com.

I'll keep this space up-to-date with the happenings of the Asteroids implementation, until then, farewell for now.