This is a nice little laptop. The screen is pretty and it's not too big. It runs fairly cool (at least compared with my old HP laptop).
And the keyboard is nice. I wish is were backlit, and while I like the numeric keypad on the right, I don't think that I love it. With the old laptop, I was (subconsciously) used to aligning my right hand with the edge of the laptop, and I can't do that anymore. The touchpad is slightly offset to be more aligned with the main keyboard - a little odd at first, but not a big deal. I find that I'm sitting a little bit to the left when I use the computer so that I'm aligned with the keyboard as well.
But it's very nice so far.
06 July 2009
New Laptop with Vista
I was planning on skipping the whole Vista thing. Not that there was anything terribly wrong with it - just that it didn't really give me anything that I really needed.
We got a netbook earlier this year and I was glad that it came with XP because that meant that "things just worked". This is partially a comment on XP functioning nicely (thankyouverymuch) and partially a comment on family members expectations when using a computer. "Things just work" and "things are where they are supposed to be". Changing to a new OS means that things are going to move around and I had no great need/desire to figure out where everything had moved (and then show everyone else in the household).
Well, my XP laptop is now encountering problems and it'll take a while to get it back in working order. In the meantime, I needed a new laptop and CostCo was having a good deal on a HP Psvilion dv6. I was irritated with CostCo for being closed on the 4th of July (how could they do that to me!), but not irritated enough to go shopping elsewhere for a computer. So I waited an entire day without a computer.
And yesterday I brought it home.
Vista.
Now what? Do I play the "I'm too cool to use Vista" game and install XP on this machine? Or do I go straight to Windows 7 and hope that the various upgrades go smoothly?
Ah, I'm too lazy for that. Let's just see how Vista works. I'm sure it's perfectly usable...
We got a netbook earlier this year and I was glad that it came with XP because that meant that "things just worked". This is partially a comment on XP functioning nicely (thankyouverymuch) and partially a comment on family members expectations when using a computer. "Things just work" and "things are where they are supposed to be". Changing to a new OS means that things are going to move around and I had no great need/desire to figure out where everything had moved (and then show everyone else in the household).
Well, my XP laptop is now encountering problems and it'll take a while to get it back in working order. In the meantime, I needed a new laptop and CostCo was having a good deal on a HP Psvilion dv6. I was irritated with CostCo for being closed on the 4th of July (how could they do that to me!), but not irritated enough to go shopping elsewhere for a computer. So I waited an entire day without a computer.
And yesterday I brought it home.
Vista.
Now what? Do I play the "I'm too cool to use Vista" game and install XP on this machine? Or do I go straight to Windows 7 and hope that the various upgrades go smoothly?
Ah, I'm too lazy for that. Let's just see how Vista works. I'm sure it's perfectly usable...
05 April 2009
Disabling startup items in WinXP
Looking at the task manager this morning, I noticed a bunch of old/garbage items running -- like WDBtnMgr, which is a "button manager" for WD hard drives that was left over from when we briefly owned one (we returned it, partially because of the software it insisted on installing everywhere, and partially because it tried to be clever with power management and didn't always connect properly. In any case, why would I want a "button manager" for a hard disk?).
Anyway, while searching I found this site: http://www.wikihow.com/Alter-Startup-Programs-in-Windows-XP which shows how to use msconfig to disable the startup items.
But the most useful information on that page (for me, at least) is the link to ProcessLibrary, which is a list of all those cryptic process names with information about each one. Very useful!
Anyway, while searching I found this site: http://www.wikihow.com/Alter-Startup-Programs-in-Windows-XP which shows how to use msconfig to disable the startup items.
But the most useful information on that page (for me, at least) is the link to ProcessLibrary, which is a list of all those cryptic process names with information about each one. Very useful!
14 January 2009
Debugging C# NUnit unit tests
I'm finally getting around to adding unit tests to a C# project I'm working on and got a chance to play around with NUnit. Yes, I know, I should've started adding these tests long ago (like when I started the project), but better late than never.
Using NUnit is quite easy:
Within your new [TestFixture] class, add tests by including methods marked with a [Test] attribute, and you can optionally have SetUp/TearDown methods to make your tests easier to manage.
Here is a stub [TestFixture] class with a single [Test]:
Once you've done this and built your project, you can launch the NUnit GUI exe, point it at your assembly and it will find and run all (or some, if you choose) of your tests.
One problem is that when you encounter a failing test, you can't just jump in and debug your code. The free Visual Studio C# Express Edition doesn't allow you to attach to a running process like the non-free Professional versions of Visual Studio.
To get around this, I added the following TestSuite class to seek out (using reflection) and call all of the unit tests (just like what the NUnit GUI does).
So now when I encounter a unittest failure in the NUnit GUI, I can set a breakpoint at an appropriate place in the code and then run the unittests in the Visual Studio debugger.
It's not perfect, but it works.
[Note: older versions of NUnit had a [Suite] attribute that could be used to set up test suites, but this doesn't seem to be present in the most recent releases. In addition, you apparently needed to add each unittest to the test suite manually, which is just asking for problems with missing tests.]
Using NUnit is quite easy:
- Download the MSI from http://nunit.org (Current version 2.4.8)
- Install
- Add a Reference to "nunit.framework" in your project
using NUnit.Framework;at the top of the file and add a new class that you mark with a [TestFixture] attribute. This attribute is used by the NUnit GUI app to identify the classes that contain your unit tests.
Within your new [TestFixture] class, add tests by including methods marked with a [Test] attribute, and you can optionally have SetUp/TearDown methods to make your tests easier to manage.
Here is a stub [TestFixture] class with a single [Test]:
[TestFixture]If you want to add the SetUp/TearDown methods, they are marked with their own attributes as follows:
public class Utils_Test
{
[Test]
public void Test_XXX()
{
// The unit test.
Assert.IsTrue(true);
}
}
[TestFixture]But again, all you really need is the [Test] method.
public class Utils_Test
{
[TestFixtureSetUp]
public void FixtureInit()
{
// Initialization for the entire TestFixture.
// Called once at beginning before any tests.
}
[TestFixtureTearDown]
public void FixtureCleanup()
{
// Cleanup for the entire TestFixture.
// Called once at end of all tests (even if they throw exceptions).
}
[SetUp]
public void TestInit()
{
// Init for each test.
}
[TearDown]
public void TestCleanup()
{
// Cleanup after running each test.
// Called even if the test throws an exceptions.
}
[Test]
public void Test_XXX()
{
// The unit test.
Assert.IsTrue(true);
}
}
Once you've done this and built your project, you can launch the NUnit GUI exe, point it at your assembly and it will find and run all (or some, if you choose) of your tests.
One problem is that when you encounter a failing test, you can't just jump in and debug your code. The free Visual Studio C# Express Edition doesn't allow you to attach to a running process like the non-free Professional versions of Visual Studio.
To get around this, I added the following TestSuite class to seek out (using reflection) and call all of the unit tests (just like what the NUnit GUI does).
using NUnit.Framework;And then I add a call to
using System;
using System.Collections.Generic;
using System.Reflection;
using System.Text;
namespace MyApplication
{
public class TestSuite
{
public static void RunTests()
{
int nTests = 0;
int nFailedTests = 0;
foreach (Type t in Assembly.GetExecutingAssembly().GetTypes())
{
if (t.GetCustomAttributes(typeof(TestFixtureAttribute), false).Length != 0)
{
// Gather test info.
MethodInfo mFixtureSetup = null;
MethodInfo mFixtureTearDown = null;
MethodInfo mSetup = null;
MethodInfo mTearDown = null;
List<methodinfo> mTests = new List();
foreach (MethodInfo m in t.GetMethods())
{
if (m.GetCustomAttributes(typeof(TestFixtureSetUpAttribute), false).Length != 0)
mFixtureSetup = m;
if (m.GetCustomAttributes(typeof(TestFixtureTearDownAttribute), false).Length != 0)
mFixtureTearDown = m;
if (m.GetCustomAttributes(typeof(SetUpAttribute), false).Length != 0)
mSetup = m;
if (m.GetCustomAttributes(typeof(TearDownAttribute), false).Length != 0)
mTearDown = m;
if (m.GetCustomAttributes(typeof(TestAttribute), false).Length != 0)
mTests.Add(m);
}
// Run tests
object obj = Activator.CreateInstance(t);
if (mFixtureSetup != null)
mFixtureSetup.Invoke(obj, null);
foreach (MethodInfo m in mTests)
{
nTests++;
if (mSetup != null)
mSetup.Invoke(obj, null);
try
{
m.Invoke(obj, null);
} catch (Exception) {
nFailedTests++;
Console.WriteLine(String.Format("Exception thrown in {0} during {1} test. ", t.Name, m.Name));
}
if (mTearDown != null)
mTearDown.Invoke(obj, null);
}
if (mFixtureTearDown != null)
mFixtureTearDown.Invoke(obj, null);
}
}
System.Windows.Forms.MessageBox.Show(String.Format("{0} tests. {1} failed", nTests, nFailedTests),
"Unit test results");
}
}
}
TestSuite.RunTests();somewhere in my application so that I can run the unittests from within the app.
So now when I encounter a unittest failure in the NUnit GUI, I can set a breakpoint at an appropriate place in the code and then run the unittests in the Visual Studio debugger.
It's not perfect, but it works.
[Note: older versions of NUnit had a [Suite] attribute that could be used to set up test suites, but this doesn't seem to be present in the most recent releases. In addition, you apparently needed to add each unittest to the test suite manually, which is just asking for problems with missing tests.]
19 November 2008
Rescue Princess 2.0 Application
Slides from a talk that Danc gave at the local Seattle chapter of IxDA (Interaction Design Association): "Building a Princess Saving App" and how it compares to application development in general.
http://lostgarden.com/2008/10/princess-rescuing-application-slides.html
http://lostgarden.com/2008/10/princess-rescuing-application-slides.html
Labels:
Game Design
Stairway to Satan
This video from Michael Shermer (director of Sceptics Society, publisher of Sceptic Magazine) discusses why people believe strange things.
The talk is from the 2006 TED Conference. The entire (14 minute) talk is interesting, but skip ahead to 9:30 to hear the section on Led Zeppelin's Stairway to Heaven which supposedly has satanic messages when you play the song backwards. Interesting demonstration of how pre-conditioning can trick you into seeing/hearing/believing things that aren't really there.
http://www.youtube.com/watch?v=8T_jwq9ph8k
The talk is from the 2006 TED Conference. The entire (14 minute) talk is interesting, but skip ahead to 9:30 to hear the section on Led Zeppelin's Stairway to Heaven which supposedly has satanic messages when you play the song backwards. Interesting demonstration of how pre-conditioning can trick you into seeing/hearing/believing things that aren't really there.
http://www.youtube.com/watch?v=8T_jwq9ph8k
18 October 2008
Waiting for 2009年3月...
Dragon Quest IX (ドラゴンクエストIX 星空の守り人)
Developed by Level 5, published by Squenix. This video was taken at this year's Tokyo Game Show:
Coming March 2009 for Nintendo DS (in Japan. No official date for US).
Ni no Kuni (ニノ国 - The Another World)
Developed by Level 5 with Studio Ghibli.
Coming 2009 for Nintendo DS (No official dates for Japan/US release).
Have I mentioned how much I love Level 5?
Developed by Level 5, published by Squenix. This video was taken at this year's Tokyo Game Show:
Coming March 2009 for Nintendo DS (in Japan. No official date for US).
Ni no Kuni (ニノ国 - The Another World)
Developed by Level 5 with Studio Ghibli.
Coming 2009 for Nintendo DS (No official dates for Japan/US release).
Have I mentioned how much I love Level 5?
11 October 2008
Nintendo DSi and homebrew
The most interesting aspect of Nintendo's recently announced DSi is the addition of SD slot. According to reports, this card is intended to store photos, video, music and games from the DSi Shop. So, wow! it sounds like Nintendo is actually allowing users to play games from a re-writeable memory card. This sounds perfect for homebrew.
It also sounds perfect for game piracy, which is why I'm doubtful that Nintendo would make this slot anywhere near as useful as it sounds. Aside from maximizing their market share, Nintendo's greatest desire is to eliminate game piracy for their systems.
Nintendo vs. the Aarrr! 4
Earlier this year Nintendo sued a group of companies in Japan for importing "game copying devices" like the R4DS. Because that's how they view them - simply as "game copying devices" with the implication that all game copying is illegal.
Of course, that's how they have to present their case. If they drew attention to the various uses for these cartridges which are clearly non-infringing like Moonshell, DS Organize, and the numerous homebrew titles, then they would be presenting a weaker (but more truthful) case.
Granted, it's likely (although I have no figures) that a significant number of R4 carts have at least one pirated game on them. And the "game backup" defense that is often used is weak because Nintendo made it impossible for normal users to create their own backups. This is important because the courts view a file you made yourself differently from a file you downloaded from the web. One is a backup and the other is not - even if the 2 files are identical and you own a legitimate copy.
Regardless, the legality of these carts (in the U.S. at least) will likely be determined by the precedent established in the Betamax case. This is where the "significant/substantial non-infringing use" defense comes into play. That is, the legality of these devices will depend on whether or not they support a non-infringing use like homebrew. Since all of these devices effectively enable homebrew, it probably more realistically comes down to whether or not there is a vibrant ("significant") homebrew community using these devices.
What about the DSi?
With the addition of music and video playback in the DSi, they're undermining the need for some homebrew like Moonshell. But there will always be a demand for other homebrew apps and games. If they really want to eliminate the R4, M3 and other carts, then they need to eliminate the need for these devices. That means having some Nintendo sanctioned method for writing your own games. With the addition of the SD card in the DSi, they now have a mechanism for doing this.
But will they do it? Sadly, I think that it's unlikely. My guess is that Nintendo has a love/hate relationship with homebrew. Actually, it's probably more of an "indifferent/hate" relationship. Some people in the company probably think it's cool what people are doing with their hardware, while others can only see dollars (and yen) lost to evil pirates.
And even if they do allow user-created games to run from the SD card, there are so many ways for them to screw it up and render it (mostly) useless. The most obvious mistake would be to not grant these SD card-based games full access to the hardware, but they could also require that apps be signed or some other nonsense. Nintendo just needs to look at how Apple is handling approvals for the iPhone App store for inspiration.
But this is all speculation. We know very little about what Nintendo is planning on doing with the DSi. My hope is that they will enable homebrew on the SD card, but I'm not holding my breath.
It also sounds perfect for game piracy, which is why I'm doubtful that Nintendo would make this slot anywhere near as useful as it sounds. Aside from maximizing their market share, Nintendo's greatest desire is to eliminate game piracy for their systems.
Nintendo vs. the Aarrr! 4
Earlier this year Nintendo sued a group of companies in Japan for importing "game copying devices" like the R4DS. Because that's how they view them - simply as "game copying devices" with the implication that all game copying is illegal.
Of course, that's how they have to present their case. If they drew attention to the various uses for these cartridges which are clearly non-infringing like Moonshell, DS Organize, and the numerous homebrew titles, then they would be presenting a weaker (but more truthful) case.
Granted, it's likely (although I have no figures) that a significant number of R4 carts have at least one pirated game on them. And the "game backup" defense that is often used is weak because Nintendo made it impossible for normal users to create their own backups. This is important because the courts view a file you made yourself differently from a file you downloaded from the web. One is a backup and the other is not - even if the 2 files are identical and you own a legitimate copy.
Regardless, the legality of these carts (in the U.S. at least) will likely be determined by the precedent established in the Betamax case. This is where the "significant/substantial non-infringing use" defense comes into play. That is, the legality of these devices will depend on whether or not they support a non-infringing use like homebrew. Since all of these devices effectively enable homebrew, it probably more realistically comes down to whether or not there is a vibrant ("significant") homebrew community using these devices.
What about the DSi?
With the addition of music and video playback in the DSi, they're undermining the need for some homebrew like Moonshell. But there will always be a demand for other homebrew apps and games. If they really want to eliminate the R4, M3 and other carts, then they need to eliminate the need for these devices. That means having some Nintendo sanctioned method for writing your own games. With the addition of the SD card in the DSi, they now have a mechanism for doing this.
But will they do it? Sadly, I think that it's unlikely. My guess is that Nintendo has a love/hate relationship with homebrew. Actually, it's probably more of an "indifferent/hate" relationship. Some people in the company probably think it's cool what people are doing with their hardware, while others can only see dollars (and yen) lost to evil pirates.
And even if they do allow user-created games to run from the SD card, there are so many ways for them to screw it up and render it (mostly) useless. The most obvious mistake would be to not grant these SD card-based games full access to the hardware, but they could also require that apps be signed or some other nonsense. Nintendo just needs to look at how Apple is handling approvals for the iPhone App store for inspiration.
But this is all speculation. We know very little about what Nintendo is planning on doing with the DSi. My hope is that they will enable homebrew on the SD card, but I'm not holding my breath.
30 December 2007
Converting videos for use with Moonshell (NDS)
One of the tasks that I needed to do over the holidays was to get some Nintendo DS/GBA flash carts set up for some people who are just getting started in Gameboy/DS homebrew development. Even though the primary use for this card is for homebrew, I thought it would be nice to get some audio/video playback working as well.
So I installed the multimedia player (homebrew) app Moonshell onto the DS flash carts. The latest version of Moonshell can be found in Moonlight's NDS archive. As of this post, Version 1.71+1 (August 2007) is the most recent version.
To use image and music files with Moonshell, you just copy your JPG/MP3 files (or a few other formats) over to your flash card and Moonshell will show/play them just fine.
Video, however, is a different beast as Moonshell won't dynamically convert the format or the size - it expects the video file to be GBA screen-sized and to be encoded in MPG1 video/MP2 audio. This means that you need to convert the videos into DPG format, which is a special format specific to the NDS and Moonshell. To convert videos into this format, there are a few free tools available (presented in the order in which I discovered them):
I tried all of these tools and had luck only with SUPER. There are clearly people out there using dpgenc and BatchDPG successfully, but I kept encountering problems with the conversion - probably codec related, but I didn't bother tracking them down since SUPER worked "out of the box" for my tasks.
To create DPG video files using SUPER, select "Nintendo - DS" from the dropdown list of output containers. This will simplify the interface by removing options that are not appropriate for DPG containers.
Now you can drag a video file into the window to add it to the filelist. Press the "Encode" button and SUPER will chug away and drop the newly encoded video file into your output directory.
One nice thing about SUPER is that, while the interface is a bit busy, there is plenty of context-sensitive help that pops up when you hover over the elements in the UI. This makes it fairly easy to get started with the program and get things working. To set the output directory, for example, just hover over the Output box and a message will pop up telling you how to set the output options.
So I installed the multimedia player (homebrew) app Moonshell onto the DS flash carts. The latest version of Moonshell can be found in Moonlight's NDS archive. As of this post, Version 1.71+1 (August 2007) is the most recent version.
To use image and music files with Moonshell, you just copy your JPG/MP3 files (or a few other formats) over to your flash card and Moonshell will show/play them just fine.
Video, however, is a different beast as Moonshell won't dynamically convert the format or the size - it expects the video file to be GBA screen-sized and to be encoded in MPG1 video/MP2 audio. This means that you need to convert the videos into DPG format, which is a special format specific to the NDS and Moonshell. To convert videos into this format, there are a few free tools available (presented in the order in which I discovered them):
- dpgenc.exe - This is included in the dpgtools distribution that comes with Moonshell. A basic tutorial on how to use (an older version of) this is at can be found in the MaxConsole Forums.
- BatchDPG - This is an alternative to dpgenc created by LS5, another homebrew developer. The official site still has the old original 1.0 version (with source), but updated versions from various people are also available (like Firon's 1.2 version). Be sure to review Yee and Firon's BatchDPG Guide because there are a number of pre-requisites (AviSynth, ffdshow, .Net Framework 1.1) that you'll need to have installed for this to work.
- SUPER by eRightSoft - "Simplified, Universal Player Encoder and Recorder" - This is a general video/audio converter that contains special support for DPG files. It can be downloaded from the SUPER main page, although to get to the actual download link, you'll have to navigate through a number of links. If you get frustrated trying to find the download, here is a direct download link. The latest build is 2007.23 (4 July 2007).
I tried all of these tools and had luck only with SUPER. There are clearly people out there using dpgenc and BatchDPG successfully, but I kept encountering problems with the conversion - probably codec related, but I didn't bother tracking them down since SUPER worked "out of the box" for my tasks.
Using SUPER to create DPG files...
To create DPG video files using SUPER, select "Nintendo - DS" from the dropdown list of output containers. This will simplify the interface by removing options that are not appropriate for DPG containers.
Select "Nintendo - DS" as the Output Container
Now you can drag a video file into the window to add it to the filelist. Press the "Encode" button and SUPER will chug away and drop the newly encoded video file into your output directory.
Drag your video files into the SUPER window
One nice thing about SUPER is that, while the interface is a bit busy, there is plenty of context-sensitive help that pops up when you hover over the elements in the UI. This makes it fairly easy to get started with the program and get things working. To set the output directory, for example, just hover over the Output box and a message will pop up telling you how to set the output options.
Subscribe to:
Posts (Atom)

