Switching to a Macbook

About a month ago, I watched a presentation by Steve Jobs, where he presented the current line of Macbooks, and the technologies used in their creation. Every single slide he pulled out made my eyes pop out of my head, leaving me scrambling to pick them up and put them back in. At the end of the presentation, when I just couldn't seem to find where my eyes had rolled off to, I had subconciously decided that I would get one.

A week ago, my subconcious decision manifested itself, and here I find myself typing away on a shiny new aluminum piece of art n_n.

But naturally! I'm a game developer that uses XNA... What use would I have for a Mac? I did a little research beforehand, and discovered that it wasn't that hard to put Windows 7 on the machine (which I love dearly) and get it working properly. Without that, I daresay I'd never have made the purchase.

I never imagined Apple would play so well with Windows o.o

All I did to get the Windows OS installed on the computer was pop in the install disk, and open up Boot Camp. I chose the partition size, and then a regular old windows installation setup ensued. After 7 had been installed, I popped in my Apple restore disk, or whatever one it was, and installed boot camp. All the hardware worked! Except the video card, which I just went to Nvidia's site and downloaded their drivers... which then worked perfectly.

My macbook at the Windows 7 login screen... I love the glow-ey keyboard n_n

I have the model with two graphics cards in it, and this is truly epic. The idea is that you use the integrated graphics card part when you want to conserve battery life (6 hours!) and switch to the discreet card when you need the graphics. Unfortunately, Windows will only recognize one graphics card (the discreet one), and will not let you switch between the two at all. This leads to a fair bit shorter battery life while running windows (only around 3). While I find this mildly disapointing, it's quite bearable, as I can't imagine doing my powerhouse gaming on OS X, and I have no issue with doing creative art and or document work away from Windows. Not to mention Mac has Office 2008 ;)

Oh, and did I mention this thing doesn't have any fans or airflow stuff on the botttom of it...? It intakes through the keyboard, and sends the hot air into a neghboring parallel universe o.o

Shadows

Ok, so I tried out the Reimers shadow tutorial, and I liked it a fair bit. It covers it all pretty well, and integrated easily enough with my own project... I had one heck of a time getting the depth comparison to work properly, but in the end it was just something silly (as always).

So here's the problem I have with it right now... first of all, the results aren't all that great, a problem inherent in the method. Since the idea is based on rendering the scene from another angle onto a texture, you have a limited amount of resolution. And it shows. Quite poorly.

Jaggies along the edges... gross >.<

Right now, the depth buffer is at 1280x800, same resolution as the screen, and it still fudges that poorly..? Granted, this is the worst case for this particular shot. Unfortunately, it happens often enough to be something to worry about, since even blurring won't fix some of these issues.

The other issue that I have is that the light comes from a single directional light. I could possibly fix it by switching to an orthographic projection for the depth buffer render, but then, I can imagine running into far more issues with the jaggies, and low resolution. Plus, even then, it's still not flexible enough to support an area light or anything like that... a torch for example.

As you can see, the light is definitely coming from a single point

So, I think a different method is called for :/... I'll leave it be for now. More important things to attend to!

A Quick Note on Shaders

A vertex shader function must always return an initialized value tagged as POSITION0, but then, the pixel shader function can't touch it. It throws an obscure error, along the lines of invalid input semantic 'POSITION0'

Learned that the hard way :/

If you really need to access the position, you need to copy it into a variable tagged TEXCOORD0, and then use that. It makes sense, really, if you think about it... Positions are for vertex shaders, textures are for the pixel shaders! Ish, oh well.

Programming Style

So here are a few things I do when I'm coding, that I find makes it easier to get things done. Since I code in C#, the Visual Studio provides me with a truly extraordinary intellisense, which not all languages receive. So given this, there are a couple of things that I do that makes typing a fair bit easier for me. Prefixes: While you might consider prefixes to be pretty old-school, and far out of style, I like to prefix a lot of my variables to group them together in the intellisense. This can make it particularly handy if you've forgotten what your variable is called. For example, I always prefix my parameter list variables with 'a' (stands for Argument)

To get this to work properly, it also helps to remove any unused 'using' statements at the top of your file. I've also read a few books on code style, and many suggest dropping the prefix, simply because your eyes skip over it anyhow. I find this to be true, but also part of the reason why I use it. The prefix is not so much for your eyes as it is for your fingers. I also find it to be helpful for avoiding name collisions, also evident in the example. Curly Braces: I never ever end my lines with a curly brace. I see so many Java developers that do this, and it bugs the heck out of me. The reasoning behind it is solid: to save on vertical space. But the cost for that saves comes a bit high to me. In order to save that space, you have to sacrifice the visual indication of a new zone, and you cram your code together far more. Space is something that gives your eyes room to breath, and lets you group pieces of code together. Rarely is the 'if' condition directly essential to the following line of code, so they really shouldn't be together anyhow. In the case where it were, a better solution would be to do something like this: if (condition == true) { Code.run(); Here you retain the visual indication for the body of the statement, and you also save the space you so desired. While I have toyed with using this stlye throughout my code, I never have, seeing as my IDE has quite dissagreed with me about it. But, empty spaces are just as important as full ones :) Naming Conventions: I once read in a book that comments should be avoided. I was quite stunned and appalled when I first read this statement, as I commented my code a fair bit at that point, and was quite pleased with it. However, after giving it much thought, I decided that the statement had been misphrased... A good coder should not need to write comments. Now that, I can agree with. Be verbose! Make your variable names as descriptive as they need to be. With the rise of such incredible intellisense as we have now, why do we ever need to worry about typing the whole variable name more than once? A descriptive name can give so much more mreaning than an obscurely placed comment. Another thing to do... Keep your methods short. The shorter they are, the better their names get, and the easier your code is to read. The measuring stick used to be the size of your screen, but what with a monitor running at 1080p? That's a large method... 8-10 lines is a bit of a better rule. Now, that last rule... 8-10 lines? I need to work on that one :)