That would be awesome! :) While I never played Road Rash, but I have deep respect for the developers for showcasing their 3D road engine very well.... very dynamic, many flowing hill tops, and including solid road side objects.
Heh. What you are seeing is my attempt to remove true perspective and add the false perspective of most racing and driving games of the pseudo 3D era... specifically Out Run. It is hard to model since it uses a basic look up table, though I approximated it. See the prior video. But it ruined the distortion for curves and hills! Now, I need a generic solution for all of this, which is much harder. Easier is to simply support one perspective style and ignore all others!
If you can first consider a flat road, then each scanline (horizontal line) represents a single distance from the viewer. This is true 3D so far. To turn left and right, this is faked by simply sliding the scan lines left or right. Pole Position arcade does this. Now, to get hills, take those scan lines and move them up and down. While this would leave gaps in the display, the engine is smart enough to fill them in. You may note some older arcade games with hills like Super Hang On where, during a hill, the scan lines move so much, and they have to fill in a gap so large, that it ends up looking very pixelated.
The distance the hill is away from you doesn't matter -- the algorithm flows naturally. But perhaps you are asking how does it know where to draw the hill. You may wish to ignore THIS video, since I'm showcasing debugging irregularities with me testing and flexing the engine -- so it's all wrong. But my other videos show something more ideal. Basically, the road has a direction (a momentum, if you will), so when the road is being drawn from the viewer out into the distance, the road can start to move upwards when there is a hill. Then that direction is maintained. So the scanlines keep "moving up" just as if they were an arrow shot into the air with no gravity.
That, my friend, is a great idea. This kind of road scenery can be generated forever. The artwork, not so much, so that would repeat a lot. But the road twists and turns could last hours even manually created, not even procedurally.
Yeah, I just had to share this, even though it's a disaster. :) I do intend to get curves and hills working with the distortion, but I'm not actively working on this project. I'm currently making an engine that will house this (what I now call sub-engine) within it. So I'll be back to it someday later.
Yes, it is drawn with scanlines. The algorithm computes a floating point coordinate for the position of the road in Y, from front to back, and if that screen row is not already drawn, it will draw the scan line of the road in that position. It will be properly scaled in X size and also choose the appropriate texture scanline to show correct perspective and distance.
I'm unsure of the tutorial you speak of, but likely it computes polygons and draws the next section with a textured polygon, filling multiple rows of the screen at once, where the polygon vertices move forward as the road moves. However, it is possible the trapezoid polygons are the same thing I am doing. How so? Because ultimately I have to use the GPU. Since the visible buffer is not constructed in CPU memory, which it could be (and was in my original VGA demo), I draw it directly on the GPU with the same logic. How does one draw a scanline to a screen? You have to render a sprite that is 1 pixel tall, and the screen size in width. (Caveat - the engine will draw as many scan lines as need to fill any gaps, which you can see when the camera is too close to the ground. Normally this happens in arcade engines on hills, but I ensure the road stepping calculations are small enough to avoid this on hills.) How does a GPU draw a sprite? Typically, it is 4 vertices and 2 triangles. So you can picture every scan line as being two triangles, 1 pixel tall, the screen in width.
I just looked at the tutorial and it is doing trapezoids. Also note the page the tutorial is based off of, Lou's tutorial. Scroll to the section called, "3d-Projected Segments vs. Raster Roads". This is where he describes the 3D trapezoids vs the scanlines (which he calls raster).
I need a new Road Rash with this engine :P
That would be awesome! :) While I never played Road Rash, but I have deep respect for the developers for showcasing their 3D road engine very well.... very dynamic, many flowing hill tops, and including solid road side objects.
really good
Thanks! Glad you enjoyed. I need to get the curves working, to really show this off, but it's not so trivial (as you can see!)
ohhh this is so cool!!!
Heh. What you are seeing is my attempt to remove true perspective and add the false perspective of most racing and driving games of the pseudo 3D era... specifically Out Run. It is hard to model since it uses a basic look up table, though I approximated it. See the prior video. But it ruined the distortion for curves and hills! Now, I need a generic solution for all of this, which is much harder. Easier is to simply support one perspective style and ignore all others!
How is the hills effect done? Specially when you can see a hill from far away?
If you can first consider a flat road, then each scanline (horizontal line) represents a single distance from the viewer. This is true 3D so far. To turn left and right, this is faked by simply sliding the scan lines left or right. Pole Position arcade does this. Now, to get hills, take those scan lines and move them up and down. While this would leave gaps in the display, the engine is smart enough to fill them in. You may note some older arcade games with hills like Super Hang On where, during a hill, the scan lines move so much, and they have to fill in a gap so large, that it ends up looking very pixelated.
The distance the hill is away from you doesn't matter -- the algorithm flows naturally. But perhaps you are asking how does it know where to draw the hill. You may wish to ignore THIS video, since I'm showcasing debugging irregularities with me testing and flexing the engine -- so it's all wrong. But my other videos show something more ideal. Basically, the road has a direction (a momentum, if you will), so when the road is being drawn from the viewer out into the distance, the road can start to move upwards when there is a hill. Then that direction is maintained. So the scanlines keep "moving up" just as if they were an arrow shot into the air with no gravity.
Make this a screensaver
That, my friend, is a great idea. This kind of road scenery can be generated forever. The artwork, not so much, so that would repeat a lot. But the road twists and turns could last hours even manually created, not even procedurally.
my brain hurts, but i like it
Yeah, I just had to share this, even though it's a disaster. :)
I do intend to get curves and hills working with the distortion, but I'm not actively working on this project. I'm currently making an engine that will house this (what I now call sub-engine) within it. So I'll be back to it someday later.
This is beautiful
Is this really made using scanlines instead of trapezoid polygons, like the codeincomplete tutorial?
Yes, it is drawn with scanlines. The algorithm computes a floating point coordinate for the position of the road in Y, from front to back, and if that screen row is not already drawn, it will draw the scan line of the road in that position. It will be properly scaled in X size and also choose the appropriate texture scanline to show correct perspective and distance.
I'm unsure of the tutorial you speak of, but likely it computes polygons and draws the next section with a textured polygon, filling multiple rows of the screen at once, where the polygon vertices move forward as the road moves. However, it is possible the trapezoid polygons are the same thing I am doing. How so? Because ultimately I have to use the GPU. Since the visible buffer is not constructed in CPU memory, which it could be (and was in my original VGA demo), I draw it directly on the GPU with the same logic. How does one draw a scanline to a screen? You have to render a sprite that is 1 pixel tall, and the screen size in width. (Caveat - the engine will draw as many scan lines as need to fill any gaps, which you can see when the camera is too close to the ground. Normally this happens in arcade engines on hills, but I ensure the road stepping calculations are small enough to avoid this on hills.) How does a GPU draw a sprite? Typically, it is 4 vertices and 2 triangles. So you can picture every scan line as being two triangles, 1 pixel tall, the screen in width.
I just looked at the tutorial and it is doing trapezoids. Also note the page the tutorial is based off of, Lou's tutorial. Scroll to the section called, "3d-Projected Segments vs. Raster Roads". This is where he describes the 3D trapezoids vs the scanlines (which he calls raster).
@@JDoucette Is your program working the same way or does it work with single scanlines (what lou calls "Raster Roads")
@alexanderriegler2271 Yes, my program renders via single pixel high scan lines... this would be the same as the raster method.