next »

I won't likely be on my computer to test this for a few days, but will try to download it later today (on my phone's browser right now). Since the new version is up, I'll remove and edit out the link to my hosted file now (yay Android FTP app). I'll also keep the new version's zip intact in case you want me to host it as well.

Another weird thing is that if the car gets airborne while it's in gear, the engine usually (but not always) cuts out. This does not happen if the car is in neutral.

BT Raycast Vehicle Constraint, that’s just one of the many annoying little things it does.

Such as when no single raycast (vehicle suspension or wheel), is touching a ground object, or any physical object, no power goes to the constraint.
Or more specifically, the constraint will not activate an impulse for the frames in which this condition is met, else the vehicle could literally accelerate in mid air.

And on the part of my coding, the speed, rpm and engine sound pitch comes from the “wheel rpm“, which is a float property that comes from the distance that the left rear ray travels per frame.
And since all these things are tied to the movement that the raycast constraint detects, and that it will always decelerate when off the ground, everything else goes down as well, (speed, rpm and engine pitch).
There are ways to fake it, (like with the neutral gear), but all the ways I’ve tested conflict with the normal operation of the speedometer, tachometer, and the engine sound.

It’s one of the many problems I’ve been trying to solve from day one.

Well, the easiest way to fake it is to set the engine RPM as though the gearbox was in neutral, but the gearbox actually stays in gear (and the automatic will shift into top gear, regardless of what the engine's doing, for reason I'll give below), and have the speedo display what the speed would be for that RPM in that gear. Of course, in real life the wheels have inertia and gain rotational energy when spinning up in this way, and in theory would dump all of that energy into the car's forward momentum when you hit the ground, but in practice the driveaxles can't transfer that much rotational energy all at once, with the result that the CV joints explode, which (among other reasons) is why you don't jump cars in real life.

But why are you just using the left rear? Shouldn't it be the average of both rears? That's how a differrential works. Incidentally, if one rear wheel is on the ground and the other isn't, the wheel on the ground will be delivering all its torque (which will only be half of the available torque, since an open differential splits torque equally between the two wheels), while the wheel in the air will be spinning freely (wasting the other half of the available torque). In this situation, take the speed of just the wheel that's on the ground, and average it with what the engine RPM would be if it were in neutral (not that whatever the final RPM is that you get from this calculation, this is the figure you use when calculating the available torque). The automatic may or may not change gears in this situation, depending on what the final RPM is.

The automatic gearbox also feels more like an "arcade-style" automatic (where the automatic is the same as the manual except the computer does the shifting for you)

I don’t really understand that part, how could the auto be the same as the manual if the auto has 3 gears, and the manual has 4.
They have different gear ratios, (they'd have too, else the automatic car would only accelerate to about 99mph).
The manual tops out at 123mph, and the 3^rd gear in the MT tops at 99mph, while the auto goes to 108mph max.
I don’t claim to have the gear ratios exact, but I know the auto and the manual are not the same.

But the gear ratios and number of gears is the only difference between the manual and the auto, which is just plain wrong if you're going for realism. The manual transmission in this car is a synchromesh gearbox with a dry clutch, while the automatic (like all automatics from that period) is a hydro-mechanically controlled epicyclic gearbox with a torque converter, which is an entirely different animal. The main differences are:
*A synchromesh gearbox cannot be shifted between reverse and forward gears while the car is moving; an epicyclic gearbox can (don't try this at home). In this respect, your manual transmission is unrealistic, but the automatic is okay.
*An epicyclic gearbox transmits full power during gear shifts (sometimes explained as the gearbox being in two gears at once, but that's a gross oversimplification, and the real explanation isn't worth the time to explain it) and the shift time is typically 200 ms or less - anything more than half a second is a sign the gearbox is broken or is about to be.
*A torque converter transmits full power when the transmission is stalled (ie, the drive wheels aren't moving), whereas a clutch wastes power when slipping (which it has to during stall, otherwise the engine would stop). Additionally, the torque converter acts as a continuously-variable transmission, and provides a reduction ratio (multiplying torque) when there is a large difference between the engine RPM and the transmission RPM, such as when the car is accelerating from a standing start. In the '69 Camaro, this ratio is around 1.70:1 at stall (transmission RPM/engine RPM = 0) and approaches 1.00:1 as the transmission RPM/engine RPM reaches 1. This is the reason an automatic gearbox can get away with having fewer speeds than a manual.
*An automatic shifts to try to maximise the torque at the wheels, which means it will shift up at a lower RPM when the throttle is closed since the powerband is at a lower RPM with a closed throttle. In fact, with the throttle closed completely, the gearbox will actually shift up slightly below the engine's (neutral) idle speed, and will end up in top gear if there's no resistance from the drive wheels (however, the gearbox will stay in first if the drive wheels can't move, since the engine idles at much lower speed with the transmission in gear and the wheels not moving). Most boxes will actually shift down a gear or two when the throttle is opened, then shift up when the throttle is released. Averting the latter scenario (eg to take advantage of engine braking) is the sole reason for the existence of the lower gear ranges.

If you want to see what a realistic automatic transmission looks like, go play Interstate '76. I think there's a free demo version floating around somewhere. It's not 100% realistic, but it's the best implementation of an automatic transmission I've ever seen in a game.

Incidentally, the actual gear ratios for the '69 Camaro L-34 are:
Manual:
Reverse: 2.26;  1st: 2.20;  2nd: 1.64;  3rd: 1.27;  4th: 1.00
Automatic:
Reverse: 2.08;  1st: 2.48;  2nd*: 1.48;  3rd*: 1.00
*2nd gear in this type of gearbox is always (1+First/Reverse)/(1+1/Reverse), 3rd is always 1.00, and 4th (for four-speed boxes) is always 1/(1+1/Reverse)
The ratios in your sim don't seem to be anywhere near these figures.

One more strange bug: there is a place in the map, just past the green building, where you can drive through the side of a hill. Here's a screenshot.

I don’t think your insurance will cover that.
Anyways, I did some work on the land so whatever caused this problem should be fixed.
But out of curiosity, did you back into the hill, or did the car land hard from a jump and go through the ground?

I drove forwards from where the green building is, and went straight through the hill and came out the other side. Turned around, and went at it from the other direction - same thing happens. That's when I took the screenshot. You can approach the hill from any direction and you just go straight through - the ground is totally non-solid. However, there is something solid there, because you don't fall through into the void - you can drive normally, inside the hill. It's bizarre.

...Another weird thing is that if the car gets airborne while it's in gear, the engine usually (but not always) cuts out. This does not happen if the car is in neutral.

Oh, lets not forget the moon gravity too.

I haven't really played it anymore. I think I've offered up enough as it is for Storm Fox to work on, on top of whatever else he had planned. I'm gonna wait until the next release to see how things changed unless I get really bored.

Oh, lets not forget the moon gravity too.

I don't think there's anything wrong with the gravity, I think it's just way too much unsprung weight. The suspension just can't keep the tires on the ground, so tiny bumps send you flying high into the air. It's enough to make you wonder why you even have a suspension...

Actually the gravity might be a little low, the default scale is one meter per unit with a gravity of (9.806 m/s^2).
But some of the vehicle physics were not acting properly when interacting with other objects, including the road surface.
So I ended up building everything at a scale of 2 feet per unit with the same gravity.
(The gravity issue combined with the stiff suspension may be why the cars would get a little squirrely in turns.)

In the new version, I’ve increased the gravity to (13.6342624 m/s^2) though I think the game engine truncates it to 13.634, but in any case it does seem better.

So there is moon gravity! And here I thought it was just the wacky suspension bouncing the car higher than would normally be possible. But, shouldn't the gravity be 16.086 u/s², if the scale is 2 feet per unit? Where'd you get 13.634 from?

I'll give you some feedback on the updated version once I've got the time to download it. Oh, and sorry about the wall of text.

Well, the easiest way to fake it is to set the engine RPM as though the gearbox was in neutral, but the gearbox actually stays in gear (and the automatic will shift into top gear, regardless of what the engine's doing, for reason I'll give below), and have the speedo display what the speed would be for that RPM in that gear. Of course, in real life the wheels have inertia and gain rotational energy when spinning up in this way, and in theory would dump all of that energy into the car's forward momentum when you hit the ground, but in practice the driveaxles can't transfer that much rotational energy all at once, with the result that the CV joints explode, which (among other reasons) is why you don't jump cars in real life.

That makes since, but one of the biggest problems is when and how to get or define that the wheels are off the ground, or vise versa.
The Vehicle constraint can detect this, but the constraint wrapper it’s self doesn’t have a property that I can get the info from, so I'm not sure how define when to use the real rpm, and when to use the fake.

This and a few other reasons are why I’ve been trying to figure out how to port my demo to another system to increase the reach of what I can program.
Something like using the full Bullet physics engine with Blender, so I can make / modify my own vehicle wrapper.
Or use something else like Gamekit, all of which are far easier said than done.

But why are you just using the left rear? Shouldn't it be the average of both rears? That's how a differrential works. Incidentally, if one rear wheel is on the ground and the other isn't, the wheel on the ground will be delivering all its torque (which will only be half of the available torque, since an open differential splits torque equally between the two wheels), while the wheel in the air will be spinning freely (wasting the other half of the available torque). In this situation, take the speed of just the wheel that's on the ground, and average it with what the engine RPM would be if it were in neutral (not that whatever the final RPM is that you get from this calculation, this is the figure you use when calculating the available torque). The automatic may or may not change gears in this situation, depending on what the final RPM is.

I don’t get or set power through just that one wheel, that’s just the wheel that I use to detect the linear speed of the car, and I define my properties from that speed.
The cars power is applied to the two rear wheels along their local Y axis equally.
And since no power is applied to any wheel that’s off the ground, the output power is automatically divided in half when one of the drive wheels is off the ground.

But the gear ratios and number of gears is the only difference between the manual and the auto, which is just plain wrong if you're going for realism. The manual transmission in this car is a synchromesh gearbox with a dry clutch, while the automatic (like all automatics from that period) is a hydro-mechanically controlled epicyclic gearbox with a torque converter, which is an entirely different animal. The main differences are:
*A synchromesh gearbox cannot be shifted between reverse and forward gears while the car is moving; an epicyclic gearbox can (don't try this at home). In this respect, your manual transmission is unrealistic, but the automatic is okay.
*An epicyclic gearbox transmits full power during gear shifts (sometimes explained as the gearbox being in two gears at once, but that's a gross oversimplification, and the real explanation isn't worth the time to explain it) and the shift time is typically 200 ms or less - anything more than half a second is a sign the gearbox is broken or is about to be.
*A torque converter transmits full power when the transmission is stalled (ie, the drive wheels aren't moving), whereas a clutch wastes power when slipping (which it has to during stall, otherwise the engine would stop). Additionally, the torque converter acts as a continuously-variable transmission, and provides a reduction ratio (multiplying torque) when there is a large difference between the engine RPM and the transmission RPM, such as when the car is accelerating from a standing start. In the '69 Camaro, this ratio is around 1.70:1 at stall (transmission RPM/engine RPM = 0) and approaches 1.00:1 as the transmission RPM/engine RPM reaches 1. This is the reason an automatic gearbox can get away with having fewer speeds than a manual.
*An automatic shifts to try to maximise the torque at the wheels, which means it will shift up at a lower RPM when the throttle is closed since the powerband is at a lower RPM with a closed throttle. In fact, with the throttle closed completely, the gearbox will actually shift up slightly below the engine's (neutral) idle speed, and will end up in top gear if there's no resistance from the drive wheels (however, the gearbox will stay in first if the drive wheels can't move, since the engine idles at much lower speed with the transmission in gear and the wheels not moving). Most boxes will actually shift down a gear or two when the throttle is opened, then shift up when the throttle is released. Averting the latter scenario (eg to take advantage of engine braking) is the sole reason for the existence of the lower gear ranges.

If you want to see what a realistic automatic transmission looks like, go play Interstate '76. I think there's a free demo version floating around somewhere. It's not 100% realistic, but it's the best implementation of an automatic transmission I've ever seen in a game.

Incidentally, the actual gear ratios for the '69 Camaro L-34 are:
Manual:
Reverse: 2.26;  1st: 2.20;  2nd: 1.64;  3rd: 1.27;  4th: 1.00
Automatic:
Reverse: 2.08;  1st: 2.48;  2nd*: 1.48;  3rd*: 1.00
*2nd gear in this type of gearbox is always (1+First/Reverse)/(1+1/Reverse), 3rd is always 1.00, and 4th (for four-speed boxes) is always 1/(1+1/Reverse)
The ratios in your sim don't seem to be anywhere near these figures.

I understand what you mean now, though it may be difficult to integrate an auto system like that into my current code.
Also, I’m starting to wonder if I need to rewrite my power-train code from the ground up… If it comes to that, (probably will), I’ll see what I can do about implementing something like this.
(As I'd love to have that real feel sort of thing in a game.)

Also, do you have a source link for the gear ratios you listed?

I drove forwards from where the green building is, and went straight through the hill and came out the other side. Turned around, and went at it from the other direction - same thing happens. That's when I took the screenshot. You can approach the hill from any direction and you just go straight through - the ground is totally non-solid. However, there is something solid there, because you don't fall through into the void - you can drive normally, inside the hill. It's bizarre.

Alright then, that should all be fixed in the new version, because I reworked that entire area.
I was mostly concerned on whether or not the car fell through after a jump, it’s a problem I had when I was using the 1 meter scale.

So there is moon gravity! And here I thought it was just the wacky suspension bouncing the car higher than would normally be possible. But, shouldn't the gravity be 16.086 u/s², if the scale is 2 feet per unit? Where'd you get 13.634 from?

I'll give you some feedback on the updated version once I've got the time to download it. Oh, and sorry about the wall of text.

There’s nothing in Blender that states, or allows me to state what a unit equals, (in Blender 2.49).
But when it comes to the Bullet physics engine that's part of the Blender game engine, it expects 1 meter per unit, and while I can build to any scale, the physics expect 1 meter per unit, and the gravity property expects an input of meters as a float value.
So when the world is scaled larger, so that 2 feet now occupy the space of a unit, or roughly 61% of the expected size of a meter, a meter is now 39% larger in this game world, which is how much I increased the gravity.

2 feet == 0.6096 meters
R = 0.3904 the remainder of the meter that is scaled beyond the size of the standard unit.
G = 9.806 the standard gravity
G + (G * R) = 13.6342624 or (13.634)

16.086 u/s² would only work if the system knew that the scale is 2 feet per unit, but it insists that the value I enter is in meters.




Thanks for taking the time to help with all of this.

Also, do you have a source link for the gear ratios you listed?

http://www.nastyz28.com/camaro/camaro70.php
Although this site is about the '70 Camaro, it uses the same gearboxes as the '66-'69 models (specifically, the Muncie M21 and the Turbo-Hydramatic 400, for the L34 engine (though the Muncie M20 was available as an option in the Z28)).

There’s nothing in Blender that states, or allows me to state what a unit equals, (in Blender 2.49).
But when it comes to the Bullet physics engine that's part of the Blender game engine, it expects 1 meter per unit, and while I can build to any scale, the physics expect 1 meter per unit, and the gravity property expects an input of meters as a float value.
So when the world is scaled larger, so that 2 feet now occupy the space of a unit, or roughly 61% of the expected size of a meter, a meter is now 39% larger in this game world, which is how much I increased the gravity.

2 feet == 0.6096 meters
R = 0.3904 the remainder of the meter that is scaled beyond the size of the standard unit.
G = 9.806 the standard gravity
G + (G * R) = 13.6342624 or (13.634)

16.086 u/s² would only work if the system knew that the scale is 2 feet per unit, but it insists that the value I enter is in meters.

No, a metre is 64% larger in this game world; your calculation doesn't make any sense at all. Yes, it is 0.3904 metres longer than your standard unit, but your standard unit is not 1 metre anymore, it's 0.6096 metres. And 0.6096+0.3904 is 64% more than 0.6096. If you're still confused, think about it like this: 3 feet is 50% longer than 2 feet, right? And a metre is a little bit more than 3 feet. So a metre has to be a little bit more than 50% longer than 2 feet. If you get an answer that's less than 50%, you've obviously screwed up somewhere.

And the system doesn't care about metres or units. When it asks for metres, you can use whatever units you want, as long as you're consistent about it. If one unit (or metre) is 2 feet, then your gravity (and everything else) should be 64% larger.

Oh, and about the sounds: are they pre-recorded, or are you using actual FM synthesis?

http://www.nastyz28.com/camaro/camaro70.php
Although this site is about the '70 Camaro, it uses the same gearboxes as the '66-'69 models (specifically, the Muncie M21 and the Turbo-Hydramatic 400, for the L34 engine (though the Muncie M20 was available as an option in the Z28)).

Thanks.

No, a metre is 64% larger in this game world; your calculation doesn't make any sense at all. Yes, it is 0.3904 metres longer than your standard unit, but your standard unit is not 1 metre anymore, it's 0.6096 metres. And 0.6096+0.3904 is 64% more than 0.6096. If you're still confused, think about it like this: 3 feet is 50% longer than 2 feet, right? And a metre is a little bit more than 3 feet. So a metre has to be a little bit more than 50% longer than 2 feet. If you get an answer that's less than 50%, you've obviously screwed up somewhere.

And the system doesn't care about metres or units. When it asks for metres, you can use whatever units you want, as long as you're consistent about it. If one unit (or metre) is 2 feet, then your gravity (and everything else) should be 64% larger.

*looks at the numbers again*
Well, I just wouldn’t be me if I didn’t screw up something, somewhere.

Alright then, it is 16.086 u/s² *notices that's half of 32.172 ft/s²*

Now, 9.806 is 60.96% of 16.086
But what's the equation used to find that 16.086 is a 64% increase of 9.806 ? (so that I can do this with other values.)

Oh, and about the sounds: are they pre-recorded, or are you using actual FM synthesis?

All the sounds are pre-made audio tracks that are played using either a (play / end), or a (loop / stop) method.
The in game music and the splash screen thunder are made using a virtual triple FM oscillator with various filters, amps, etc.
The horn is made by combining a square wave, with a few offset sine waves.
And the engine sound is a public domain audio effect that I found.

Well, I just wouldn’t be me if I didn’t screw up something, somewhere.

Alright then, it is 16.086 u/s² *notices that's half of 32.172 ft/s²*

Now, 9.806 is 60.96% of 16.086
But what's the equation used to find that 16.086 is a 64% increase of 9.806 ? (so that I can do this with other values.)

Wow, sounds like someone needs more caffeine (or more sleep). You just divide 9.806 (and everything else) by 0.6096 (which is exactly how many metres there are in 2 feet).

Wow, sounds like someone needs more caffeine (or more sleep). You just divide 9.806 (and everything else) by 0.6096 (which is exactly how many metres there are in 2 feet).

Seeing it now is like, ‘how could I not have thought of that‘, but I just couldn’t for the life of me remember at the time.

Oh well, I’m tired… and dumb. …Thanks though.

Finally got to test this out, but only had time to play the GLSL version so far. The physics feel a lot better, but I think Foxpup has you covered on that end.

Xbox 360 controller is still off on a couple of buttons (and I find it odd you made that the default, given the popularity of the PS style controllers ). The opening screen lists the buttons right, but the actual mapping has the shift up mapped to the Back button (Button 7 in the pic you linked earlier), and downshift mapped to the right bumper/button 6. While playing, it also brought up another issue since you'll have to re-map them anyway for the Xbox controller. I don't know about other players, but for me it's natural to use my index fingers for the shoulder triggers as throttle/braking, and my right thumb to shift a manual using the Y(#4) and B(#2) buttons to manually shift up and down respectively. That also leaves open the A(#1) open to be an e-brake if you decide to make that a feature. Like I said, that's just how MY prefered mapping is. I know other people may see things differently. Have you thought about allowing people to do custom mapping within the game like a lot of production games do?

Camera controls work as advertized on keyboard and controller, but the left/right options seem like they need to be reversed. I would say I can understand your line of thinking, such as pressing the left D-pad to look left and vise versa. Only the up and down controls are reversed, so pressing up makes you look down like you're now controling the camera pan instead of the view direction. Personally I prefer the latter, but you should pick one method for both up/down and left/right camera movements.

Ground looks better and the ditches aren't as bad as they used to be. I did find a couple of odd texturing issues. This first one is pretty obvious. You go up against the lands end boarder and at the right angle it will cover up the HUD text.



I also noticed this issue with the background textures overlapping.



And lastly, what's with the invisable bridge?

Grr!! Why does this file hosting service suck so bad?! Okay, so now it doesn't just redirect to the home page, instead it actually has a button labelled "Download This File", which leads to a CAPTCHA, which leads to a big ugly ad asking me to to "Sign Up Now". Also, at the bottom of the page it says the file size is 0KB. Um, what? They just keep asking me to pay $5.00 per month to sign up. And the file is nowhere to be found. I'm beginning to think that FileDropper is some kind of scam (and apparently I'm not the only one).

Still working for me. When I punch in the CAPTCHA and click the download button, it pops up a new Windows dialog box asking if I want to save or simply open the file. While that happens, the main website then changes to the sign up ad for the 7 days free. Clicking that goes in to another page that offers 4 different plans (free, $.99, $5, and $10 monthly). Not sure why you're having that issue, but maybe you have a popup blocker messing with the download popup box? Also, I noticed it says the file size is 0KB too, but it downloaded ok for me regardless.

Uh, the standard download dialog box isn't a pop-up (and in any case it works fine on every other site on the Internet), or are you talking about a different pop-up window? But I'm not seeing any pop-up windows, my pop-up blocker isn't telling me that it's blocked any pop-ups, and disabling it has not effect. Disabling RefControl has no effect either, disabling AdBlock Plus make (even more) ads appear, enabling third-party cookies and disabling Do Not Track has no effect, and changing my JavaScript settings does nothing (except that disabling JavaScript completely renders the "Download This File" button completely inoperative). I've also tried using Konqueror instead of Firefox, and I get the exact same problem.

EDIT: Wait, I got it now.

EDIT AGAIN: False alarm. I only got 770,253 bytes before the download abruptly failed and further attempts to download the file result in nothing but a 404. I am not happy right now.

Uh, the standard download dialog box isn't a pop-up

That's what I was refering to. I know it's not a pop-up as in a new browser window, but sometimes I have those download dialog boxes blocked unless I specifically give a site permission to do so. When that happens, it at least gives me a notice so I can choose to allow it or not. Sorry I can't help you more with that. Like last time, if Storm Fox is ok with it, I'll host it for the time being on my site.

Xbox 360 controller is still off on a couple of buttons (and I find it odd you made that the default, given the popularity of the PS style controllers ). The opening screen lists the buttons right, but the actual mapping has the shift up mapped to the Back button (Button 7 in the pic you linked earlier), and downshift mapped to the right bumper/button 6. While playing, it also brought up another issue since you'll have to re-map them anyway for the Xbox controller. I don't know about other players, but for me it's natural to use my index fingers for the shoulder triggers as throttle/braking, and my right thumb to shift a manual using the Y(#4) and B(#2) buttons to manually shift up and down respectively. That also leaves open the A(#1) open to be an e-brake if you decide to make that a feature. Like I said, that's just how MY prefered mapping is. I know other people may see things differently. Have you thought about allowing people to do custom mapping within the game like a lot of production games do?

Well, I made the Xbox 360 controller the default because it works with windows directly, and the Play Station controller only works if you have an adapter like this one… LINK, it’s not the one I have, but it’s similar, (don‘t know if the mapping would be the same).
And since I figure that most people don’t have the adapter, I made the Xbox the default.

And as for the mapping, I’m not sure what to say, as far as the code goes, everything is correct.
06 for gear_up
05 for gear_dn
07 for gear_up_ps
06 for gear_dn_ps
And the ps_ctrl property is set to false on startup so… I’m not sure what to say, it sounds like you're on the PS controller setting.
Is there any possibility that you hit your F2 key, or that the key's stuck down?
Also, while you shouldn’t have to, did you try pressing the F1 key while on the track?

Also, yes, custom mapping is in the future plans.

Camera controls work as advertized on keyboard and controller, but the left/right options seem like they need to be reversed. I would say I can understand your line of thinking, such as pressing the left D-pad to look left and vise versa. Only the up and down controls are reversed, so pressing up makes you look down like you're now controling the camera pan instead of the view direction. Personally I prefer the latter, but you should pick one method for both up/down and left/right camera movements.

I think I get that from working with airplanes and such, (in video games, radio controlled models, etc.)
But I’ll keep that in mind for future versions.

Ground looks better and the ditches aren't as bad as they used to be. I did find a couple of odd texturing issues. This first one is pretty obvious. You go up against the lands end boarder and at the right angle it will cover up the HUD text.

I need to make the HUD a separate scene, and then overlay the HUD scene onto the game scene, that will fix this problem.
The only reason I haven’t done this yet is because I haven’t put a global configuration dictionary into the system yet.
Once I get that done, the HUD issue will be fixed, and also adding a key mapper, car chooser, car color chooser, etc. will also be possible as I'll be able to pass properties and config settings between scene.

I also noticed this issue with the background textures overlapping.

I’m still trying to figure that one out, it’s got something to do with the way alpha textures are rendered…

And lastly, what's with the invisable bridge?

That’s just a shortcut I use during debugging, I figured I’d leave it in the demo for you guys to play with.

@ Foxpup

I checked the link you posted and read the comments there, and I have to say that I’m surprised.
As having my download removed early was the first and only problem that I’ve ever had with them.

And I really don’t know what to tell you, as it works fine for me, so it’s either a setting on your machine, (like a blocked element, blocked cookie, disabled feature, etc.) or it’s a country / region issue.

Sorry I can’t do much about it…

@ Narei Mooncatt

Like last time, if Storm Fox is ok with it, I'll host it for the time being on my site.

Yes you can do that, here are the file hashes to mach…

File Hash SHA-1: 4DF225385D3DF88DCA3FF6EE13123F74930EE28F
File Hash MD5: 07D3E1B0869AC38B29EF3D8D60BEA58C

…and if either of you two know of a host site that's good, let me know and I'll see if that works better for everyone next time.

Thanks.

I'll check the Xbox/PS setting more tonight when I have time. I do know that I also tried pressing F1 in case it was somehow set to the PS mapping and that didn't change anything.

And here's the link for the current version:

http://www.thefoxydj.com/SFdemo/DPD_0-0-4-3-a_by_SFS.zip

(congrats, you got your own folder. )

Thanks, Narei. I owe you one. (hash matches, by the way)

As for free file hosting sites, they're all pretty unimpressive in one way or another (usually any two of obnoxious advertising, delayed downloading, or severely restricted download speed). Web hosting can be a good way to host files if you have an actual web site about said files (most free web hosting companies get really angry for some reason if you just upload a bunch of huge files and no website).

Web hosting can be a good way to host files if you have an actual web site about said files (most free web hosting companies get really angry for some reason if you just upload a bunch of huge files and no website).

I do this with Google Sites with an absurdly minimal webpage as the "site", and as much as it is an inappropriate tool for the job, it works pretty well for me.  On the other hand, the largest file I've hosted thorough it was about 19MB; your file is somewhat larger than that.

Also, Narei, you probably meant to link here.  I looked at the source of your post, but I'm not quite sure why your link didn't work.

Also, Narei, you probably meant to link here.  I looked at the source of your post, but I'm not quite sure why your link didn't work.

The forum will automatically put "http://" in front of anything that looks like a link (even if you don't use the [‍url‍] code), regardless of whether this makes sense or not, and as far as I can tell there's no way to disable this "feature" (I had the same problem trying to post an FTP link).

Found the problem. I capitalized the "H" in the http part of the link. For some reason, that caused the forum to add another http:// in front of my link, making it start http://Http://.

I made that "H" lower case and that seems to have fixed the problem. Thanks for pointing that out.

The new version feels much better, though the CG still seems way too low. Also, the graphics engine doesn't seem to be z-sorting transparent polygons properly or at all (the correct way to render transparent polygons is to sort them by z-depth, then render them back-to-front with the z-buffer disabled after rendering all non-transparent polygons - it seems your graphics engine isn't doing the first step correctly).

I have also identified the cause of the "cars driving through hills" phenomenon: inconsistent tessellation of non-planar faces on the terrain mesh. Consider this object:

There are two possible ways to tessellate the indicated face, resulting in either a concave or convex surface:

Your physics engine is creating concave surfaces from non-planar faces, resulting in a solid but invisible valley; while the graphics engine is creating convex surfaces from non-planar faces, resulting in a visible but non-solid hill. Attempting to drive over the hill results in the car going straight through the hill into the invisible valley. The new version still has this problem (and in the exact same place as the old version), and there are several other places all over the map with this problem as well.
As I recall Blender has a "Convert Quads to Triangles" option which will fix the problem (you only need to do this with the terrain mesh, you can still use quads for everything else without any (major) problems). You shouldn't even be using quads for terrain anyway for exactly this reason.

I'll check the Xbox/PS setting more tonight when I have time. I do know that I also tried pressing F1 in case it was somehow set to the PS mapping and that didn't change anything.

Please let me know if you find anything more on that, I know I checked and tested the code at least four times before I released the demo.
*checks the released version again* and everything works as it should…

…Try the left and right stick clicks on your controller, if the left sounds the horn and the other buttons are still wrong, then something is just simply all together wrong, (in my code, with your driver, something else, etc.)
But if the right stick sounds the horn, then you are on the PlayStation controller setting.

As for free file hosting sites, they're all pretty unimpressive in one way or another (usually any two of obnoxious advertising, delayed downloading, or severely restricted download speed). Web hosting can be a good way to host files if you have an actual web site about said files (most free web hosting companies get really angry for some reason if you just upload a bunch of huge files and no website).

Web hosting can be a good way to host files if you have an actual web site about said files (most free web hosting companies get really angry for some reason if you just upload a bunch of huge files and no website).

I do this with Google Sites with an absurdly minimal webpage as the "site", and as much as it is an inappropriate tool for the job, it works pretty well for me.  On the other hand, the largest file I've hosted thorough it was about 19MB; your file is somewhat larger than that.

Perhaps I’ll figure something out… and I doubt that Google would like me very much as I could drop a gigabyte on them in an instant.
Anyways, thanks for the input.

Also, the graphics engine doesn't seem to be z-sorting transparent polygons properly or at all (the correct way to render transparent polygons is to sort them by z-depth, then render them back-to-front with the z-buffer disabled after rendering all non-transparent polygons - it seems your graphics engine isn't doing the first step correctly).

Fixed.

I have also identified the cause of the "cars driving through hills" phenomenon: inconsistent tessellation of non-planar faces on the terrain mesh. Consider this object:

There are two possible ways to tessellate the indicated face, resulting in either a concave or convex surface:

Your physics engine is creating concave surfaces from non-planar faces, resulting in a solid but invisible valley; while the graphics engine is creating convex surfaces from non-planar faces, resulting in a visible but non-solid hill. Attempting to drive over the hill results in the car going straight through the hill into the invisible valley. The new version still has this problem (and in the exact same place as the old version), and there are several other places all over the map with this problem as well.
As I recall Blender has a "Convert Quads to Triangles" option which will fix the problem (you only need to do this with the terrain mesh, you can still use quads for everything else without any (major) problems). You shouldn't even be using quads for terrain anyway for exactly this reason.

I’m very familiar with that problem, as it occurs a lot in low poly modeling.

I went back and checked the area, the ground is completely solid, and the car follows every contour, granted that there are mesh alignment problems in version 0.0.4.2a, but it’s still solid, and I can’t find any of these problems in version 0.0.4.3a.

I think this is the spot that you meant…

In the picture you can see that my version renders properly, (the physics match the graphics).
And I can see how this spot could go either way, but nevertheless my computer renders it properly.

Do you think it’s possible that your graphics card is simply rendering things differently than mine?
Because that's what it seems like, and I don’t see any of these problems in my version at all.

In the picture you can see that my version renders properly, (the physics match the graphics).
And I can see how this spot could go either way, but nevertheless my computer renders it properly.

Do you think it’s possible that your graphics card is simply rendering things differently than mine?
Because that's what it seems like, and I don’t see any of these problems in my version at all.

It's definitely rendering things differently to yours. Here's another screenshot, which clearly shows the "incorrect" tessellation. I'm using "incorrect" in quotation marks because there's no right or wrong way to process this kind of geometry. You cannot trust the hardware to do what you want it to do, because it has absolutely no way of knowing what you wanted. It could split the quad into two triangles one way, or the other way, or it could even split it into four triangles, with an extra vertex in the centre of the quad. The fact that your hardware happens to do it the "correct" way is really just a coincidence. In order for it to work correctly in all cases, you need to tessellate the mesh in software, at least until AMD finally perfects their new Telepathy Processors.

I guess I’m going to have to make most / all the ground polygons into triangles, but that’s going to increase the ram requirement.

And I’m looking at your screenshot… it looks like the sky-dome is clipping out in the distance.
Does it always do that when you play the new version?

Because I made sure that the view distance was long enough in order to prevent that, and it doesn't happen on my computer.

And I’m looking at your screenshot… it looks like the sky-dome is clipping out in the distance.
Does it always do that when you play the new version?

Because I made sure that the view distance was long enough in order to prevent that, and it doesn't happen on my computer.

Huh. I never noticed that before. It looks like it only happens with camera 2, which I used to take the screenshot. Are you sure you set the far clipping plane properly on all the cameras?

*checks*
No I didn’t… *sigh*

(To rephrase what I said earlier, it doesn't happen on my computer, …when I use camera 1.)

In other words I missed it, cam 2 is set for 1100 units… it should be 2500 units.

And I probably wouldn’t have found it without your screenshot, so, thanks.

Try the left and right stick clicks on your controller, if the left sounds the horn and the other buttons are still wrong, then something is just simply all together wrong, (in my code, with your driver, something else, etc.)
But if the right stick sounds the horn, then you are on the PlayStation controller setting.

I tried letting it pick the default, and manually pressing F1 for the Xbox controller and in both cases the right stick click activated the horn. When I pressed F2 for the PS setting, neither stick activated the horn. In fact, none of the buttons on my controller did, so I know the default/F1 is supposed to be the right one for me. I did notice something though...

And as for the mapping, I’m not sure what to say, as far as the code goes, everything is correct.
06 for gear_up
05 for gear_dn
07 for gear_up_ps
06 for gear_dn_ps
And the ps_ctrl property is set to false on startup so… I’m not sure what to say, it sounds like you're on the PS controller setting.
Is there any possibility that you hit your F2 key, or that the key's stuck down?
Also, while you shouldn’t have to, did you try pressing the F1 key while on the track?

Can you explain what the difference is between the gear_up and gear_up_ps? And same for gear_dn. I'm guessing PS means PlayStation, but I meant in terms of the mapping in the demo. I thought it odd that you have button 6 mapped twice (unless that was a typo in the quoted section). Buttons, 6 and 7 are the right bumper and back button respectively on the Xbox controller. So button 7 is corresponding to the gear_up_ps and is the only thing mapped for the button. Button 6 seems to have 2 functions mapped to it, and for whatever reason is choosing to correspond itself to the gear_dn_ps instead of gear_up. So perhaps however you have the mapping set up is causing conflicts with the controller picking the wrong action to do?