Flight for Nordlicht intro released.

[VladR]

Re: drawing

 

First. I am drawing from front to back and using a line height map buffer which you know from voxel landscape.

 

Then the illusion works because you fill boxes with same color and set only the pixels.

 

I draw the quads from middle to outside and separate from left and right side...

 

I draw only L parts of a quad. So x1,z1 to x2,z2 then x2,z2 fo x3,z3.heighy of those grid nodes is taken from a 16x16 array.

 

Each vertice of the mesh has same delta in x and z. Only y differs.

 

The drawing order is essential if the lines not to break the illusion.

Yeah, but if the drawing order is front-to-back, then there must be some kind of occlusion acceleration structure, no ? Perhaps that explains the general performance of the technique, not sure...

 

But, still, if you draw front to back, there must be a per-pixel occlusion check somewhere, otherwise the mountain behind the front quad, wouldn't be pixel-perfect occluded (and it is, I was carefully checking the vid), but would otherwise overdraw the mountain in front of it.

 

 

I suppose it all depends on where exactly the technique draws the boundary between 3D and 2D. I recall your older vid showing how (Fractalus, I think?) runs on 7 MHz and all kinds of glitches/errors were suddenly excarbated at that speed (which were invisible at default framerate).

 

I have a gut feeling that back-to-front rendering could be a bit faster - what do you think ?

[VladR]

You have a clue how it is done?

You mean Amiga's Unreal vid you posted ?

 

- First of all there's no rotation, so all objects have 3D paths along precomputed lines (simple look up table)

- Sprites are actually composed of several sub-layers, and each such layer can have a unique xpos,ypos

- this obviously results in some overdraw, but gains you much finer precision versus bruteforce scaling (e.g. you would need 2x-4x more frames of prescaled sprites otherwise)

- there seems to be just enough sprites to envoke some variety, but low enough a number that they can be pre-scaled at loading time

- the YT compression artifacts make it hard to discern more

[Heaven/TQA]

Yeah, but if the drawing order is front-to-back, then there must be some kind of occlusion acceleration structure, no ? Perhaps that explains the general performance of the technique, not sure...

 

But, still, if you draw front to back, there must be a per-pixel occlusion check somewhere, otherwise the mountain behind the front quad, wouldn't be pixel-perfect occluded (and it is, I was carefully checking the vid), but would otherwise overdraw the mountain in front of it.

 

 

I suppose it all depends on where exactly the technique draws the boundary between 3D and 2D. I recall your older vid showing how (Fractalus, I think?) runs on 7 MHz and all kinds of glitches/errors were suddenly excarbated at that speed (which were invisible at default framerate).

 

I have a gut feeling that back-to-front rendering could be a bit faster - what do you think ?

What I ment with voxel landscape line buffer is that you fill a 1d scanline buffer with pixel y values.

 

So when you draw a line you fill a y buffer where you store y values only if new height is higher than old height.

 

Same for voxel landscape to avoid overdraws. And you can draw front to back.

[Heaven/TQA]

Of course with a line buffer there is a threshold where the overhead of that doesnt compensate the skipped pixel settings and vice verser. On my voxel landscape I even had a brute force version where I draw 1x5 voxel spans without checks.

[VladR]

Yeah, regardless of technique, that performance threshold is always there - but discovering it is half of fun

 

 

Generally, I was never fond of front-to-back drawing. Every single time I tried that, it was easier to come up with a much faster back-to-front rendering. The only time front-to-back can't be beat is when there's some huge object occluding 50%+ of the scene, but that's a very specific, and rare, scenario.

[Heaven/TQA]

Yeah, regardless of technique, that performance threshold is always there - but discovering it is half of fun

 

 

Generally, I was never fond of front-to-back drawing. Every single time I tried that, it was easier to come up with a much faster back-to-front rendering. The only time front-to-back can't be beat is when there's some huge object occluding 50%+ of the scene, but that's a very specific, and rare, scenario.

 

 

 

Procedure draw_line(x_left,x_right,linecolor)

For x=x_left To x_right

If x>=0 And x<=w

If heights(x)<ybuffer(x)

y=heights(x)

dy=ybuffer(x)-heights(x)-1

ybuffer(x)=y

Box(x*pixel_width, y*pixel_height, pixel_width, dy*pixel_height,linecolor)

EndIf

EndIf

Next

EndProcedure

[emkay]

OK. How about using Antic D with 1:2 aspect ratio? And some multiplexed PMG protagonist in the overlay?

Unreal uses something similar, as most objects use double scanline (1:2) ratio for the objects. It might be a lot of raster tricks, but it looks very much like 3D. It's something never seen on the Atari. A fluent "3d" depth animation plus a free moving object above it. The scene should be done with always close colors to dim the low resolution a bit, and the protagonist could be done , using double scanline resolution.

[Heaven/TQA]

https://youtu.be/LB_pdLHz4tY?t=101

[emkay]

https://youtu.be/LB_pdLHz4tY?t=101

???

 

AGA Chipset, 68030, 25MHz... Coprocessor?

 

hm...

Edited May 17, 2018 by emkay

[emkay]

Even more interesting: They used the flattened version like the C64 version. Not the "real Hill" version of the Atari

[Heaven/TQA]

???

 

AGA Chipset, 68030, 25MHz... Coprocessor?

 

hm...

 

what if I tell you that we made it on OCS?

[emkay]

what if I tell you that we made it on OCS?

Well done?

[Heaven/TQA]

Yup. Looks like ROF on steroids.

[Heaven/TQA]

btw I was totally wrong with Koronis Rift... it does not use a so called EOR filler like I did in my Voxel engine...

 

the engine has a full collum routine where ti fills from y1 to y2 with self modified code...

 

and on top of it it draws the white pixels with simple AND ORA STA....

 

interesting that this approach is still fast enough.

[VladR]

What is OCS ?

[emkay]

What is OCS ?

Original Chip Set.

The first Chipset of the Amiga.

It changed to some enhanced features of the Denise Chip and was able to adress more RAM , then it was called ECS.

Later AGA (Advanced Graphics Array )Chipset , as used after 1989, was generally faster, but also not fully compatible.

So, if you see a 3D Demo, it's usually not a real Amiga demo, it's an Amiga "AGA" demo.

Sound was never touched there.

[Heaven/TQA]

VladR....

 

You did some benchmarks in brute force fillers? Assume Koronis Rift is filling collums (delta height to next) with one color and later draws on top the white pixels...

[VladR]

Original Chip Set.

The first Chipset of the Amiga.

It changed to some enhanced features of the Denise Chip and was able to adress more RAM , then it was called ECS.

Later AGA (Advanced Graphics Array )Chipset , as used after 1989, was generally faster, but also not fully compatible.

So, if you see a 3D Demo, it's usually not a real Amiga demo, it's an Amiga "AGA" demo.

Sound was never touched there.

Oh, it's a Commodore thing. I wouldn't know about that. I did hear the terms ECS and AGA, though never paid much attention to them. It's a Commodore, after all

 

You did some benchmarks in brute force fillers?

Yeah, but that's for scanline rasterizer. Handle Left/Right edge byte separately, and then jump into unrolled loop of STA vidptr,X ; INX

That's bloody fast.

 

VladR....

 

You did some benchmarks in brute force fillers? Assume Koronis Rift is filling collums (delta height to next) with one color and later draws on top the white pixels...

Uffff, columns. Quite possible the slowest possible way to fill on Atari...

 

I suppose, if you had each column unrolled into 4-cycle STAs and just inserted/cleared rts per each column, it could be remotely not-slow (but certainly not very fast). At 160x96x4, it requires (160/4)*96 = 3,840 STAs (3 Bytes) -> 11,520 Bytes for STAs. If you wanna combine that with EOR, we're looking into ~22 KB. But, with 128 KB in a stock Atari, that's not a big problem (let alone considering all memory expansions available)

 

But how many columns do you typically have ? I was recently looking into the dynamic rts insertion/restore but it adds up real ugly. If you got 100+ columns, just that alone will eat 1 frame/vblank.

 

I'm still not convinced a hybrid solution wouldn't be actually faster (e.g. draw the mountains crossing the horizon via scanlines, and the remaining ridges below horizon via line drawing). It's of course much more work, and connecting the 2 approaches would certainly result in some ugly bugs, especially for clipping.

 

My thinking is this: If we target 5-6 fps, that's 10 frames worth of CPU time:

1 : Clearscreen

1: 3D transform

2-3: scanline-based horizon (basically each line (post-transform) that crosses horizon's YPOS is included there)

3-5: All remaining ridges (via fractal displacement) drawn using line algorithm. If not many ridges present, framerate could jump up

 

You would need to keep the counter per each line, how far did you get during the scanline portion, so that you can then seamlessly continue drawing just the ridge lines (where you left off in previous pipeline stage). That's certainly debugging complication (but not an algorithmic one, "just" an inconvenience).

[Heaven/TQA]

Thanks.

 

Eidolon and Rescue on Fractalus are working with ora fillers and work in simplest way (like me do in all of mine engine).

 

Using unrolled collum based speddcode where Index reg is used to adress Collums in a loop. Same for clear.

 

But interesting koronis rift not. It uses that mentioned delta approach with injection of Jsr and Rts for span (in y) length to fill from y1 to y2.

 

Not to mention the overhead with handling the jsr/rts you need to handle the top most byte depending on 0x or x0.

 

Interesting the filler is a simple

 

STA,X

STA+40,X

...

 

So I had expected at least

 

LDA

ORA

STA

 

To combine both pixel collums per byte.

 

Anyway due to colors I am trying for 3 days using a EOR filler approach. Issue is that I dont know the colors above and below a area to fill as the drawing is handled from left to right.

 

In my Voxel Code its always top to bottom and per collum...

 

[Heaven/TQA]

The vertical lines are the issues.

[Heaven/TQA]

Vertical lines mean x2,y2,z2 to x3,y3,z3 and they break the trick illusion Lucasfilm is using for RoF and Koronis Rift.

[emkay]

The vertical lines are the issues.

Looks like they were the "depth" of the "hills". And as they were in front of them, the color is changed to the front layer.

[emkay]

Do you just set the color palette or do you change the drawn registers also?

The problem could be solved with more depth layers.

[Heaven/TQA]

Its an eor filler issue.

[emkay]

Its an eor filler issue.

If you say so.

 

Have a closer look at the hill to the right.

 

 

How come, the eor filler issue, knows to go down from the peak to the bottom of a hill, straight the correct degree in the projection depth?

Edited May 21, 2018 by emkay