Drawing Triangles process

[Positron5]

I want to investigate how you would draw a triangle on the jaguar display. Would this be possible by

using the scaled bitmapped object and controlling the HSCALE and VSCALE (independently?), xpos and ypos values, similar to

@42bs's atari lynx method.

 Can anyone explain the process?

Andrew

Edited May 16, 2022 by Positron5
@42bs correction

[Cyprian]

I'm not sure whether it is a good idea to use OP to draw a triangle because more OP objects means more memory bandwidth stolen from its processors. Would be better to use the GPU to drive the blitter and draw triangle line by line.

[Positron5]

Thanks @Cyprian for replying, I searched through the forum and I found this-

In it Luigi301 gives a good account of a method of using the blitter etc to create a functional 3d renderer.

GPU and blitter looks like the way to go.??

 

[42bs]

10 hours ago, Positron5 said:

I want to investigate how you would draw a triangle on the jaguar display. Would this be possible by

using the scaled bitmapped object and controlling the HSCALE and VSCALE (independently?), xpos and ypos values, similar to

@BS42's atari lynx method.

 Can anyone explain the process?

Andrew

Funny, I just checked my old demos. I used Bresenham to calculate the vertices and Blitter to draw horizontal lines.

I think the Jaguar Blitter cannot act like Suzy.

[Positron5]

@42bs. I will try and have a go at producing some triangles and get to know the blitter instruction set.☺️

[42bs]

The Jaguar blitter has a "tilt", but it cannot change size as Suzy can.

Means you can draw lines or tilted rectangles. But no triangles.

[Positron5]

For anyone that is interested, you can find Bastian's source code from his topic here:

New bjl_update: Polygon

14 hours ago, 42bs said:

Added polygon/poly_mmu sources to new_bjl:

 

https://github.com/42Bastian/new_bjl/tree/main/exp/poly_mmu

 

[jguff]

19 hours ago, 42bs said:

The Jaguar blitter has a "tilt", but it cannot change size as Suzy can.

Means you can draw lines or tilted rectangles. But no triangles.

Could you theoretically use blitter to create right angle triangles using clipping?

Maybe use blitter zbuffer capabilities to trick blitter into drawing triangles?

I'm not interested enough to try and write assembly code to find out...

 

Bob

Edited May 21, 2022 by jguff

[42bs]

I don't think so, as clipping is a fixed rectangle. One needs one that grows.

 

[laoo]

I imagine that by drawing tilted / skewed rectangle with clipping on one side you can draw special case of right triangle, but when Suzy needs two blitted triangles to obtain any arbitrary triangle, here you would need four and with potencially big waste of cycles due to clipping. 

[42bs]

Ah, this idea is neat. 

But needing to split up a triangle into four takes also some time.

I need to check my polygon routine, if it is worth making a triangle version. But in this case you have a lot more points and edges.

Edited May 21, 2022 by 42bs

[jguff]

Thinking this through a bit more...

 

Simplest case:
...initialize 3 vertices (V1, V2, V3) that define a right triangle, with one side lining up with imaginary vertical (or horizontal) line
...calculate skewed rectangle from 3 vertices
...instruct blitter to draw skewed rectangle with clipping enabled - to produce a right triangle with one side lining up with vertical or horizontal

 

Adding some complexity:
angle = 0
for each subsequent frame
...rotate the vertices iAngle degrees
...calculate intersection of line between V2 and V3 with imaginary vertical (or horizontal) line running through V1
...calculate two rectangles from the 3 rotated vertices and the imaginary vertical (or horontal) line runnning through V1
...instruct blitter to draw 90 degree skewed rectangle with clipping enabled - to produce a right triangle with one side lining up with imaginary line
...instruct blitter to draw 90 degree skewed rectangle with clipping enabled - to produce a right triangle with one side lining up with imaginary line - the two clipped rectangles produce a triangle representing the initial triangle rotated by angle degrees
...++iAngle

 

I'm not suggesting this is smart or efficient.  Merely suggesting it may be possible.

 

If blitter clipping is smart enough to short circuit iteration of inner loop when blitter encounters window edge, that would help efficiency.

However, nothing is going to change the fact that blitter is going to draw non horizontal lines with this potential approach.  Not drawing horizontal lines should mean writing to non-contiguous memory elements, which should mean page faults.  Would think page faults would make this potential approach very inefficient.

 

Bob
 

[+Gemintronic]

Out of my league and ignorant.  Just stating that right off the bat.

 

I wonder if with taking Z order into account drawing triangles into a buffer then just rendering it as one big screen filling sprite would work.

 

Or, is memory and the 68k too wimpy to do software based rendering?

[laoo]

Eh, I was actually wrong. There does not seem to exist finite "clipped right triangle subdivision" to that triangle.

[42bs]

While riding with my bicycle I was also thinking about. What you get with the blitter is a parallelogram. 

This could be cut (in theory) with the clipping rectangle. In your gfx it would be as wide as the horizontal edge.

But this is is one part. I think the computing expense plus register setup cannot be outperformed by the blitter drawing. Esp. because in a 3D game you have a lot of small triangles.

The drawback of the line by line poly routine is, that it does not work with texture mapping and the Gouraud shading is also 'wrong'.

But it could be optimized a bit by recording the lowest and highest Y to avoid searching the first h-line to draw.

[42bs]

19 hours ago, Gemintronic said:

Out of my league and ignorant.  Just stating that right off the bat.

 

I wonder if with taking Z order into account drawing triangles into a buffer then just rendering it as one big screen filling sprite would work.

 

There is an algo using Span-Buffers:

https://mcejp.github.io/2021/02/17/s-buffers.html

Edited May 22, 2022 by 42bs
Fix typo :-)

[jguff]

37 minutes ago, 42bs said:

There is an algo using Spam-Buffers:

https://mcejp.github.io/2021/02/17/s-buffers.html

There's a typo in there...

 

Shame the blitter cannot directly recognize span lists.  Span lists seem likely most efficient means to flat shade polys for jaguar. Span list is kind of what Object Processor is doing for sprites.

 

Any idea whether the Object Processor is really separate transistors from the Blitter, or is Object Processor using/calling/wrapping the Blitter?

[42bs]

21 minutes ago, jguff said:

There's a typo in there...

? oh those auto-corrections 

[Positron5]

57 minutes ago, 42bs said:

While riding with my bicycle I was also thinking about. What you get with the blitter is a parallelogram. 

This could be cut (in theory) with the clipping rectangle. In your gfx it would be as wide as the horizontal edge.

But this is is one part. I think the computing expense plus register setup cannot be outperformed by the blitter drawing. Esp. because in a 3D game you have a lot of small triangles.

The drawback of the line by line poly routine is, that it does not work with texture mapping and the Gouraud shading is also 'wrong'.

But it could be optimized a bit by recording the lowest and highest Y to avoid searching the first h-line to draw.

The clipping concept is good but I think that the blitter triangle way looks the winner.

[Zerosquare]

17 hours ago, 42bs said:

While riding with my bicycle I was also thinking about. What you get with the blitter is a parallelogram. 

This could be cut (in theory) with the clipping rectangle. In your gfx it would be as wide as the horizontal edge.

But this is is one part. I think the computing expense plus register setup cannot be outperformed by the blitter drawing. Esp. because in a 3D game you have a lot of small triangles.

The drawback of the line by line poly routine is, that it does not work with texture mapping and the Gouraud shading is also 'wrong'.

But it could be optimized a bit by recording the lowest and highest Y to avoid searching the first h-line to draw.

I had the same idea a long time ago, but never actually tested it:

The black triangle is drawn by drawing a parallelogram (cyan) clipped by a rectangle (pink).

Arbitrary triangles are drawn by subdividing them into right-angled triangles:

 

But there are several issues:

- as mentioned, this only works right for simple flat lighting, not Gouraud or texture-mapped

- it's inefficient for skinny triangles

- subdividing triangles has a computation cost

- according to SCPCD, the blitter's clipping feature is buggy, so it may not work as it should

[42bs]

6 minutes ago, Zerosquare said:

according to SCPCD, the blitter's clipping feature is buggy, so it may not work as it should

Plus you cannot set x,y,w,h of the clipping, but have to calculate the screen pointer to place 0,0. So additional extra cost.

So we found another 'design flaw' in the Jaguar.

[SCPCD]

The other issue with this method, is that the blitter will compute all clipped pixel and so, 50% of the time the blitter will do unusefull stuff.

 

[42bs]

Ok, Jaguar kills me

	;; get first point
	load	(points_ptr),counter
	addq	#4,points_ptr
	moveta	points_ptr,points_ptr.a

	load	(points_ptr),y1
	addq	#4,points_ptr
	move	y1,x1
	moveta	y1,xy0.a
	shlq	#16,y1

	sharq	#16,x1
	sharq	#16,y1

	moveta	x1,x1.a
	moveta	y1,y1.a

.poly_loop
	subq	#1,counter
	jump	n,(DRAW_LINES)	; polygon close => now draw
	load	(points_ptr),y2
	jr	nz,.not_last
	addq	#4,points_ptr

	movefa	xy0.a,y2	; get back first point
.not_last

This is a part of a new polygon routine. The first point is saved and used as last point.

On VJ this works, on the real machine the "movefa xy0.a,y2" seems not to be excecuted, but rather y2 contains the next from points_ptr.

I added "or y2,y2" before and after the "movefa". No change.

What the %"$§/%&/§$& am I missing

 

Edit:

I have to add an "or y2,y2" directly after the "load" (and of course check counter again).

Edited May 25, 2022 by 42bs

[jguff]

9 hours ago, 42bs said:

Ok, Jaguar kills me

	;; get first point
	load	(points_ptr),counter
	addq	#4,points_ptr
	moveta	points_ptr,points_ptr.a

	load	(points_ptr),y1
	addq	#4,points_ptr
	move	y1,x1
	moveta	y1,xy0.a
	shlq	#16,y1

	sharq	#16,x1
	sharq	#16,y1

	moveta	x1,x1.a
	moveta	y1,y1.a

.poly_loop
	subq	#1,counter
	jump	n,(DRAW_LINES)	; polygon close => now draw
	load	(points_ptr),y2
	jr	nz,.not_last
	addq	#4,points_ptr

	movefa	xy0.a,y2	; get back first point
.not_last

This is a part of a new polygon routine. The first point is saved and used as last point.

On VJ this works, on the real machine the "movefa xy0.a,y2" seems not to be excecuted, but rather y2 contains the next from points_ptr.

I added "or y2,y2" before and after the "movefa". No change.

What the %"$§/%&/§$& am I missing

 

Edit:

I have to add an "or y2,y2" directly after the "load" (and of course check counter again).

 

Maybe Page 41 of Software Reference Manual, dated 2021-12-20, Stephen Moss

 

 

 

[42bs]

Yes, I ran into this moveq problem before. But here it really stroke me.