Jump to content
Positron5

Drawing Triangles process

Recommended Posts

Posted (edited)

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 by Positron5
@42bs correction

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.👍👍

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by jguff

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by 42bs

Share this post


Link to post
Share on other sites

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
 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

IMG_20220522_143016.jpg

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by 42bs
Fix typo :-)
  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
21 minutes ago, jguff said:

There's a typo in there...

🙂 oh those auto-corrections 

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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:

wPtL

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:

W3c8

 

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by 42bs
  • Like 1

Share this post


Link to post
Share on other sites
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

 

image.thumb.png.2188980840932ef21159cf7d927fbf05.png

 

 

image.thumb.png.ffcd39e2100ebb3bd160f6c39796be7d.png

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...