6 posts tagged “c#”

This is a bit of a late update, since this was resolved on Saturday, but whatever, it's still good news.

DirectInput finally works. As it turns out, there was no threading issue, just bad code on the part of the Managed DirectX book I was using. The damn thing was getting stuck in an infinite loop and preventing anything from happeneing once the keyboard's Initialize method was run. It now works beautifully, so I can get working on mouselook for the assignment.

It is mildly disheartening that most of the others in the class (well, those that still care. Quite a few people considered the class too difficult and have dropped or become zombies) are fairly close to completing tonights assignment. That is because they're focused on making it work rather than making it a truely object-oriented deal. Oh well, it's worth it.

Salisbury Steak, corn, mashed potatoes, a chicken pot pie, a can of Dr. Pepper, and some Smash Bros. Not a bad lunch.

Looks like I'll be spending most of the night catching up on my XML class. Way too much time working on Ingen, heh. There's a quiz tomorrow that I need to be prepped for. There's a J2EE exam next Tuesday, too. Gah, I need to get working on the lab for that.

Other than that, though, things are good. Matt and I are working on a new project, which is looking promising. I'm working on the DirectInput portion of Ingen. This has made me realize just how badly I need to add events for everything. I'll probably be spending a good deal of Friday doing so.

I decided last night that I wanted to prepare myself a meal for change. Though my schedule doesn't usually allow for the extravegance of...making Pasta Roni on my own time, yesterday was a different story.

I came home with enough Banquet tv dinners and pot pies to fill half of the freezer. TV dinners for a buck and pot pies for $0.43 is pretty hard to pass up. I am enjoying a lunch of beef enchiladas, rice, a pot pie, and a can of Dr. Pepper for the grand total of $2.04. Not bad, considering lunch usually costs me more than five.

Ingen is coming along nicely. Turns out that aspect ratio problem was actually an issue with the mesh itself. Whoever made it used a crappy .X exporter. The following errors occur when loaded in the .X viewer:

Loading model - C:\Documents and Settings\ddahl\My Documents\Visual Studio 2005\Projects\dusda\trunk\Ingen\UI\bin\Debug\samus.x
Tangents and Binormals cannot be generated without a 2-element or greater texture coordinate at TEXCOORD0. Please use DXOps to UV-Atlas your mesh.
Binormals do not exist on mesh.  Attempting to calculate.
Tangents do not exist on mesh.  Attempting to calculate.

In other words, the mesh is missing some of what makes it render properly. The .X viewer is capable of calculating fixes for it, which Ingen does not do. If I see more of these flawed .X exports, I'll add the functionality to do the same, but for now I'd rather focus on implementing DirectInput :) and lighting.

Especially the lighting. Managed DirectX handles lighting with a 'Lights' object array within the Device object. A total of 255 lights may be assigned per Device object, which is plenty (nobody uses that many lights at once). I decided that it would be best to treat the Lights array as exactly that, an array. I'll write a nice layer on top of it that manages adding, removing, and configuring of all lights. Once that's done I'll be able to manage lights in a Scene object (building it to abstract stuff away from the SceneManager, which currently contains code for both running the engine and handling scenes).

But enough mumbo jumbo. My chicken pot pie awaits.

Problems. Always with the problems!

I'm not sure what's causing this, yet. I set my camera up via a CameraInformation object I made. Here are it's properties:

cameraInfo.FieldOfView = (float)Math.PI / 4;
cameraInfo.AspectRatio = 4/3;
cameraInfo.FrustumNearPlane = 1;
cameraInfo.FrustumFarPlane = 1000;
cameraInfo.Location = new Vector3(0, 0, 2);
cameraInfo.Target = new Vector3();
cameraInfo.UpDirection = new Vector3(0, 1, 0);

I've tried modifying the aspect ratio a couple times, but it doesn't seem to be the problem. The field of view isn't an issue either. What the crap?

Now is a time for celebration. I finally hit the "Hello World" of my graphics engine. Thanks to some help from Cybie, the structure is more well defined and, now, completely functional.

I know it doesn't look like much; there is no lighting yet (that's next), but you're looking at a mesh imported from Bryce 5. It has a simple texture on it, which you can't see (again, the lighting), but it's there!

Next up: A more impressive picture.

I just hit a wall in my graphics engine (Hereafter referred to as Ingen).

LoaderLock was detected

Message: DLL 'C:\WINDOWS\assembly\GAC\...\Microsoft.DirectX.Direct3D.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

That's a first. I've never seen this before! This was delivered by something called an MDA...

Turns out the MDA is the Managed Debugging Assistant, which works with the CLR to catch things that can't otherwise be captured. I think I can just get around this by disabling the MDA...but it's telling me that there are potential deadlocks here, so I need to find out why.

So, I looked into the MSDN entry about LoaderLocks. Didn't help much. According to the entry, these are caused by mixing managed and unmanaged code in the same dll...but I'm not using unmanaged code. The SDK may be, but I'm using strictly managed stuff.

More on this when I figure out what's going on.

Solution: Turns out it's just a conflict with DX library versions. From Sontek:

I had this problem awhile ago when I was making my snakes game. The problem is that the libraries you are using are the DirectX 1.1 libraries, You need to add references to the 2.0 libraries or just turn LoaderLock off via the debug menu...Debug -> Exceptions -> Managed Debugging Assistants and uncheck LoaderLock.

Well, glad that's figured out. Now to fix the NullReferenceException that just came up...