Day 30: Why the Windows 7 installer is horrendous

The horror that is a Windows installation

Set about reinstalling Katy and Donald with Windows 7 on-campus, Katy did fine the install went well and all was dandy. Donald now, was another matter entirely.

First, the installer would get up to the bit where you choose which drive to install Windows on, then there it would hang and tell me a required cd/dvd device driver is missing, insert installation disk to load the driver.

This issue normally happens when you need to load the AHCI or the RAID driver for the installation (it's all to do with sata drivers and recognising your hard drives and SSD's and such). Now, I've tried using the installation disk, I've tried all of the 50 or so options for AHCI and RAID drivers on that disk, and none of them actually fix the issue and let you install windows.

However the second cause of this error is when the Windows setup installation you are trying to install from (in my case a live, bootable USB drive) is internally corrupted in some way or another. In which case reformatting and remaking the bootable usb drive fixes it.

Remaking the USB drive got me past this issue, then hit another error when I tried to format the SSD to install windows - apparently windows cannot create the partition.

So anyway, I've discovered the best most foolproof way to get windows to install when you have drive problems: boot into partedmagic or some other live partition management software (e.g. gparted directly) and set up your drives manually. You want a new partition table but leave the partition you wish to install windows on unformatted. No initializing an NTFS partition or any of that jazz, you want a fresh clean disk with only an MS Dos style partition table, but no partitions initialized on it.

Only took about 10 hours of trial and error with Hoops and now Donald to work that one out!

Promotional Video for the School

Some chaps took some quick video clips of the AR stuff in action as part of a promotional video for the University. Pics below, courtesy of Toby (thanks :))

Dude on the left has the absolute latest in camera stability gadgetry

The bouncing golf balls, result of 4 gruelling hours well spent

And the annual barbecue was also roaring away in the background as I sat typing furiously away indoors. Due to fasting commitments I couldn't join the general food splurging, and my afternoon was spent distancing myself enough far enough away from the sumptuous smells wafting through just about everywhere. Having a room without a window has some benefits then!

Back to Automation

We left off with the following tasks done:

Replacing regex within .fbx files so they reference the correct textures

Building .fbx and .jpg files via the command line MSBuild into working .xnb files

Various bits of shell scripting

And this not yet done:

1. Some more shell scripting (moving the correct files about..?)
2. How to manage the loading of files into LowryDemo (current method of replacing .xnb and then hitting M, Z is too dangerous and user unfriendly)
3. How to manage the gif generation (user needs to manually adjust variables on every head to center the head model so that it rotates in the middle of the view: need to adjust zoom, Y position, Y rotation of the model before running the JPEG snapping bit)

Looked into task 2 today, managing loading of files into LowryDemo. After lots of googling, debugging, googling, sitting back in frustration, debugging and googling I've finally worked it out.

Overridden the Model Loader code to customize it because I want to load the .xnb files that I built myself - not the ones that the project is building at compile time. This means specifying a custom directory and model name for the loading. And it works - this means I can load whatever I want, whenever I want whilst the program is running! The correct head loading of LowryDemo is complete, at long last.

To do now: work out the automation of ExportJPEGs and implement it into the automated workflow

use batch files in the shell script to do the msbuild stuff on the fly

finish off batch file automation.

And that should be it!

There are also some optimizations I need to do in general that I recently learnt about, mainly adding content links rather than copying content to the content folder. This should save a good gigabyte or so of wasted space in the final program! Very welcome stuff.

Random notes I made whilst working it all out (for reference):

Great resource: http://rbwhitaker.wikidot.com/managing-content

(also links to more great resources on the Content Pipeline itself and then how to extend it)

At compile time, all assets are processed through content pipeline and stored in a temporary file (.xnb)

Content.Load<Model>("blah") retrieves the model you specify from the content pipeline, which is given as a Model object to whatever called Content.Load.

Brief overview of Content Pipeline, 4 steps on all assets before they are used in your game:

1. Importer: reads imported data so the content pipeline can process it. Outputs the object that the next element can process...
2. Content Processor: converts raw data from Importer into something meaningful, what we call processed data.
3. Content Compiler: puts processed data into a (binary) compiled asset file, an .xnb
4. Content Loader: reads in compiled asset file, turns it into an object your game can use

Summary:

Specify Content.Load to point to your own premade .xnb files.

Name must not include an extension

Must be name of the original file (sans extension) before compiling.Not so! Simply use the name of the final .xnb file (sans extension)

Corresponding textures must be in the same directory.

CANNOT USE ABSOLUTE FILE PATHS - (this one got me for a looong while, but it does make sense - moving the code to other people's computers, you don't know where stuff will end up in an absolute sense)