Just finished a chase camera that can be moved around with the xbox controller.
And yes, the rev counter works :)
Tuesday, October 28, 2008
New chase camera
Just finished a chase camera that can be moved around with the xbox controller.
And yes, the rev counter works :)
Monday, October 27, 2008
XNA Vehicle Physics
I've tried several different physics engines for XNA:NFS.
I tried JigLibX first, as it had the coolest vehicle demo, but after a considerable amount of pain getting it integrated, it was difficult to get the vehicle to behave in the same way as the demo. And once it got to a certain speed, it started to rock side to side, with no obvious way to stop it.
Up next was BepuPhysics. This has a pretty basic looking vehicle demo, but was quite easy to integrate.
Basically you define your terrain (from a list of vertices), give it some properties like friction and gravity. Then you create a Vehicle, attach some Wheels and hook up a button press to wheel.Accelerate();
Getting it running initially only took a couple of hours - but trying to figure out values to make the vehicle behave correctly still had me tearing hair out days later.
The problem is that its all a very fine balance of forces. For example, one bumpy part of the track was pitching the vehicle backwards and forwards and looked ridiculous. The solution? Make the suspension softer to counteract the bumps. But making the suspension softer caused it to wallow/float around the corners, sometimes tipping over. The solution? Increase the sideways stiffness, and give the car more mass to stabilise it. This then pushed the softened suspension down too far. And so it went on, round and round.
After almost quitting the whole project, I saw this post which is a simple 2d vehicle physics class. Using it as a starting point, I've ended up writing my own vehicle physics. Granted, it will never be anything as good as what Bepu/JigLibX could produce in the right hands, but it means I can choose which corners to cut and focus on making it a fun experience to drive.
Demo coming soon :)
I tried JigLibX first, as it had the coolest vehicle demo, but after a considerable amount of pain getting it integrated, it was difficult to get the vehicle to behave in the same way as the demo. And once it got to a certain speed, it started to rock side to side, with no obvious way to stop it.
Up next was BepuPhysics. This has a pretty basic looking vehicle demo, but was quite easy to integrate.
Basically you define your terrain (from a list of vertices), give it some properties like friction and gravity. Then you create a Vehicle, attach some Wheels and hook up a button press to wheel.Accelerate();
Getting it running initially only took a couple of hours - but trying to figure out values to make the vehicle behave correctly still had me tearing hair out days later.
The problem is that its all a very fine balance of forces. For example, one bumpy part of the track was pitching the vehicle backwards and forwards and looked ridiculous. The solution? Make the suspension softer to counteract the bumps. But making the suspension softer caused it to wallow/float around the corners, sometimes tipping over. The solution? Increase the sideways stiffness, and give the car more mass to stabilise it. This then pushed the softened suspension down too far. And so it went on, round and round.
After almost quitting the whole project, I saw this post which is a simple 2d vehicle physics class. Using it as a starting point, I've ended up writing my own vehicle physics. Granted, it will never be anything as good as what Bepu/JigLibX could produce in the right hands, but it means I can choose which corners to cut and focus on making it a fun experience to drive.
Demo coming soon :)
Monday, October 20, 2008
XNA Performance Profiling
Finally having all the main bits working in XNA NFS, I was looking at the performance, which wasn't great, even on my fairly decent PC.
I first went through my normal optimization - limiting the number of DrawPrimitive() calls. After bringing it down to only the minimum of calls (by only drawing a small part of the track), I still had an annoying camera 'jump' every second or so. This is at a pretty even 50-60 fps windowed (ie, maxed for my refresh rate).
After going through my camera classes and not finding anything wrong, I figured I'd try profiling it - although given the framerate I didnt expect to find anything unusual.
A quick google of XNA performance profiling turned up a link to nProf - a freeware & open source .NET profiler.
Here is a screenshot of the nProf window after running for a couple of minutes.
Notice the selected line - the BasicEffect constructor. The total amount of time spent in the BasicEffect.ctor() was almost as much as the total amount of time spent rendering the track!
This immediately didn't look right, and having a look at where I was calling new BasicEffect() revealed the problem. I was creating about 5 new BasicEffects per frame
The ease of creating a BasicEffect, and even the name itself implies you can create them whenever you need one - but the reality is they are SLOW to create, so you better not be creating them per frame!
I changed my code to create them once then update properties on them per frame.
In fact, all but 2 were identical, so I was able to get down to 2 BasicEffect.ctor() calls for the whole lifetime of the game. The framerate is now always 59-60fps, and the annoying pause/jump (which I now assume was the GarbageCollector doing its thing) is gone. And without using nProf I would never have guessed the problem.
So the lesson is (as I've been told and forgotten many times) is to profile then optimize, not the other way around.
Life is good again :)
And heres the latest screenshot, showing the corrected gamma and track barriers:
I first went through my normal optimization - limiting the number of DrawPrimitive() calls. After bringing it down to only the minimum of calls (by only drawing a small part of the track), I still had an annoying camera 'jump' every second or so. This is at a pretty even 50-60 fps windowed (ie, maxed for my refresh rate).
After going through my camera classes and not finding anything wrong, I figured I'd try profiling it - although given the framerate I didnt expect to find anything unusual.
A quick google of XNA performance profiling turned up a link to nProf - a freeware & open source .NET profiler.
Here is a screenshot of the nProf window after running for a couple of minutes.
Notice the selected line - the BasicEffect constructor. The total amount of time spent in the BasicEffect.ctor() was almost as much as the total amount of time spent rendering the track!
This immediately didn't look right, and having a look at where I was calling new BasicEffect() revealed the problem. I was creating about 5 new BasicEffects per frame
The ease of creating a BasicEffect, and even the name itself implies you can create them whenever you need one - but the reality is they are SLOW to create, so you better not be creating them per frame!
I changed my code to create them once then update properties on them per frame.
In fact, all but 2 were identical, so I was able to get down to 2 BasicEffect.ctor() calls for the whole lifetime of the game. The framerate is now always 59-60fps, and the annoying pause/jump (which I now assume was the GarbageCollector doing its thing) is gone. And without using nProf I would never have guessed the problem.
So the lesson is (as I've been told and forgotten many times) is to profile then optimize, not the other way around.
Life is good again :)
And heres the latest screenshot, showing the corrected gamma and track barriers:
Monday, October 6, 2008
Screenshots
For the one person reading this - here are some early screenshots!
The starting line
There are still gamma issues with some scenery objects...
Birds eye view of part of the track
The physical road the car actually moves along
The starting line
There are still gamma issues with some scenery objects...
Birds eye view of part of the track
The physical road the car actually moves along
Sunday, October 5, 2008
Need For Speed in XNA
As the title suggests, I'm working on an XNA-powered Need for Speed game.
It reads in the original Need for Speed 1 data files (using specs found here) and renders it out in full XNA goodness - 1024x768, anti-aliasing, motion blur etc.
I thought it would be an interesting test - would an amateur using XNA be able to replicate a 10 year old game, which for its time was pretty groundbreaking?)
The jury's still out on that one, but so far I have a complete track and vehicle renderer, complete with animating scenery and skybox.
I am currently working on the car physics, using this as a starting point.
Screenshots of the original game are a bit hard to find, heres one:
It reads in the original Need for Speed 1 data files (using specs found here) and renders it out in full XNA goodness - 1024x768, anti-aliasing, motion blur etc.
I thought it would be an interesting test - would an amateur using XNA be able to replicate a 10 year old game, which for its time was pretty groundbreaking?)
The jury's still out on that one, but so far I have a complete track and vehicle renderer, complete with animating scenery and skybox.
I am currently working on the car physics, using this as a starting point.
Screenshots of the original game are a bit hard to find, heres one:
Subscribe to:
Posts (Atom)
