poll:outrun for msx2

Page 3/11
1 | 2 | | 4 | 5 | 6 | 7 | 8

By hamlet

Scribe (2420)

hamlet's picture

02-06-2019, 17:52

Quote:

Penguin Adventure? Smile

Haha! That's true. Penguin Adventure was my first racer on my first Sony.

By SLotman

Paragon (1211)

SLotman's picture

02-06-2019, 19:15

There is a 'fixed' version of Weclemans (by Martos if I recall correctly) out there that running on turbo-Rs (or machines with 7mhz) is quite good.

Also, Greatest Driver.

By wolf_

Ambassador_ (9766)

wolf_'s picture

02-06-2019, 20:03

Makes you think, huh. Shouldn't the scene take this up? To make a convincingly smooth 3D racer with hils, full-screen'ish? With V9990, 9958 or 9938. Just to see whether this bunch of 40+yo nerds can do what the companies couldn't back then. Running Naked in a Field of Flowers

By NYYRIKKI

Enlighted (5325)

NYYRIKKI's picture

03-06-2019, 18:32

Grauw wrote:

F1 Spirit 3D Special?

https://youtu.be/SE-SHwV5v2M

Uses splits and horizontal scrolling… Would be nice if someone could fill in more details, e.g. for the hills do they use vertical scrolling (doesn’t that give sprite issues), or is the middle part in screen 4?

Yes it does :) If you look closely you can see this is a problem. The hill starts only before your car nose is drawn, cars further away lose top of them etc. This is for sure one reason, why the cars are not any more higher profile.

By PingPong

Prophet (3417)

PingPong's picture

03-06-2019, 20:00

I think that using even a msx1 it is possible to have a fast + colorful road in screen 2.
each of the three sections of the screen is 256 (bytes) tiles. one can write 512 tiles easily on vblank even on msx1
the issue is how to create a fast algo that get the correct tiles to put on screen to create the road layout based on curves, hills etc.

Any idea on making some concept?

By theNestruo

Expert (106)

theNestruo's picture

03-06-2019, 20:09

PingPong wrote:

the issue is how to create a fast algo that get the correct tiles to put on screen to create the road layout based on curves, hills etc.
Any idea on making some concept?

I described an algorithm in a previous post within this topic! :_D

By wimpie3

Master (254)

wimpie3's picture

03-06-2019, 20:25

In the behind the scenes look of XRacing, you can see how a heavily optimized tileset is used for the flag animation' I bet straight and curved roads can be optimized through the same procedure.

By ARTRAG

Enlighted (6229)

ARTRAG's picture

03-06-2019, 21:46

PingPong wrote:

I think that using even a msx1 it is possible to have a fast + colorful road in screen 2.
each of the three sections of the screen is 256 (bytes) tiles. one can write 512 tiles easily on vblank even on msx1
the issue is how to create a fast algo that get the correct tiles to put on screen to create the road layout based on curves, hills etc.

Any idea on making some concept?

Just encode in asm the code at:
http://www.extentofthejam.com/pseudo/
or, even better, use that code to pre-render the frames of all possible road turns and hills and just update tile sets and pattern name tables to animate the road and its transitions...

By JohnHassink

Ambassador (5400)

JohnHassink's picture

04-06-2019, 02:47

Once tried my hand at re-imagining the music for MSX OPLL (as I feel a true remake, or even the original version should have had). Found out that it's pretty hard. Smile
https://youtu.be/WiH1GU6JOlY

By TomH

Champion (327)

TomH's picture

04-06-2019, 19:39

Many thoughts to contribute:

Outrun isn't just a lazy port of a Spectrum title, it's a lazy port of a poor Spectrum title. And not just with hindsight. To quote one of the reviews of its rerelease: "I just can't walk past an Out Run arcade machine without sticking 20p in. With this version though, you'll be lucky if you can stand having a second go. The graphics are not too bad but it's thing like speed, the multi-load and music that let it down."

Chase HQ is an amazing port over in Spectrum and Amstrad world, but probably still not the most accomplished 8-bit driving game; I'd award that to the Master System version of Road Rash. The perspective is correct, hills abound, and the camera isn't glued to a path.

The maths behind that sort of game is fairly easy and needn't involve floating point. It's just trigonometry really. If the road were perfectly straight and flat then let y be the viewer's height from the floor and a be the angle between the viewer's centre of vision and the current scan line (which is just a value you'd pull from a 192-entry lookup table for a 192-pixel-high screen).

Then for each scan line you're interested in two unknowns: (i) the distance to the floor directly from the viewer (for sizing); and (ii) the distance along the floor from the point immediately below the viewer (for palette selection). Call them (i) = d, (ii) = b.

Well, in the pretend triangle involving the viewer's position, the point directly below them on the floor, and the point in this scan line, (i) is just the hypotenuse of that triangle, and (ii) is the base.

So: tan(a) = b/h, sin(a) = b/y, cos(a) = y/h.

Therefore: b = y*sin(a). Well, you had a lookup table for a. Keep a lookup table for sin(a). Cost to compute in real time: one multiply per line. Can be 8x8 for the old a*b = ((a+b)^2 - (a-b)^2)/4 lookup trick. Very cheap.

Just to take a quick step back on h: what you actually want to compute is likely to be 1/h, to get width of that part of the road in pixels. Well, there's a bunch of ways to get it: cos(a)/y, tan(a)/b, or even 1/(b*sin(a) + y*cos(a)). You're going to have a pay for a divide.

Also there'll be barrel distortion on that because you're then working out distance from a point rather than distance projected onto a plane. So you'll actually need also to multiply your computed 1/h by cos of the viewing angle. This comes out of another 192-entry lookup table. So it costs one extra multiply per line.

So, if camera height off the ground is a variable: two multiplies and one divide per screen row.

If you fix camera height: no arithmetic. It's just lookup tables as a function of angle. You can still rotate the camera freely around the x-axis.

This is still assuming a flat, straight road. Add a skew that's a sinusoidal function of b for corners. Definitely don't go past the first quarter of a sine curve across whatever depth you're drawing.

And remember how you can freely rotate the camera? Option one is to do that slowly for gradual hills. Option two is to maintain a forward list of angled segments. You pay for an extra dot product per segment on display, but it's still a linear front-to-back process. Option three is just to crib an idea from voxel height maps, and compute a height per scan line, drawing as much or as little as is visible from their base to the current water line. This can introduce resolution issues close to the camera though.

Drawing? Do it as partial updates. Per scan line you end up with "road was size s2 at centre x, is now size s2 at centre x2". Usually working out the minimum redraw isn't very hard. I'd dare imagine you can then just overprint roadside objects, letting them stick to precomputed sizing and an 8x8 grid, and do the vehicles as sprites.

Page 3/11
1 | 2 | | 4 | 5 | 6 | 7 | 8