For the mouse, I override OnMouseUp and OnMouseDown. When the right button is down, I freeze the cursor to the center of the control, hide it, and from then on, calculate the delta x and delta y from center. I multiply this by a factor of the game time, and rotate the camera by it. That way normally the cursor is free to move about the control and be displayed, but when you right click, the cursor disappears, and you're in camera move mode. Later I will still need to implement some sort of picking to be able to have the left click be sensitive to objects in the scene. I had a ScreenProjection class when I was using OpenGL that handled translating screen coordinates into world coordinates based on the gluUnproject() method, but I'll cross that bridge when I come to it.
The keyboard was a little more tricksy, until I figured out that when you subclass System.Windows.Forms.Control, you have to manually call Focus() in your MouseDown event handler in order to make the control have focus, and therefore fire KeyDown and KeyUp events. After spending an hour learning all about this, I realized that KeyDown and KeyUp events are not exactly fired in a realtime enough fashion for a simulation type application to use them. The events respect the system's key repeat rate. Well that's no good. Also, this was an event driven type of setup, so where would my game time for constant animation timing come from? Hmm, maybe I can track a velocity variable with keyup and keydown events, and scale that by the game time in my Update() method... no that won't do, it uglies up the control class, how does that work for multiple keys down, etc. I figured to heck with it, I'm using Xna, I might as well use Xna, so in the update method I grab up a KeyboardState and check for my two keys there with the handy IsKeyDown() methods. Problem solved. Could I probably do the mouse this way? Maybe, but its working the way it is right now, and I'm not a big fan of fixing stuff that's not broken, especially when I have more features on the 'unimplemented' list than 'implemented'.
So there you have it. The changeset I committed was only like 15 lines of code or so, and best of all, it confirmed that my suspicion in my last entry was correct, I click File->New, select a terrain size, pan the camera around and there's my terrain. Granted its only a bunch of triangles on the x,z plane, and there's no texture, and its all flat, but at least what IS being rendered is being rendered properly.
The next area I want to work on is getting a texture on said terrain. Looking into this, I realize in the before time, with OpenGL, some of the render engine code spilled into the model code in the form of the texture manager. I had the level store (model) set up so that anytime it encountered a storable that needed textures to render itself, it did a lookup from the renderer's texture manager. That worked for the time being, but Xna has exposed that for the bad idea that it was. If I port that design straight across, I'll end up with Texture2D's in my level store, which I have no idea how to write out to a file, nor is my level editor going to concern itself with reading in (That would involve the content pipeline, which I'm trying to keep out of my editor.) So my level store should store just the raw image data, as well as maybe the size might be useful as well. Then somehow I'll have to find a way to transform some raw image bytes into a Texture2D. Not sure how that's going to happen yet.
I'd really like to document the system I have set up for loading and saving the level store here, but I typed it up, and reading over it, either its not as elegant as I thought it was, or my technical writing skills are not as elegant as I thought they were. Either way that'll be an entry for some other time.