Positron5 Posted May 16, 2022 Share Posted May 16, 2022 (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 May 16, 2022 by Positron5 @42bs correction Quote Link to comment Share on other sites More sharing options...
Cyprian Posted May 16, 2022 Share Posted May 16, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Positron5 Posted May 16, 2022 Author Share Posted May 16, 2022 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.?? Quote Link to comment Share on other sites More sharing options...
42bs Posted May 16, 2022 Share Posted May 16, 2022 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. Quote Link to comment Share on other sites More sharing options...
Positron5 Posted May 16, 2022 Author Share Posted May 16, 2022 @42bs. I will try and have a go at producing some triangles and get to know the blitter instruction set.☺️ Quote Link to comment Share on other sites More sharing options...
42bs Posted May 20, 2022 Share Posted May 20, 2022 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. Quote Link to comment Share on other sites More sharing options...
Positron5 Posted May 20, 2022 Author Share Posted May 20, 2022 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 Quote Link to comment Share on other sites More sharing options...
jguff Posted May 21, 2022 Share Posted May 21, 2022 (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 May 21, 2022 by jguff Quote Link to comment Share on other sites More sharing options...
42bs Posted May 21, 2022 Share Posted May 21, 2022 I don't think so, as clipping is a fixed rectangle. One needs one that grows. Quote Link to comment Share on other sites More sharing options...
laoo Posted May 21, 2022 Share Posted May 21, 2022 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. Quote Link to comment Share on other sites More sharing options...
42bs Posted May 21, 2022 Share Posted May 21, 2022 (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 May 21, 2022 by 42bs Quote Link to comment Share on other sites More sharing options...
jguff Posted May 21, 2022 Share Posted May 21, 2022 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 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted May 21, 2022 Share Posted May 21, 2022 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? Quote Link to comment Share on other sites More sharing options...
laoo Posted May 22, 2022 Share Posted May 22, 2022 Eh, I was actually wrong. There does not seem to exist finite "clipped right triangle subdivision" to that triangle. Quote Link to comment Share on other sites More sharing options...
42bs Posted May 22, 2022 Share Posted May 22, 2022 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. Quote Link to comment Share on other sites More sharing options...
42bs Posted May 22, 2022 Share Posted May 22, 2022 (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 May 22, 2022 by 42bs Fix typo :-) 1 Quote Link to comment Share on other sites More sharing options...
jguff Posted May 22, 2022 Share Posted May 22, 2022 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? Quote Link to comment Share on other sites More sharing options...
42bs Posted May 22, 2022 Share Posted May 22, 2022 21 minutes ago, jguff said: There's a typo in there... ? oh those auto-corrections 1 Quote Link to comment Share on other sites More sharing options...
Positron5 Posted May 22, 2022 Author Share Posted May 22, 2022 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. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted May 23, 2022 Share Posted May 23, 2022 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 Quote Link to comment Share on other sites More sharing options...
42bs Posted May 23, 2022 Share Posted May 23, 2022 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. Quote Link to comment Share on other sites More sharing options...
SCPCD Posted May 25, 2022 Share Posted May 25, 2022 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. Quote Link to comment Share on other sites More sharing options...
42bs Posted May 25, 2022 Share Posted May 25, 2022 (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 May 25, 2022 by 42bs 1 Quote Link to comment Share on other sites More sharing options...
jguff Posted May 26, 2022 Share Posted May 26, 2022 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 Quote Link to comment Share on other sites More sharing options...
42bs Posted May 26, 2022 Share Posted May 26, 2022 Yes, I ran into this moveq problem before. But here it really stroke me. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.