Optikal

That link provides about all the information you could possibly need to know, including a link to another article about implementing it in .Net.

If you know how matrix multiplication works (which any intro. linear algebra book should explain) you can combine that knowledge with the Matrix section of the DX SDK docs to figure out how to create your own transformation matrices.

Create a translation matrix that will translate the world such that your mesh is now at the origin, then multiply that by your rotation matrix, then multiply the result by a translation matrix that will move the mesh back to its desired position. The resulting matrix will be what you want.

Just to add my .02 to this. I think C++.Net should be used when you want the power of C++ (ie. scientific computing, gaming, etc) but you want to use the .Net framework for something such as the GUI. C++.Net allows you to do all this in one language.

If you want to use an x86 processer for a control type application, you can get a version of windows called Windows Embedded made specifically for this purpose. Also Linux and the various Unix flavors come in very lightweight distributions for this purpose, and since Linux is open-source you can modify it to suit your needs (which would be infinitely easier than trying to write your own OS from scratch).

Making a compiler is an extremely complex task. There is lots of research on this, and most universities offer compiler construction courses. If you do a search for Recursive Descent or LR Parsers you should get some webpages that offer compiler construction advice. There are also "compiler compilers" available for download (ie. YACC, LEX [i think thats what its called]).

If you use time-based algorithms (animations, physics, AI, etc) then they will run at the exact same speed regardless of framerate. This is the way almost all modern games operate.

Just curious, why do you want to limit your framerate? typically games will allow the framerate to be as fast as the host computer can handle...

I'm a full-time student, going into my 5th and last year of a comp. sci. degree (I know, I'm slow). I've been a programmer at a major aerospace company for the past 6 years or so, using mostly VB6 but got to do some ASP, some Java, and some Access (ick). In a couple years we'll be moving to .Net here, so me and my co-workers are currently working on getting MS certified with .Net (MCSD).

dereck: You say you should free all managed objects in the dispose event. I was under the impression that this was not needed. By freeing them I assume you mean setting all references to them to null/nothing. By doing this you are not actually freeing the memory until the GC runs, but regardless of whether you "free" them in the dispose event or not, when the GC runs it will look at the object graph and see that they are unreachable regardless of whether the references were deleted. If this is correct then I really see no point in freeing managed objects in the Dispose event (unless they use resources other than memory). I am fairly inexperienced with .Net so I may have made some incorrect assumptions here, please correct me if I'm wrong.

Just a side note I wanna make. If you are serious about wanting to program games, you should know that they involve TONNES of math. Especially if you are involved in the 3D engine portion of it. Matrix math, calculus, vector math, advanced geometry, etc. It sounds like you are focusing on your math skills which is good. Just thought I'd throw in my 2 cents.

developers do appreciate the small learning curve of XBox development. But it is still done in C\C++ which gives them low-level access, it is just the low-level access they are used to having when coding on the PC. So the learning curve is small since they already have experience with C\C++, but they still have their low-level control over the runtime environment. Console developers will love anything MS can do to reduce the learning curve, but they will not trade their low-level control for it.

Since your vid card has only 8MB of memory I'm assuming its fairly old (or just low-end) and won't support many DX9 features (such as custom shaders) in hardware. But not to worry, because DX includes a software emulator, it will just give bad performance, but will still allow you to run and play with your code.

If you want an education that teaches you to build real-world apps you can go to a technical college. University courses generally tend to teach you the theory behind programming, and give you a deep understanding of all the fundamental concepts and advanced techniques, but rarely apply that to real-world applications.

Would never happen, at least not in the near future. Console developers demand too much low-level control to accept .Net. They would balk at such a high-level layer. It would be nice though....

Don't think thats the case. I load and save the bitmap in separate events (triggered by menu items). So the application is idle between the 2 events. But just to make sure, I tried it with Application.DoEvents() right before the save, but as I suspected, it made no difference. It has been suggested that the Bitmap locks the file while the bitmap is loaded, and that if I want to save it to the same file I have to copy the bitmap to another in-memory Bitmap, then call Save on that one (haven't tried it yet though)...still don't understand why the SaveFileDialog would make it work though.

It seems that when I load a System.Drawing.Bitmap object from a disk file using the constructor (the one that accepts only one string [the filename]), then try to do a .Save() on it passing in a string representing the filename, it will produce an exception if the filename I pass to Save() is the same one I used to load the bitmap. The exception raised is: System.Runtime.InteropServices.ExternalException Additional information: A generic error occurred in GDI+. If I pass in a different filename to Save() it works fine, or if I create a new Bitmap by just specifying width and height (not filename) then .Save() it, it works fine. What is perhaps the strangest thing of all, is that if right before I try my .Save(), if I do a .ShowDialog() on a SaveFileDialog control, the Bitmap.Save() will always work. Even though I do absolutely nothing with the result from the dialog, and it doesn't matter what file I select in the dialog (or even if I press cancel). My theory is that the Bitmap is somehow holding onto the file that it loads itself from. And that when I try to save it, it raises that exception because the file is not ready to be overwritten. Now my questions would be, how do I make it so that I can successfully Save my bitmap, and what the heck is the SaveFileDialog.ShowDialog() doing that makes Bitmap.Save() work?