Tips For Driving Games [curves, books on theory]?

[eugenetswong]

Do you have any suggestions on what needs to be done for driving games like "Enduro"?

 

1) The curves in the road seem reasonably accurate to real life, and I expected that I would need trigonometry. I don't know, though. I read somewhere that it is good to use tables, instead of math. Since I plan on doing that, should I just go all the way, and eyeball the shape of each bend in the road? That doesn't seem right, according to my intuition.

 

2) I see that there is a great book on how develop an adventure game, but what about a driving game? Perhaps there is a magazine article? Even if you don't remember the name of the article, perhaps the article was in "Compute"?

 

3) I think that Enduro on the Atari 400 would be wise to use mixed graphics modes and horizontal scrolling; graphics 9 for the background mountains.

[Rybags]

Modern day racing games use normal 3D techniques as you'd also see in an FPS.  As you probably know that produces the most realistic simulation.

 

We can't really do that on our old systems though it would be reasonable to try to use such a technique just for the edges and centreline of the road.

Pole Position is probably the best looking insofar as the rendering of the road.  It uses LMS per scanline, fine HScrolling and a pre rendered road where the viewpoint of each line is simply changed to produce each type of feature.

Though of course it's not a "correct" way of rendering but produces a believable result.  But does come with limitations such as you can't stray from the road much, the viewpoint will always be close to straight ahead, ie you can't spin out and end up facing the other way.  And possibly the biggest limitation is since each scanline is shifted relative to the previous one, you can't easily render other objects onto the playfield - the other cars are 2 Players overlayed and the signs are missiles.

 

The scenery - yes, generally there's no interaction or overlay with the action so you can do a parallaxed fine scrolling mountain + cloud scene.

[popmilo]

Here  is a link to a holy Bible of how to make pseudo 3d racer :

http://www.extentofthejam.com/pseudo/

 

And one of nice follow-ups with code:

https://codeincomplete.com/posts/javascript-racer/

 

 

[eugenetswong]

Thanks, guys!

 

I'm amazed at how much you guys know. I don't understand where you get it from. Maybe you read the same books.

[eugenetswong]

Also, Rybags's comment really explains a lot of what I never fully appreciated about in old vs. new games. In other words, I knew that it looked better, but never understood why it was better; for example, being able to deviate from the track, or being forced to turn our car around after a spin out.

[Rybags]

Another few psuedo 3D games to look at are Vroom and the Lotus Challenge games - they're probably the best of type on home systems and have elevation change as well.

Edited March 7, 2020 by Rybags

[eugenetswong]

12 hours ago, popmilo said:

Here  is a link to a holy Bible of how to make pseudo 3d racer :

http://www.extentofthejam.com/pseudo/

 

And one of nice follow-ups with code:

https://codeincomplete.com/posts/javascript-racer/

 

 

Okay, so I've read through it, and had such difficulty understanding the terminology, that I started skimming at about 3/4 of the way down. There is so much terminology, that I don't think that programmers, who are new to game programming can understand it.

 

###

 

Atari sprites are narrow. How would they be used in road rendering/construction?

[Yaron Nir]

22 minutes ago, eugenetswong said:

Atari sprites are narrow. How would they be used in road rendering/construction?

You can construct a player from 2 HW sprites with 3rd color

use the same method to create one more competitor 

OR use software sprites where you blit those on screen (maybe with different color to differentiate competitors)

 

if your game is racing one more opponent then use HW sprites

if your game has more opponents then use software sprites 

[emkay]

What is that thread about , exactly?

What "Enduro" game is it about?

And why do people still point to other computers and solutions that work only on other computers?

 

Such games can get very fluent and keep good details.

 

 

 

 

[Wrathchild]

I wouldn't say its been done to death already but there has been a fair degree of discussion.

So I'd concur with the javascript link that @popmilo posted is a good read.

 

 

 

 

[eugenetswong]

7 hours ago, Yaron Nir said:

You can construct a player from 2 HW sprites with 3rd color

use the same method to create one more competitor 

OR use software sprites where you blit those on screen (maybe with different color to differentiate competitors)

 

if your game is racing one more opponent then use HW sprites

if your game has more opponents then use software sprites 

I realize that we can use sprites for other players, but I don't see how a sprite or PM graphic can be used in constructing part of a road. Maybe assembly must be used to draw during the horizontal refreshing.

[eugenetswong]

emkay, I don't understand what you are asking. I assume that you are asking rhetorical questions of other people?

 

Wrathchild, thanks for the links. I'm so new to this. I never looked at the JavaScript stuff, because the first link seemed to be a prerequisit, and it seemed too hard. I'll check the JavaScript page and the other stuff now.

[eugenetswong]

Wraithchild, thank you for the links. I think that  I am too new to understand any of this. I don't know where to begin. I'll focus on making a simple straight road, unless somebody suggests otherwise.

 

Any "hello world" type suggestions would be helpful.

 

Just for the record, I haven't even used PM graphics yet.

[Flojomojo]

It would be interesting to see a simple (by necessity, because 8-bit) driving game that incorporated physics of gravity and suspensions. I don't think modern games did this until Gran Turismo on the PlayStation. It really changes the whole feel of simulated driving. 

[R0ger]

Don't want to discourage people, but there is reason why there is so few games like this on Atari. It is complex subject. As for the theory, all is presented in great detail in the link Popmilo posted:

http://www.extentofthejam.com/pseudo/

 

If you want to apply this on Atari though, you will need assembler, kernel code and/or DLIs, and very good knowledge of the hardware. Anyway, I would recommend writing it on PC in language of your choice first, to get more familiar with the problem, and simply to avoid assembler testing as much as possible. You want to know number ranges for all variables, test how different options will look, and you will also be able to estimate how fast it will be on Atari based on number and types of operations used.

[Rybags]

Such a game isn't what I'd suggest as a beginner's project.

 

A hello world version might be something like the Grand Prix game I did in the 80s.  It uses a Player for the car and the track is by printing with insert line commands.

Though somewhat simplistic and 100% Basic.

 

http://www.atarimania.com/game-atari-400-800-xl-xe-grand-prix_27524.html

[emkay]

10 hours ago, eugenetswong said:

emkay, I don't understand what you are asking. I assume that you are asking rhetorical questions of other people?

 

Partly.

 

Is it this game, this thread is about?

 

 

 

 

There are also other "Enduro" games.

 

 

 

 

 

The posted links are not very useful, as the Atari has restrictions. The Motocross demo shows the right way. Possibly Gorgh (the coder of it) will add some words.

On the 2600 the framerate is very good. That's why it seems very playable.

 

[NRV]

14 hours ago, Flojomojo said:

It would be interesting to see a simple (by necessity, because 8-bit) driving game that incorporated physics of gravity and suspensions.

That sounds a lot like...

 

 

 

[Flojomojo]

Heheh, yes it does. I was thinking along the lines of simulation-style detail on going around plain loops, like Gran Turismo, but this is infinitely more entertaining. 

[+Stephen]

6 hours ago, emkay said:

The posted links are not very useful, as the Atari has restrictions. The Motocross demo shows the right way. Possibly Gorgh (the coder of it) will add some words.

On the 2600 the framerate is very good. That's why it seems very playable.

Man - that sure looks fun.  We could use some bike racing games on the Atari

[eugenetswong]

 

On 3/8/2020 at 6:52 AM, emkay said:

Partly.

 

Is it this game, this thread is about?

 

 

Yes, that is what I was thinking about.

 

I'll be happy with a first step of just drawing 2 lines for a side of the road.

Edited March 19, 2020 by eugenetswong

[eugenetswong]

Somebody [not me] on reddit asked about camera angles for driving games. I want to copy and paste the link here for my future reference, and for anybody else in the future.

 

[eugenetswong]

I can't seem to stop thinking about this. If you all could look over the following thoughts and notes to confirm my learning, then I would appreciate it.

 

• He uses Delta Delta Z, Delta Z, & Z, to represent acceleration, speed, and position. He is using layman's terms to briefly talk about Calculus.
• To calculate Y on the screen, we can let our eyeballs be a distance of 1 from the bottom of the screen, and Z_Dist from the object. We can divide the Y in world by the Z in the world, and then add half of our screen resolution to get the Y pixel.

I'm still having a difficult time understanding how he calculates 640 or 639, when he puts an object at the right side of his field of view on his 640×480 screen. He said this.

Quote

x_screen=640

fov_angle=60

y_world=sin(60/2)

z_world=(60/2)

x_resolution/2=320

scaling=?

x_screen = (y_world*scaling)/z_world + (x_resolution/2)

640 = (sin(30)*scaling/cos(30)) + 320

320 = tan(30)*scaling 320/tan(30) = scaling

 

In generic terms: scaling = (x_resolution/2) / tan(fov_angle/2) We've replaced a/2 by 30 (half of 60 degrees), recognized that sin/cos = tan, and voila! We should be able to test this by placing an object at the right edge of the field-of-view, plugging these values into the original projection equation, and ensuring that the X value winds up as 640. For example, an (x, z) point at (20, 34.64) will wind up at X=640 because 20 is 40*sin(30) and 34.64 is 40*cos(30).

I should be able to do this, because his formula is hardware independent, and doesn't require movement to use the math.

 

I did this.

20/34.64=0.5773672055

Tan(30)=0.5773502692

 

Is he rounding off to the 4th decimal place?