# 3D rasterisation

Pagina 4/4
1 | 2 | 3 |

Right — if you're ray casting then doing conventional perspective is actually a little more expensive, at one extra multiply per column. If a pet peeve stemming from all raycasters that I have ever seen isn't too off-topic: the thing people usually get wrong there is thinking that if you want to cover an x degree field of view in u pixels then angles should be picked through a linear scaling of x to u. When people have made that mistake you usually see them pick a small field of view, because the error is smaller, and still have things be slightly sickeningly-distorted towards the edges. The correct thing to do is to think about the right-angled triangle each cast ray makes from viewer to screen, and get the angle from that. So it's an arctan thing. And then just a lookup table. No extra processing cost for getting it right.

My more helpful reason for returning is that I realised my previous comment about an odd-shaped lookup table for polygon edge scanning (or line rasterisation for an MSX1, I guess) is hokum because you've two values to store and each table is triangle-shaped. So you can just flip one and push them together.

Suppose you're limited to a 192x192 drawing area. Then the lookup table is 36kb, and when |x| > |y| the algorithm looks something like:

address = (|x| * 192) + |y|    // with shifting rather than an actual multiplication, obviously

x1 += (quotient >> 1)
error = y
while(y1 != y2) {
output(x1, y1)

error -= remainder
if(error < 0) {
error += y
x1++
}
x1 += quotient

y1++
}

Typed extemporaneously. Check before use. You'd probably have four variations for the four arrangements of incrementing and decrementing x and y, and have ended up with |x| and |y| in picking one.

The |y| > |x| version instead outputs either quotient or quotient+1 locations downward from (x1, y1) before incrementing x1 (and have four arrangements of that).

If you're on an MSX1 or any other machine without hardware line drawing then to draw a line, don't seed x1 to halfway across a span, and draw all the spans. Make sure you handle x = y, x = 0 and y = 0 as special cases.

Nice port of the wireframe 3D intro of Silpheed to MSX: https://youtu.be/fYyeU7QZhFE

Using 512x212 resolution! Not sure whether it’s screen 6 or 7, but if it’s drawn with LINE VDP commands then there wouldn’t be much of a performance difference anyway.

(For comparison, the PC version: https://youtu.be/3n4nOiURgzg)

Very impressive. Doesn't look like it uses more than 4 colors, though. I imagine it uses page-flipping to avoid flickering and tearing. Maybe it uses the extra available pages in SCREEN 6 to store the background graphics?

The first one looks a lot smoother… Does anybody know why?

Google translate of the description of the first video:

Quote:

Hey, it seems that Silpheed was scheduled to be released on MSX! This is that demo!

… It's April Fool's Well! That's too bad! Huh…? Already in June …?

T Sato was created, “I tried playing the wireframe of Silpheed OP with BASIC's one screen program.”
Looking at, I made it because I thought “How fast do you get out of MSX?”
Except for wire frame data and fonts, it is an eye / ear copy.
To be a bad thing, it will not work unless the primary mapper is 512 KB or more. There are 250 KB wire frame data anyway.
Since it does not discriminate the model, it operates even though “extended memory of MSX 2 or more + DOS 2 + 512 KB or more”, but the speed does not come out.
Because A1ST has only 256 KB as the primary mapper, it does not work even if you stick an extended memory (it probably works if you extend and remodel the main memory)
Real (It is dedicated largely due to the program) It is for A1GT only.
Why would it be such a thing, if you ask someone familiar with MSX it will be fun to teach you about 30 minutes.

Among them, you may make making and commentary videos.

For users of MZ-700 / MZ-1500 / MZ-2500 / SMC-777 / MB-S1 / Pasopia 7, the next is your turn! What?

Created by T Sato - X1 turbo version

Created by nori6001 - PC6601SR version

Google translate of the description of the second video:

Quote:

Zakary, you look a little pale?

It's a palette problem. dont 'worry.

…?

Don’t worry.

Haa …

The AV version wireframe demo is skipped one frame of 88 version.
I think that I wanted on-memory instead of processing speed problem.
Thanks to this, memory is enough even for non-remodeled ST. I did it!
At the same time, it became SCREEN 5 and the frame rate also dropped, so the speed at which MSX 2 (Necessary DOS 2) can finally be seen also comes out.

So it seems the second video halved the number of frames to reduce the memory usage for the sake of the turboR ST, as well as make it run on MSX2. For the ST though, too bad the quality was reduced instead of just supporting an external mapper (which is trivial)…

By the way, looks like all the 3D math has been preprocessed, and the data is essentially a wireframe FMV? May be a useful idea. Takes more memory than I would expect though…

wireframe FMV? As in, for each frame there's a list of start and end coordinates to draw lines between?

Is what I think, indeed.

Metalion posted an interesting optimisation approach here:

Grauw wrote:
Metalion wrote:

3) As I'm drawing in fact a polygon, I'm needing 2 of those triangles and a rectangle in between. The rectangle is done with a HMMV, and I'm using the time needed by the VDP to draw it to make computation for a next frame. If I draw larger triangles because of the HMMV command, it reduces the size of the rectangle and therefore the time available for computations. Of course, it's a balance between the 2, and the gain on drawing speed could also be used. But that needs to be checked.

Aha, interesting! I was already wondering what you needed right triangles for :). I would implement scan line algorithm with two Bresenham functions, one for the left edge and one for the right of a flat-base or flat-top triangle.

But if I understand correctly you’re aiming to exploit larger block fills to optimise the performance, by rendering the triangle in groups of lines at a time (say 8), and then filling the inner area that doesn’t have any edges with HMMV while using something slower for the corners. Or differently put, rendering with HMMV as it were at a lower resolution.

Although in that case to maximise CPU-VDP parallelism my first thought would be to render the corners completely by the CPU, so that it can be done in parallel with the HMMV execution.

Grauw wrote:

By the way, looks like all the 3D math has been preprocessed, and the data is essentially a wireframe FMV? May be a useful idea. Takes more memory than I would expect though…

If that was the case, why the author didn't do hidden line removal? With 3D math predone, it would not cost anything, on the contrary it would save bandwidth.

Pagina 4/4
1 | 2 | 3 |