In one of my projects I'm using a PropertyGrid element in the main form as an easy way for users to change settings. One item in the class used by the PropertyGrid is a collection and C# automatically opens a CollectionEditor form for the user to add, remove and modify elements of the collection.
The issue however is that changes to the collection should be represented in the main area of the form immediately, but the CollectionEditor control seems to leave the collection in an undefined state until the form is closed.
I can understand what the CollectionEditor form is trying to do, it is waiting until the user clicks on OK or Cancel before writing the changes to the actual collection. However it doesn't do this, it partly mucks up the collection when the user changes items or adds them, but doesn't touch the actual collection when the user removes or rearranges items.
Tuesday 17 August 2010
Monday 16 August 2010
Torque and Power
When discussing performance or simulations of vehicles, the concepts of torque and power usually come up and often get confused. Our goal in writing a simulation is to get the vehicle to behave exactly like the real vehicle, in order to do this it is vital to understand the concepts of torque and power from the engine (these concepts apply to all type of rotary engines, including electric motors).
Tuesday 18 May 2010
Input management in XNA
Managing input in even the simplest game can result in a mess of confused lines of code scattered across the entire project. I have started to write an InputManager class that can be used to easily set up and use during the game.
There will be two main parts to the class. The first part is how to set it up during game loading, and the second is how to use it during the game to check what the player is doing. I use the concept of "Actions", which can describe a particular action the user wants to do, for example selecting a menu item, asking a character to jump, or steering a car to the left.
There will be two main parts to the class. The first part is how to set it up during game loading, and the second is how to use it during the game to check what the player is doing. I use the concept of "Actions", which can describe a particular action the user wants to do, for example selecting a menu item, asking a character to jump, or steering a car to the left.
Labels:
programming
Tuesday 4 May 2010
Simplifying complex resistor networks
After seeing this circuit diagram there were several differing answers in the associated forum regarding the resistance of the tangle of one Ohm resistors on the right side. The most common method seemed to be repeatedly applying the star-delta conversion on various parts and using other various simplifying tricks. The problem with these methods is obvious if you read the posts to the xkcd forum, everyone makes mistakes!
What is needed is a more robust, systematic method to solve problems like this, then a computer can solve it, and computers don't make mistakes. The method I will derive results in two relatively simple steps to solve any resistor network, no matter how complex. The first step is to set up a matrix that describes which nodes are connected together, the second step is to invert the matrix and solve.
Labels:
mathematics,
physics
Wednesday 21 April 2010
Games for 3D glasses with XNA
Following on from my post about creating images for 3D glasses, here is how I modified my XNA game engine to render stereo images.
Previously my camera class simply set up the view and projection matrices based on various input. These matrices are then used by the other components in the game to draw themselves. I have now added an extra property to the class, AnaglyphType, to determine whether the scene is rendered as a left/right stereo pair. Also extra code is added to the game loop to draw the scene into two textures, then combine them with a pixel shader.
Previously my camera class simply set up the view and projection matrices based on various input. These matrices are then used by the other components in the game to draw themselves. I have now added an extra property to the class, AnaglyphType, to determine whether the scene is rendered as a left/right stereo pair. Also extra code is added to the game loop to draw the scene into two textures, then combine them with a pixel shader.
Labels:
3D,
photography,
programming
Monday 12 April 2010
Simple 2D car steering physics in games
How to do a realistic moving car in only 6 lines of code!
I find nothing more frustrating in car games than when the developer has implemented some ridiculously unrealistic model for how the car moves. For most games, especially flash-based mini-games, simulation grade 3D physics are not required, but still the car should move and turn roughly like you'd expect a real car to.
Have a quick go at this car parking game, or this one, try to turn into a parking space, something doesn't feel right. More specifically the rear wheels are sliding sideways whenever you turn - this does not (normally) happen in a real car, and it makes this game very hard for all of us used to controlling a real car. I'll show you here how to get better physics than this in just half a dozen lines of code.
I find nothing more frustrating in car games than when the developer has implemented some ridiculously unrealistic model for how the car moves. For most games, especially flash-based mini-games, simulation grade 3D physics are not required, but still the car should move and turn roughly like you'd expect a real car to.
Have a quick go at this car parking game, or this one, try to turn into a parking space, something doesn't feel right. More specifically the rear wheels are sliding sideways whenever you turn - this does not (normally) happen in a real car, and it makes this game very hard for all of us used to controlling a real car. I'll show you here how to get better physics than this in just half a dozen lines of code.
Labels:
cars,
physics,
programming
Sunday 11 April 2010
Creating images for 3D glasses
I got a copy of Coraline for my birthday, and it came with a few pairs of those red/green 3D glasses. I thought I'd have a go and making some of my own 3D photos. The idea is pretty simple, you take two photos of the subject, one from the position of your left eye, and one for your right eye. You then tint the left image green, the right one red, and merge them together (this can all be easily done in Photoshop or equivalent).
I think this one came out pretty well, the rotors on the top of this model helicopter really look like they're coming out towards you!
I think this one came out pretty well, the rotors on the top of this model helicopter really look like they're coming out towards you!
Labels:
3D,
photography
Subscribe to:
Posts (Atom)