Damon Payne: Hand waving software architect

103db signal to noise ratio at < .03% total harmonic distortion
Solution Architect, software developer, geek
Damon Payne at Blogged
2009 Microsoft MVP - Client App Dev
2007 Microsoft MVP - Solution Architecture
 Monday, March 31, 2008

http://rss.slashdot.org/~r/Slashdot/slashdot/~3/261336950/article.pl

I believe this to be awesome news.  While Intel, John Carmack, NVidia, and others debate the degree to which Ray Tracing is useful, I'll be hoping that the Direct X Ray Tracing solution using the Task Paralell Library (or something like it) to exploit multiple cores for ray tracing a scene.



Monday, March 31, 2008 11:17:06 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Tuesday, December 12, 2006

A friend just sent me a link to this Channel 9 video and I watched the first couple of minutes.

http://channel9.msdn.com/Showpost.aspx?postid=261254

For those of you who don't have 40 minutes to watch this, its a video interview with Frank Savage @ MSFT, who heads of the XNA development team.  Frank worked on Wing Commander III and has a ton of street cred in the gaming industry.  MSFT wisely continues their trend of hiring the smartest people with the most cred and vision that they can find.

Anyway, allow me a moment of self reflection.  When I was 11 I made a spaceship game on BASIC for our 8086 PC.  It had colors and a cool spaceship I drew using arcs and lines, and the spaceship shot out this cool lightning bolt when you hit the space bar.  I got it to draw terrain (fixed skyscape that repeated over and over again) and was working on enemy spaceships.  At the time, I didn't understand that game developers give the illusion of many things happening at once by giving every object in the game world a chance to update itself every "tic" and that redrawing as often as possible was responsible for seeing various things moving on the screen at once.  I was trying to see if there was a way to get threads to work on BASIC, the old BASIC with 10 PRINT "HELLO", 20 GOSUB 2000 so I could have one thread per enemy spaceship and bullet.  Hey, it made sense at the time!   This caused me to wonder, where the hell did I go wrong?  I could have been one of those guys you read about, certainly no John Carmack in level of skill or innovation, but if I'd stuck with game programming maybe MSFT would be hiring me and people would say "Yeah, wow, you're that guy who worked on CornBlaster II" or something like that.  Oh well, I suppose I'm still young, if I only I could get off my ass and stop playing FFXII long enough to get back into game programming after an 18 year hiatus.



Tuesday, December 12, 2006 3:23:42 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Tuesday, September 12, 2006

If you know me, you know I am an audio nut.  A peak at my living room (pictured here) might give you an idea I'm not well in the head, let alone the lunacy involved in the custom home theater that's being built in the basement right now.

The world of audio is a great place to observe tons of Snake Oil being sold and a sad, sad departure from the available Science that could guide us towards better sound.  Its not unlike many areas of computer science, where the Morts have never even heard of the science their day-to-day work is based on.  If you know SQL experts who are great at their job but who weren't aware that the concepts come from relational algebra, set theory, etc. then you know what I mean.

Over the past year I've become very interested in the effect the listening room has on sound.  Audiophiles like me spend a fortune on equipment that has perfect frequency response and near-zero harmonic distortion then put the system in a room that creates 30db peaks and valleys and flutter echos that ruin the stereo image, the list of room problems goes on and on.

I recently created a Room Mode calculator for my audio site, http://www.KlipschCorner.com/.  Room Modes are essentially the frequencies your room will cause to sound louder than they should due to the dimensions of the room.  For example, a 60hz sound wave is 19 feet long making a room with any dimension being 19feet a bad call.  Rooms with the common 8ft ceiling are tough to treat due to the frequency ranges being close to 8ft or 4ft.  A room mode calculator is useful when planning a new listening room because one can quickly see if there will be room modes at any "problem" frequencies and also see the distribution of room modes, where an even distribution is desirable.

There is a graphical component as well as a tabular component.  My hosting provider, while their service is great, chose to license a rather poor charting utility, so if anyone wants to send a free license of Infragistics my way you'd be saving me a lot of pain.

You can see the end results at http://www.KlipschCorner.com/Tools/ModeCalc.aspx and I suppose I can make the KlipschCorner.Acoustics library as it stands now available via some open source license.

I wonder if DirectSound could be made to do some time-domain analysis (using test tones and a microphone for input) for calculating sound decay rates vs ambient noise in a room?

.NET | ASP.NET | DirectX | Rant


Tuesday, September 12, 2006 9:41:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [6]  |  Trackback
 Sunday, June 12, 2005

 I finished this book on the plane coming back from Tech Ed.  The book is pretty well laid out and if you download the source code for all the samples to read as you go along everything makes a lot of sense.  If I had never even looked into game programming before and this was the first book I'd read, the book would be highly motivating; it leaves one with the feeling of "Holy crap, I could actually do this."

If you've never done game programming before, I'd suggest going through the motions of doing the 2D games before getting into all the Managed D3D stuff.  2D games have all the same elements: game loops, render loops, collision detection, etc and you need to learn all those things before moving on to more complicated vectors.  Reading this book also gave an introduction to DirectInput, DirectSound, and DirectPlay: the developer story for making a DirectX game is really fantastic. While there is always a performance hit for working within managed code, as Tom Miller points out Managed DirectX is a very thin wrapper and in terms of pure graphics performance the managed apps get very similar framerates to the unmanaged apps.

I'm going to re-work my current Tank simulation with DirectInput and some sound before moving back to my neural net.



Sunday, June 12, 2005 12:45:09 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [40]  |  Trackback
 Thursday, June 09, 2005

 I saw several good talks yesterday but by far the most interesting was Jocham Seemann's talk about the Domain Specific Language tools they are working on for Visual Studio 2005. (Side note: he must not have grown up in the US, I did not see the battle scars he would certainly have acquired defending himself and his name) The idea behind the DSL tools is to provide a common set of Designer tools. Designers tend to have common elements such as shapes, decorations, and connectors. Consider an ER modeling tool vs. a UML class diagram tool: their basic notions are similar but the exact semantics differ. Using the DSL tools you define the semantics of your custom language. You detail what entities are in your domain space, what attributes they have, what types of connections they can have to what other entities, etc.

The DSL tools have a lot of built in support for code generation, using an ASP-like tag syntax, similar to CodeSmith as well.  The tools allow you to define validation rules and such as well, and handles persistence of your models for you.  Once your tool is done, you can click a button to build a visual studio add in so that other developers working within your problem space can use your Domain Specific Language.

My question is why stop there?  Why limit the use of this tool to visual studio users?  Suppose you work in a business with a fairly well defined domain, such as selling mutual funds for a specific company.  If you could define your domain entities, attributes, connections, rules, etc and then put this tool into the hands of people like, oh, say, business analysts you may have a very powerful code-generation and/or documentation tool that is usable by the people who supposedly know the business best.  I have built some custom designers in .NET 1.1 and its not exactly easy, a "Generic DSL" tool would be an interesting challenge and potentially a very useful product to a business as well.  I'll have to dig up the DSL team's URL out of my notes and download the DSL plugin for Visual Studio 2005.

 

In other news: Microsoft released a June 2005 update for the Managed DirectX SDK.  The first time I downloaded it a resource bundle seemed to be missing and it didn't work.



Thursday, June 09, 2005 9:28:12 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [7]  |  Trackback
 Monday, May 30, 2005

I've been talking about DirectX and games lately, and I've come up with a simulation for me to experiment with some things I've been wanting to learn or see in action.  Essentially, my brain has been going in several directions at once and this will be a first effort at exploring some ideas I have.  These areas of interest are:

  • Physics: Realistically modeling shockwaves from explosions.  Coming up with a mathematical model for uniform and non-uniform force vectors and fluid dynamics such that a virutal world can react realistically with no "arbitrary" parameters defined, ergo "How come this can blows up but not this wall?"
  • Destoryable terrain technology.  Using the above to be able to model bezier surfaces that represent a surface after an explosion.  
  • AI: I'm very interested in AI, mostly just for academic nerd reasons ,but I may come up with business or gaming related applications

So, I've decided my simulation for all this will be a DirectX remake of the classic game scorched earth.  It will start out as a 2D version and move to a 3D version as soon as I find a good (free) 3D modeling tool.  I already have the game and graphics part of it pretty much done.  Next step: program some AI that shoots back at you.

If you read the site because of the .NET Compact Framework or other "useful" content this may seem ridiculous to you.  Never you mind, games are some of the most complex systems you can write today, presenting very complex design challenges.  Consider it a mental workout.

Of course, if I have fun with this I will try to make a product out of it...



Monday, May 30, 2005 12:38:14 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [3]  |  Trackback
 Tuesday, May 24, 2005

OK, so, I've had a chance to mess with Direct 3D more.  As soon as you figure out basically how to draw 1 thing on the screen and you want to experiment, its best to create some kind of framework.  It would be nice to draw a scene, isolate your experiment to one class, and make it easy to add/remove/alter a particular aspect of the scene you are drawing.  A dynamic scene could be rendered given the following metaphors:

An Entity class that represents any draw-able item.  The Entity is responsible for loading its vertices, points, textures, etc.  A non-staic light source could also be an entity in which case the Entity would load its color information etc.  The Entity could be an abstract base class.  Entities are added to a World which represents all the dynamic items that could be rendered.  While Entities might not be visible at all times (View Coordinates, World Coordinates, Painter's Algorithm discussions in future posts) they might be thinking/acting elsewhere so they need periodic chances to do something even if they are not visible.  A simple DirectX program/Render loop might go like this:

  1. Initialize Device and drawing surface properties
  2. Create a World
  3. Create some Entity objects to go in the world
    1. Entity objects load their Model (vertices, colors, textures, etc) information
    2. Entities are given a reference to the Device so that they can Render themselves later.
  4. While your World is running
    1. Given each item a chance to update itself
    2. Process user input if applicable
    3. Begin a scene
    4. Tell each item to Render itself
    5. Do lights/effects passes etc
    6. End Scene
    7. Present Scene
    8. Repeat

All in all, the render loop for a simple game/simulation might be pretty simple.  The internet could use a lot more sample code for Direct3D, at least I've been unable to find much on how various things are typically done.  For example, when an Entity changes position in the World is it customary to rebuild it or to Transform its vertices to reflect the new position?  From what I can see, Transformations are used to model the observer changing its view position from one place to another, yet, rebuilding a vertex list seems very inefficient.  Consider this partial snippet for drawing a triangle with 3 vertices and some color:

...
class MovingTriangle : Entity
{
private CustomVertex.TransformedColored[] _verts;
private VertexBuffer _vertBuffer;
private float _topX;

...

public override void Render(Microsoft.DirectX.Direct3D.Device dev)
{
dev.SetStreamSource(0, _vertBuffer, 0);
dev.VertexFormat = CustomVertex.TransformedColored.Format;
dev.DrawPrimitives(PrimitiveType.TriangleList, 0, 1);
}

public override void DeviceAquire()
{
_vertBuffer = new VertexBuffer(typeof(CustomVertex.TransformedColored), 3, _dev, 0, CustomVertex.TransformedColored.Format, Pool.Default);
_vertBuffer.Created += new EventHandler(_vertBuffer_Created);
_vertBuffer_Created(null, EventArgs.Empty);
}

void _vertBuffer_Created(object sender, EventArgs e)
{
DoCreateBuffer();
}

private void DoCreateBuffer()
{
GraphicsStream stream = _vertBuffer.Lock(0, 0, 0);
_verts = new CustomVertex.TransformedColored[3];

_verts[0].X = _topX;
_verts[0].Y = 50;
_verts[0].Z = -0;
_verts[0].Rhw = 1;
_verts[0].Color = System.Drawing.Color.Red.ToArgb();
//
_verts[1].X = _topX + 100;
_verts[1].Y = 250;
_verts[1].Z = -0;
_verts[1].Rhw = 1;
_verts[1].Color = System.Drawing.Color.Red.ToArgb();
//
_verts[2].X = _topX - 100;
_verts[2].Y = 250;
_verts[2].Z = -0;
_verts[2].Rhw = 1;
_verts[2].Color = System.Drawing.Color.Red.ToArgb();

stream.Write(_verts);
_vertBuffer.Unlock();
}
}
...

It seems as though vertex recreation would be horribly inefficient.  I just ordered a pile of DirectX books from my favorite online store to shed some light on common D3D practices.  As soon as I get through the next chapter in my Physics book I can share the nature of my ridiculous DirectX test project.

 



Tuesday, May 24, 2005 9:58:40 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [5]  |  Trackback
 Monday, May 23, 2005

 After passing it at B&N several times I picked this book up yesterday.  I really enjoyed my Physics in college but of course being in a hurry to graduate left no time for pursuing any interesting things.  I do regret that my physics class was not Calculus based.  When I did take Calculus the physics applications were by far the most interesting parts.  When we were shown that the first derrivative of the acceleration function is the distance function I was blown away as it was the first time I'd ever seen a mathematical idea (derrivatives) explain not a phenomenon in reality (If the train is going 100 km/h and the city is 50 km away...) but an actual aspect of reality.

Back to the book, I just started reading the first few chapters: a refresher on basic physics.  More impressions as I read through it but you can probably expect to see a DamonPayne.Physics C# library posted here. 

When picking this book up I also realized how utterly ludicrous it is that the English measurement system is still in use.  Over the course of the year, I'm going to try to convert to thinking of things in terms of Kilometers to my house and my car's 0-100km acceleration time.



Monday, May 23, 2005 8:06:15 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Wednesday, May 18, 2005

I have never done DirextX programming before, as I mentioned my graphics experience is in 2D software drawing APIs (ie, line/pixel/arc drawing) and OpenGL.  Tonight I got some paying work done and needed to dabble in something so I got the latest and greatest Managed DirectX download from MSDN, dated April 2005.  I have mostly been messing around with the sample programs tonight, and just started combining some of the samples to do something more than hello, world.  "Hello World" in graphics land is drawing a shaded triangle, by the way.

A few observations from an hour of messing around:

The Good

Things have come a long way since I last did anything with graphics.  Creating a drawing device can be done in as little as 2-4 lines of code.  Its fairly easy to get to the point where you can start messing around and see something on the screen.  Microsoft has also included some Intellisense documentation, which was missing when I played with DirectShow a while back.

                PresentParameters presentParams = new PresentParameters();
                presentParams.Windowed=true;
                presentParams.SwapEffect = SwapEffect.Discard;
                _device = new Device(0, DeviceType.Hardware, this, CreateFlags.SoftwareVertexProcessing, presentParams);

... then draw away.

The Bad

Performance from Managed code does not look like its going to be pretty.  I'm thinking it should be able to draw the simple scene shown above more than 42 times per second.  Also, many of the examples included in this release of the SDK do not compile or work.  The most annoying thing I encountered is the code included for drawing text to the Direct3D device did not compile.  It looks like MSFT has been tweaking the managed API and has not updated all the samples.  For what its worth, I got the "GraphicsFont" to work with minor code changes, and I'm including the file here for download on the off chance anyone else is having issues. 

GraphicsFont.cs.rename (22.61 KB)

More observations as I get time to make them.



Wednesday, May 18, 2005 9:32:50 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [5]  |  Trackback