Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Progress and a few design details

Sign in to follow this  


I've decided that designing an input system at this stage of the game would be a little premature given that I really only *need* 2 mouse axes to move a camera and 2 keyboard keys to move forward and backward.

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.
Sign in to follow this  


Recommended Comments

Original post by Matt328
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.

Might want to have a look-see at Setstyle(Controlstyles,bool) for that. Setting Controlstyles.Selectable to true would allow your control to be focusable. Not sure if this is rendered a moot point by your using XNA for keyboard handling, but might be helpful in the future.

Share this comment

Link to comment
Thanks for the tip. I wouldn't say its a moot point as I don't want to process any keyboard input unless the control has focus. However, setting Controlstyles.Selectable to true in the OnCreateControl() method doesn't seem to change anything. I still need to call Focus() manually in the OnMouseDown() function in order for clicking on the control to give it focus.

I also thought maybe I needed to be calling base.OnMouseXX() from my OnMouseDown() functions, but that didn't seem to change anything either.

Share this comment

Link to comment
Are you calling Updatestyles() after you set it? I didn't mention it prior since I was unaware of it, having been calling Setstyle(,) in the control's constructor instead of a method.

Share this comment

Link to comment
Oh, hey, guess what, I was wrong. >:| Found out today when testing a control of my own, threw multiple instances of it in a form, couldn't select the others. Looks like you /do/ have to Focus() when it is clicked.

I did a quick check in Reflector to see how TextBox handled it, and in the WndProc bit, it also calls a function to focus the control when it is left-clicked.

:/ Sorry for the blatant ignorance of my previous posts.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!