I was going to post here a sample VB project using DirectX, but I remembered there's an easier solution.

 Download #Develop from http://icsharpcode.net/OpenSource/SD/Default.aspx -- it has a template for DirectX already set up.  To use it, you need three things:

1.  Either Microsoft's .NET Runtime 2.0 or Mono 2.0

2.  DirectX 9 (XP) or DirectX 10 (Vista) from http://www.microsoft.com/downloads/browse.aspx?displaylang=en&productID=9C954C37-1ED1-4846-8A7D-85FC422D1388 (the SDK and/or REDIST will install the support -- better to install the SDK, so you can get help if you need it)

3. #Develop or Visual Studio -- #Develop has a template, Visual Studio does not.  The two use interchangeable project formats.

Alternatively, with the Microsoft toolset go here:

http://microsoft.com/xna

That will give you the XNA toolset, which allows you to write code in any managed language (including C#, VB.NET, Python, PHP, C++, Delphi -- whatever language floats your boat and is applicable to the target) and deploy to the following devices:

1.  Windows Computers

2.  XBox 360

3.  Zune MP3 Player

The XBox 360 support requires whoever owns the XBox to pay an extra premium to play "Creator's Club" games.  Zune currently doesn't require this extra premium.

Alternatively, if you're writing a new engine from scratch, TAO from the Mono project is a good option.  TAO uses SDL, a highly portable 2D graphics platform, and has bindings for OpenGL and a large number of other highly portable libraries.  As a result, code in any .NET programming language compiled against TAO is itself highly portable -- it will run, from the same executable, on MacOS X, Linux and Windows.

If it is desired to run against Mono on non-Microsoft OS, then avoid DirectX -- DirectX is a Microsoft proprietary technology, not supported on non-Microsoft platforms.  OpenGL is widely supported and, additionally, offers the entire DirectX 10.1 feature set on Windows XP with nVidia and ATI drivers.  OpenGL is driven by the video card companies in conjunction with industry partners from CAD-CAM and video game companies, not by Microsoft.  It is easier to introduce proprietary extensions, it is easier to introduce agreed-upon standard extensions, and generally the video card companies are fully supporting their chipsets features on that side.

On Windows Vista and later -- as well as all Linux distros and MacOSX -- you should use OpenAL in some form for audio.  Either directly via C++, TAO's OpenAL support (from .NET languages) or via a library like fmod.  Pure and simple, on Windows Vista the driver natively speaks OpenAL.  DirectSound goes through a compatibility library that invokes OpenAL.  On Windows XP, you should install Creative Labs OpenAL driver (which works with all sound cards), and on Creative Labs cards, that card will bypass DirectSound and talk straight to the hardware.  On non-Creative Labs cards, it will route through DirectSound.

http://blogs.msdn.com/andrewarnottms/archive/2007/10/29/what-do-you-think-of-the-new-wcf-store-and-forward-mail-transport.aspx

I can't speak for the mail transport in WCF, because I've not yet used it, however I've used other mail transports with .NET before.  The nice thing about the mail transports is that it is a technology that crosses firewalls easily.  If you have a client outside the firewall, it is almost never a problem for it to e-mail someone inside the firewall.  It is usually easy to get an e-mail account (regardless of the server software involved).

E-mail transports are also useful because Microsoft Message Queue requires a domain controller for some distributed scenarios, but you are sometimes on leased servers that aren't domain controllers.  In those scenarios, e-mail transport provides most of the same benefits as message queues, but without the need for a PDC.  That is huge for some setups.

The other really nice thing about e-mail transports is that given backup MX service (something that only costs around $20/year from companies like no-ip and the like), servers can go offline -- even for a week or more -- and the messages will recover when it comes back up.

The big drawback to e-mail is that it is very high latency.  The messages might get there in 10 seconds.  The messages might get there in an hour.  The messages might get there in a week.  This usually isn't a problem on internal e-mail, but it is a big problem for system domain boundaries. 

Also, you have to watch for filtering as well.  For example, is the remote system allowed to send mail by the SPF?  I am a huge advocate of SPF -- I have it set up on my servers, I enforce it on inbound mail, and you should too.  SPF blocks more than 300 messages a day on battlebazaar.com, and around twenty to thirty a day on battlebazaar.net, and we don't have a ton of users (but battlebazaar.com was used in several discussion lists and newsgroups, and so the spammers came).

Many anti-spam programs will trigger off of message headers, and off of receiving many similar messages.  You have to be certain whatever anti-spam you have server-side is able to handle the messages reliably also.