Thursday, September 29, 2005

Hello Process!

I just created my first Windows service. Its sole purpose in life is to look for a Firefox process once a second and, if one is found, sets its CPU affinity to CPU0.

Works like a charm. :)

In lieu of posting binaries, which is what I'd much rather be doing, here's the source code, written in C# in Visual Studio 2005 RC. The trick is adding the service installer and using installutil.exe to install the service assembly. See Adding Installers to Your Service Application on MSDN.

I love .NET. I was intimidated by all the stuff I saw in MSDN about setting affinity until I got to .NET. Mmmm. Process.ProcessorAffinity()... Auughghghghghghh...

namespace AffinityMonitor
{
    public partial class AffinityMonitor : ServiceBase
    {
        public AffinityMonitor()
        {
            InitializeComponent();
        }

        protected override void OnStart(string[] args)
        {
            System.Diagnostics.EventLog.WriteEntry("AffinityMonitor", "AffinityMonitor service started");
            backgroundWorker1.RunWorkerAsync();
        }

        protected override void OnStop()
        {
            System.Diagnostics.EventLog.WriteEntry("AffinityMonitor", "AffinityMonitor service stopping");
            backgroundWorker1.CancelAsync();
        }

        private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
        {
            while (true)
            {
                Console.WriteLine("Tick!");
                Process[] processes = Process.GetProcessesByName("firefox");
                foreach (Process p in processes)
                {
                    p.ProcessorAffinity = new IntPtr(1);
                }
                System.Threading.Thread.Sleep(1000);
            }
        }
    }
}

Tuesday, September 27, 2005

(Nevermind.)

After turning off Cool 'n' Quiet and several days of working just fine, the PC's back to stuttering again. *sigh*

Monday, September 26, 2005

Trying to Vyde

Every time I get the urge to contribute to Vyde, I end up having to do something else. Was out of town this past weekend, am gonna be really busy at work this week, have to come up with an exercise routine, and will be out of town again the weekend after this one. So not a lot of brainpower has gone toward Vyde lately, but a little bit has. I want the gameplay to include scanning, ala Metroid Prime. And that thought led me to remember that I want to include stats, too, ala GTA. I've got some ideas on the random world generator, but have not implemented anything yet. Finally seemed to have figured out the stuttering app problem; AMD's Cool 'n' Quiet technology seemed to be the culprit (or at least the root cause). Turned it off and haven't had any problems in a few days. I've started looking at basic DirectX tutorials, and continue to look for more. I have a feeling that if I can get a program drawing 1 textured triangle, I can get one drawing 12 (10 if you take out the "fourth wall" of a tile), and with 6-10 triangles I have a tile. With a tile abstraction I can start stringing tiles together. We're getting there. Just got a lot of other stuff to do. Yay hobby! BTW, found a nice article on the 5 things every RPG should have. I thought it was spot-on, and even insightful in places.

Tuesday, September 20, 2005

Adventures in Concurrency: Fix for Stuttering Apps!

So I downloaded the DX9 August SDK and started having a look at some of the samples.

It helps to realize early on that trying to build the samples using the release candidate of Visual Studio 2005 acquired at the PDC (this is a sweet IDE) won't go off without a hitch. Though there are VS2005 solutions included in some of the samples, the UI toolkit they use to do a lot of the UI legwork references the wrong version of the .NET Framework (900). Tearing out the DirectX, Direct3D, and Direct3DX references, and replacing them with references to their respective 12xx equivalents seems to solve the problem.

Anyway, when I got the BasicHLSL sample to build, I ran it and saw constant stuttering. The timer in the UI was jumping back and forth in time. So, having already had problems with stuttering in Firefox and, the other day, Painkiller, and having solved both those problems by setting those processes' CPU affinities to a single CPU, I reasoned that the same thing was going on with this DirectX sample.

A bit of Googling turned up an article on MSDN about the QueryPerformanceCounter sometimes suffering from BIOS problems on multiprocessor computers. Further Googling schooled me in a problem with AMD's Cool 'n' Quiet technology.

Went to ABIT and upgraded my BIOS, and guess what? Problems solved. Firefox & Direct3D samples -- no stuttering.

So FYI, BIOS version 17 for the ABIT Fata1ity AN8 SLI cured the problem. I suppose it's just coincidence that the release notes for that version indicate a fix for the Cool'n'Quiet technology.

Oh, and might I add that the FlashMenu utility that ABIT dishes out is quite helpful: first time I ever flashed BIOS from within Windows. It even has connectivity to the ABIT website for finding, downloading, and installing the latest version automatically. Very cool. Happy with this board I am.

UPDATE: Ignore everything! Woke up this morning and the PC is back to its old ways. Rrrr.

Sunday, September 18, 2005

Lack of Managed DirectX Tutorials

I spent some time today looking for Managed DirectX tutorials, and haven't found a whole lot. So far, the best set I've found is at pluralsight.com. A lot of the tutorials out there, Managed or otherwise, use 3rd-party libraries to "assist" with the process. But those turn me off pretty quickly. I want to understand the inner workings of something, not just get to a finished product. The DigiPen series lost its appeal when I realized that it was teaching how to code around an existing engine. I may just start reading through the MSDN material instead.

Off Topic: The Sad State of Hobby-Level 3D Production

I've been spending some time looking at the options available for producing 3D content for Vyde. Up until a few minutes ago, I was hopeful that either Autodesk Gmax or Alias Maya Personal Learning Edition would supply me (a hobbyist, mind you) with a good 3D modelling and animation program for producing Vyde content.

Not so! Both are merely advertisements for their respective parents, 3DS MAX and Maya. By themselves, Gmax and MPLE don't permit you to do anything except "experience" the software. They are both cleverly-disguised shareware -- free, untimed trials that are useful only to those who have or intend to purchase the big app. Out of the box, Gmax won't export to anything but Plasma 3D.

Seriously. Who uses Plasma anymore?

Gmax is actually a case study in a marketing effort gone horribly wrong. Have a look at the titles that support Gmax "game packs". I can count them on two hands. Autodesk decided to needlessly inject a layer of development between the consumer and the game house, with the burden of development placed on the game house! Why? When a game house decides to grant extensibility powers to their customers, they typically release their own tools to do it. Where does Gmax fit into that business model? Nowadays, why would a game house devote extra resources to supporting a 3rd-party editor (Gmax) that wasn't used during the production process?

I can't even download MPLE; the site shows me some fantastic blank pages when I try, but no hint as to where I can get it.

What is a hobbyist to do? Blender3D? Ugh. I really tried Blender; gave it a good, honest, college try. Maybe it's because I'm an experienced 3DS user, but it was a pain in the ass to use.

I'll be on the lookout for alternatives, but in the meantime I may just reinstall my old educational copy of 3DS MAX. Version 3.1. Yay.

Hobbies shouldn't be this expensive.

www.vyde.info

I've registered www.vyde.info, for those who are interested. For the time being it will act as an alias to vyde.blogspot.com.

Tuesday, September 13, 2005

Multithreading

I just finished the second concurrency talk here at the PDC in LA, and it's got me really jazzed about attempting multithreading in Vyde. Possible applications I can think of at the moment include decreasing load times, offloading random level generation to a separate thread(s), or handling the simulation of the world in one set of threads and rendering in another. The conference is outstanding; the talks are very high quality and offer lots of useful insight into whatever you went looking for. Met the ZMan last night and a bunch of us went and had a couple of beers; it was a blast. You meet lots of interesting people at conferences like this. (Not nearly enough women, though. :)

Saturday, September 10, 2005

Growing a Game Organically: Water Frequently

I forget why the idea popped into my head, but I remember it popped loudly. In the unforgiveable amount of time that has passed since my last on-topic post, I've been thinking a lot about how to begin this project's implementation. I am wholly dissatisfied with the idea of designing the entire thing first and then implementing it -- I need to write some code and get at least one triangle displayed on my ridiculously fast video card.

Today I'm going to load up on Diet Sprite and finish the series of webcasts that I began a while back. It should take several hours, but I have little else to do this weekend before flying out to LA for PDC '05.

Oh right... the thought. So I'm thinking to myself that one approach to starting some code would be to design the entire game first (or the first version of it, anyway) then hack my way through it, meeting any and all requirements I set out for myself in a checklist fashion. Or, thought I, I could just let this be a hobby instead of a deadline-oriented project. I could instead make small pieces in a logical progression, and let the game grow organically.

The order in which things are done would be important, and even more important would be the coding style that produces very modular building blocks. Much like I assume God or whoever built the universe, I'd have to start with the most atomic piece I can think of, and then build on that, and build some more, and build more depending on what is needed (according to me). First task might be to create a simple tile: a 3D block that represents a unit of space in the game. With an almost Platonic concept of a tile form, I've produced something useful without having lost the freedom to change course. Then I might augment that with decorations or behaviors. Then maybe inanimate objects within tiles. Then maybe some physics to govern how those objects behave. With a tile model (and its constituent parts) in place, I could build a tile grid. With a tile grid full of tiles, I can begin adding random generation to the mix, making sure to compartmentalize that functionality such that it can be upgraded in the future without affecting the rest of the engine as it evolves.

To some I'm sure this seems obvious. But it hit me like a ton of bricks, as I'm usually a very process-oriented (and deadline-oriented) person -- have something usable at every step in case someone schedules a demo for the next day without telling you until the next day. But this new job is doing wonders for my problem-solving and learning skills -- I can see that I can combine play with process.

It's like Legos, if Legos were run through a multi-stage graphics pipeline.

Time to get started.

Monday, September 05, 2005

Off Topic: Simple Question

How is it, in Battlefield 2, that you can shoot an enemy soldier 5 times in the face with an assault rifle, from 20 feet away, zoomed in, and not kill him? Is that what they're calling realism these days?

Off Topic: Grow RPG

Grow RPG will consume about 3 hours of your life before it lets go of you. I have no idea why this is so addicting, but solving it is strangely gratifying.

Grow v3 will consume about 1:50 hours after you solve Grow RPG. :)

Off Topic: Gish!

Everybody go play Gish right now. WOW this is a great game. May be worth a purchase just to encourage games like this. The abandoned mine levels are so Vyde-ish. The physics are a blast, and the lighting is just great. Well done Chronic Logic!

Sunday, September 04, 2005

Off Topic: Half-Life 2 Finished

Finished Half-Life 2 today. Overall, I liked it a lot. Here's what I took away from it (spoiler-free):

  • Needless to say, the use of physics was outstanding.
  • Too many of the levels had insufficient ammunition.
  • It was often too difficult to see everything that was going on, though that did contribute to a sense of immersion.
  • The enemy design was great. The Combine looked truly menacing.
  • Great voice acting and great casting. Robert Culp as Dr. Breen was lots of fun to listen to.
  • The game was far too linear. It would have benefitted from more opportunities to (and motivation to) explore.
  • Not enough weapons!
  • OUTSTANDING graphics. The Source engine is truly a thing of beauty.
  • Cool story. I kinda wish that we knew more about the G-Man and Freeman's relationship to him.
  • Formidable AI. Even friendly NPCs are smart enough to get the f!@$ out of your way when you're trying to move around.
  • Good mix of action and problem solving.
  • Remarkable sound design. Probably the best of its class. The amount of detail to be found in the sound effects (like the way that gunshots change "depth" with distance) is not to be overlooked.
  • The ending was slightly anticlimatic. Kind of abrupt.
  • The animation, especially facial animation and headcrab animation, was top-notch. Scripted sequences were engaging and not annoying; they segwayed into action sequences well.

Definitely worth the price of admission. Gotta finish Thief III next.