Hey all,



This is the sort of effect I'm looking for, with the sides of the buildings being properly projected. Is this relatively quick enough to calculate in software? I'm more than willing to make a number of compromises regarding size, shape, anything really. I can't seem to find any articles on the subject, of course "GTA style buildings" isn't exactly the pinnacle of google fu.

Thanks!

Why are you trying to avoid 3D acceleration? This is pretty trivial using OpenGL or DirectX. Writing your own software renderer is a fairly monumental task and 3D hardware has been standard on PCs for about 15 years now [smile]

-me

You can definitely do it, since the road, which makes up something like 1/3-2/3 of the pixels on screen at any given time, is always planar and perpendicular to the view vector.

Quote:Original post by outRider
You can definitely do it, since the road, which makes up something like 1/3-2/3 of the pixels on screen at any given time, is always planar and perpendicular to the view vector.

But the buildings aren't and they translate with proper perspective parallax (at least I'm assuming they do, if it just snaps to another screen when you hit the edge then nevermind).

To get perspective & parallax without hardware acceleration i that case would require using or writing a software renderer. If you're using someone else's software renderer it's definitely no harder than using OpenGL and if you're writing your own it's definitely harder. Which is why I asked why he was avoiding using hardware acceleration.

-me

Yes, I realize that. His question was whether or not it was 'quick enough' and given the constraints of his scene there are shortcuts that can be taken. I'm not really concerned about why he wants to go the software route, unless he wants to elaborate on his choice and ask for opinions on it.

I guess the keyword you're looking for is "ray casting" -- the same principle used in Wolfenstein 3D, Doom, Duke Nukem, etc, which used "faux 3D" to render environments.

You could also look up "mode 7," the principle used in games like F-Zero and Mario Kart to display tracks with perspective.

Ultimately, you'd be rendering "billboards" in software, using basic calculations to skew sides of buildings... No complex depth calculations needed...

The key observation that makes it feasible to draw that kind of scene in software even on very modest hardware is that the polygons you are trying to draw all have the feature that either horizontal or vertical lines have constant depth.

Let's look at a wall that runs left to right, for instance. Its projection looks like a trapezoid, and you can loop over the horizontal scanlines that form it. You have some texture that you want to apply to the wall, and on a given scanline the coordinates that you have to sample on the texture are equally spaced, so the tight loop that goes over the pixels of the scanline and selects a color for them has very little work to do and can be executed extremely fast.

Sorry I posted before heading out -- I'm looking to implement something similar in a Flash game, specifically targeting Flash Player 9, which doesn't have any hardware acceleration at all.

Polygon rasterization based on Bresenham's algorithm.

- View-project edges of 3D shapes. (trivial, parallax, shift by height)
- Order them top-to-bottom
- For each scanline
-- select the texture belonging to edge
-- texture map until edge is reached (can do filtering as well


If you take one of higher scanlines (slightly below yellow number 50):

// edges from rasterization via bresenhamR     F           S   R    <- rendering this line R      F           S  RR       F           S R// filling in from leftRRRRRRF           S   RR      F           S  RR       F           S R// when doneRRRRRRRRFFFFFFFFFFFFSSRRRRRRRRRRRRR      F           S  RR       F           S RR = road textureF = building front textureS = building side texture

Well, the best ASCII art will allow. Understanding how top-to-bottom triangle rasterization with texture mapping works helps.

The obvious problem here is how to know how far a texture will go. That's fairly easy to determine - it's a function of height, sort of Zbuffer. It can be computed as part of rasterization. It can be further simplified if all 3D objects can only exist at predefined grid points. Such as city blocks here, so base of map is fixed NxN squares.


There existed many examples of absurdly efficient texture mapping algorithms, but in an era long gone for hardware long forgotten.

However, all of this can be implemented using single-pass and integers only. It could be done in real-time back on 386. Then there's tons of hacks on how to add shadows, layers and other effects.

Quote:I'm looking to implement something similar in a Flash game, specifically targeting Flash Player 9, which doesn't have any hardware acceleration at all.

Sadly, the techniques originally used cannot be effectively implemented in Flash. Lack of arrays (linear memory), lack of efficient rasterization, generally bulky numeric support.

Flash does however support bulk triangle rendering which is *more* than capable of drawing dozens of textured triangles. So there is no need for low level hacks. See PaperVision3D.

And new version of Flash will come out with full GPU support.