Suggestions for learning - Page 2

pmc · 08 July 2009, 12:23

I've read in various places that the blitter's line draw is not sufficient when it comes to filled vectors due to the way the blitter's fill logic works.

Most places suggest implementing Bresenham's line drawing algorithm in software and using the processor to draw the lines ready for the blitter to fill.

Bearing in mind the above, I've got a couple of questions:

While blitter line draw might cause problems for filled polygons in vector routines I take it that it's still sufficient when it comes to line (ie. non filled) vectors - is that correct?

Secondly, I've read that the blitter's line draw utilises Bresenham's algorithm but in hardware - how can this be the case then if it doesn't work properly when it comes to polygon filling? ie. why do you have to replace the blitter's hardware Bresenham's with your own software Bresenham's to get correct fills?

wolfchild · 08 July 2009, 14:02

@pmc, are you aware of this document? http://www.mways.co.uk/amiga/howtocode/text/vectors.php

It even has a sample blitter fill routine, though I have no clue what it does

pmc · 08 July 2009, 14:19

@ wolfchild - yes mate thanks, I've read bits and pieces of it.

It presents - I think, somewhere - a software Bresenham line draw algorithm for use with filled vectors. I've also got a book that shows a Bresenham algorithm in 68k asm too.

What I'm hoping to do is avoid that for now and just use blitter line draw (if that's OK for line only vectors...?) as I currenly don't require filling.

Just want to get a wire frame cube spinning to start getting properly to grips with the 3d maths stuff in asm so I can then start also learning about optimising too. Guaranteed that when (if...) I get something working it'll be slow with lots of room for improvement.

gilgamesh · 12 July 2009, 22:02

Pmc, you really should try the mathematics a few times on paper. Just rotate a few points in 3d and project them into 2d. That will give you a feeling for what you are really doing and how to code it efficiently.
Vector algebra can be very elegant and concise, but assembler notation is not.

Generally one should keep in mind that everything that is done to a vector v in order to get v' can be expressed as a multiplication of v with the matrices M1, M2, …
If you're doing three successive rotations Sx, Sy, Sz, one translation T and one projection P, you may want to multiply these matrices first:
v * (Sx * Sy * Sz * T * P) = v * M = v'

And remember that you never work on the processed vectors, since rounding errors will sum up. Always use the original vectors.

That's all I can think of now. I hope this will help.

pmc · 14 July 2009, 13:35

Thanks for the advice gilgamesh.

@ other guys: I've coded an asm blitter line draw routine now that can take any pair of points expressed as x start / y start, x end / y end pxel positions and works out all the values needed (octants etc.) to tell the blitter how to draw a line between them.

Obviously from what I've read as regards problems with blitter line draw and filling this would be no good for filled vectors but should be OK for line vectors - I hope so anyway cos it's what I'm intending to use!

Anyway, if anyone's interested in having a routine like that for themselves then let me know and I'll post it.

Vortex · 14 July 2009, 14:04

PMC, isn't there a special line draw modus for the blitter. Never used it, but I think it's BIT #1 (second bit) of BLTCON1. Setting this bit should set a bit per horizontal line for use with subsequent area fill (according to the HRM).

pmc · 14 July 2009, 14:13

Yes mate there is.

Obviously the line routine I've done could be used like that by, as you say, just setting bit 1 in BLTCON1 for lines drawn with one point per raster line.

*But* I've read in a couple of places that even this isn't good enough when it comes to area filling polygons for vector graphics. These texts all recommend coding a software Bresenham's line draw routine as per my posts above.

Perhaps one of the vector graphics gurus on here could give us a proper explanation why.

korruptor · 14 July 2009, 14:15

What's the norm (fastest?) in Amiga demos?

CPU plot the 1pix per scan line then a blitter fill, or just let the blitter and do both?

Toni Wilen · 14 July 2009, 15:05

Quote:

Originally Posted by pmc

*But* I've read in a couple of places that even this isn't good enough when it comes to area filling polygons for vector graphics. These texts all recommend coding a software Bresenham's line draw routine as per my posts above.

I think the reason was first or last pixel of line that messes up filling without extra code. Fortunately there is very simple trick: point D-channel to scratch region, C-channel to real bitplane. Result: first pixel goes to "scratch" area, the rest is written normally.

(http://eab.abime.net/showpost.php?p=206412&postcount=6 and other posts in that thread)

pmc · 14 July 2009, 21:21

So that means that with a very small change I might even be able to get my line draw routine to work for filled vectors in the future too? Cool

I say *might* as I've found a bug in my existing line draw routine that's screwing certain lines up so I'll need to spend some time tomorrow fixing that first...

Nice one Toni.

WayneK · 15 July 2009, 11:06

That puts you ahead of most people on amiga who coded 3d vectors then, since afaik 95% of 3d demos on amiga used TEC/Cryptoburners line-draw routine rather than coding their own

Good luck with the 3d stuff.

pmc · 15 July 2009, 11:34

Quote:

Originally Posted by WayenK

That puts you ahead of most people on amiga who coded 3d vectors then, since afaik 95% of 3d demos on amiga used TEC/Cryptoburners line-draw routine rather than coding their own

Hmmm... or so I thought. To make sure my line routine definitely works as required I've been shoving in random numbers to see what it draws.

I've noticed that if I input x start as 1, x end as 2, y start as 255 and y end as 235 I thought I would get a line that looked something like this:

|
|
.|
.|

Instead, I get a line that looks like this:

|
|
.\
...\

Not good. I've calculated what I should be filling the blitter registers with using these start and end numbers by hand and then compared this to what my routine generates in a debugger and there's no difference.

Looks like my routine calculates all the numbers and fills all the registers correctly.

Perhaps the calculations required which I've been following from Amiga System Programmer's Guide are inaccurate.

More work needed I think...

pmc · 15 July 2009, 13:02

Quote:

Originally Posted by pmc

Perhaps the calculations required which I've been following from Amiga System Programmer's Guide are inaccurate.

I might be correct in this. I manually calculated and filled the blitter registers again but this time using the calculations as listed in the HRM. This time the line looked more like how I thought it should look.

Can't be certain the ASPG book is wrong until I do more testing. Time to tweak my routine's calcs to do what the HRM says and retest on some more lines...

Vortex · 15 July 2009, 13:25

WHat are you doing with a system (friendly ?

) programmers guide anyway...

(sorry, couldn't stop myself...

)

pmc · 15 July 2009, 13:39

Quote:

Originally Posted by Vortex

WHat are you doing with a system (friendly ?

) programmers guide anyway...

(sorry, couldn't stop myself...

)

LOL. Very, very true my friend.

As an indication of just how true - I recoded my slope calculation routine but this time as per the HRM and tested with a few lines and it now looks to be working OK. I'll keep testing to be sure but fingers crossed it's all good.

I won't curse the Amiga System Programmer's Guide too much though as the explanation of calculating octants was very useful in my opinion compared to what the HRM says about them.

My advice for anyone wanting to code their own blitter line draw routine is therefore to get both books.

Or leech the routine off me.

EDIT: Speaking of leeching it off me - I've done more random values line testing and the routine looks to work OK so I've attached it here in case anyone would like to use it themselves. All you have to do is load x1, x2, y1 & y2 with the appropriate numbers and then do a bsr .draw_line and the routine should do the rest. Be careful - the routine assumes you load reasonable numbers and does no error checking!

Linedraw code removed - I found a subtle bug - an updated (hopefully bug free) version is now posted later in this thread.

pmc · 16 July 2009, 12:33

Just a quick note for anyone mad or stupid enough to actually wanna try using my line routine - make sure you wait for the blitter to be ready before you call the .draw_line routine.

If you don't, weird shit happens to your lines when you use the routine to draw multiple lines in succession.

Hey, what can I say? I'm learning to use my own routine as I go.

pmc · 27 July 2009, 16:05

Hello boys.

It's been a while but now I have returned.

Check out the attached source code. You should see a nice spinning 3D wire frame cube. My first 3D routine in asm.

This is the first (sort of...) working version of my routine. There's commenting which should help someone pick apart what's going on. I'm sure there'll be optimising and bug fixing aplenty to do...

Gotta say thanks to everyone who's encouraged me or given me advice for this one but especially to:

wolfchild & StingRay for pointing me towards two 3D tutorials that really helped loads. Thanks guys.

Apollo for pointing me at the fixed point tutorial.

And one final big thankyou to Vortex for helpful advice, encouragement and guidance all the way through too.

StingRay · 27 July 2009, 16:11

Nice one! Reminds me of the time when I saw my first rotating cube on screen, many many many years ago. =) Had a quick look at the source, muls #256,dx really hurts my eyes!

Also, it seems the movement of the cube is a bit jerky so you may want to increase the precision of your sine table and/or calculations a bit. Anyway, nice achievement, congrats!

Edit: the precision of your sintab is OK, just enlarge the sintable and the movement should be much smoother.

pmc · 27 July 2009, 17:34

Quote:

Originally Posted by StingRay

Nice one! Reminds me of the time when I saw my first rotating cube on screen, many many many years ago.

Cheers man.

It's just another routine with code from 1987 from me.

Quote:

Originally Posted by StingRay

Had a quick look at the source, muls #256,dx really hurts my eyes!

LOL. Tell me about it! This routine is slooooooow.

My next task is to optimise as much as I possibly can. Once that's done I need to make the routine more universal so that it can handle different objects.

At some point I'd like to be able to also have time to calculate which lines should be hidden. So far the only thing I've read on this suggests checking the unit normal vectors of the vertices for positve or negative in comparison to the viewpoint vector...? Whatever that means!

Oh, and having enough time to play music and show some scrolltext at the same time might come in handy too... eh Vortex?

Quote:

Originally Posted by StingRay

just enlarge the sintable and the movement should be much smoother.

I made cos and sin tables that had 2^14 fixed point numbers for all the angles from 0 to 359 degrees in one degree steps. Do you mean adding values for example for the half degree steps in between too?

Enlighten me more Obi-Wan!

Vortex · 27 July 2009, 17:40

Congratulations PMC! Good job!

You must be very happy with the result.

With these rotation routines you can have loads of fun. Vector balls (love them

), 3d star fields, filled vectors,...

Need to get back to my paint job now, but I will try to move over the code to my miggy tonight and watch your code on the real deal..

By the way, did you test how much time your routine takes?

27 July 2009, 16:05	#37
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Hello boys. It's been a while but now I have returned. Check out the attached source code. You should see a nice spinning 3D wire frame cube. My first 3D routine in asm. This is the first (sort of...) working version of my routine. There's commenting which should help someone pick apart what's going on. I'm sure there'll be optimising and bug fixing aplenty to do... Gotta say thanks to everyone who's encouraged me or given me advice for this one but especially to: wolfchild & StingRay for pointing me towards two 3D tutorials that really helped loads. Thanks guys. Apollo for pointing me at the fixed point tutorial. And one final big thankyou to Vortex for helpful advice, encouragement and guidance all the way through too. Last edited by pmc; 26 February 2010 at 12:23.

27 July 2009, 16:11	#38
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Nice one! Reminds me of the time when I saw my first rotating cube on screen, many many many years ago. =) Had a quick look at the source, muls #256,dx really hurts my eyes! Also, it seems the movement of the cube is a bit jerky so you may want to increase the precision of your sine table and/or calculations a bit. Anyway, nice achievement, congrats! Edit: the precision of your sintab is OK, just enlarge the sintable and the movement should be much smoother. Last edited by StingRay; 27 July 2009 at 16:28.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Learning AMOS - Beginners Guide Disks	Peter	Retrogaming General Discussion	15	28 October 2015 17:17
DiskImage: When learning to read proves futile.	XDelusion	support.Apps	19	20 October 2012 23:57
Wanting to start learning to code amiga in asm	fishyfish	Coders. Asm / Hardware	5	03 March 2012 06:11
Playpower - 8 bit learning games for the developing world	girv	Retrogaming General Discussion	5	24 March 2009 22:00
Learning assembler	bLAZER	Coders. General	1	12 May 2007 05:00

08 July 2009, 12:23	#21
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	I've read in various places that the blitter's line draw is not sufficient when it comes to filled vectors due to the way the blitter's fill logic works. Most places suggest implementing Bresenham's line drawing algorithm in software and using the processor to draw the lines ready for the blitter to fill. Bearing in mind the above, I've got a couple of questions: While blitter line draw might cause problems for filled polygons in vector routines I take it that it's still sufficient when it comes to line (ie. non filled) vectors - is that correct? Secondly, I've read that the blitter's line draw utilises Bresenham's algorithm but in hardware - how can this be the case then if it doesn't work properly when it comes to polygon filling? ie. why do you have to replace the blitter's hardware Bresenham's with your own software Bresenham's to get correct fills?

08 July 2009, 14:02	#22
wolfchild Registered User Join Date: Jun 2008 Location: Malta Age: 47 Posts: 43	@pmc, are you aware of this document? http://www.mways.co.uk/amiga/howtocode/text/vectors.php It even has a sample blitter fill routine, though I have no clue what it does

08 July 2009, 14:19	#23
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ wolfchild - yes mate thanks, I've read bits and pieces of it. It presents - I think, somewhere - a software Bresenham line draw algorithm for use with filled vectors. I've also got a book that shows a Bresenham algorithm in 68k asm too. What I'm hoping to do is avoid that for now and just use blitter line draw (if that's OK for line only vectors...?) as I currenly don't require filling. Just want to get a wire frame cube spinning to start getting properly to grips with the 3d maths stuff in asm so I can then start also learning about optimising too. Guaranteed that when (if...) I get something working it'll be slow with lots of room for improvement.

12 July 2009, 22:02	#24
gilgamesh Linux snob Join Date: Sep 2008 Location: Monkey Island Posts: 997	Pmc, you really should try the mathematics a few times on paper. Just rotate a few points in 3d and project them into 2d. That will give you a feeling for what you are really doing and how to code it efficiently. Vector algebra can be very elegant and concise, but assembler notation is not. Generally one should keep in mind that everything that is done to a vector v in order to get v' can be expressed as a multiplication of v with the matrices M1, M2, … If you're doing three successive rotations Sx, Sy, Sz, one translation T and one projection P, you may want to multiply these matrices first: v * (Sx * Sy * Sz * T * P) = v * M = v' And remember that you never work on the processed vectors, since rounding errors will sum up. Always use the original vectors. That's all I can think of now. I hope this will help.

14 July 2009, 13:35	#25
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Thanks for the advice gilgamesh. @ other guys: I've coded an asm blitter line draw routine now that can take any pair of points expressed as x start / y start, x end / y end pxel positions and works out all the values needed (octants etc.) to tell the blitter how to draw a line between them. Obviously from what I've read as regards problems with blitter line draw and filling this would be no good for filled vectors but should be OK for line vectors - I hope so anyway cos it's what I'm intending to use! Anyway, if anyone's interested in having a routine like that for themselves then let me know and I'll post it.

14 July 2009, 14:04	#26
Vortex Used Register Join Date: Nov 2008 Location: Headvillage / The Nethervoids Age: 50 Posts: 103	PMC, isn't there a special line draw modus for the blitter. Never used it, but I think it's BIT #1 (second bit) of BLTCON1. Setting this bit should set a bit per horizontal line for use with subsequent area fill (according to the HRM).

14 July 2009, 14:13	#27
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Yes mate there is. Obviously the line routine I've done could be used like that by, as you say, just setting bit 1 in BLTCON1 for lines drawn with one point per raster line. But I've read in a couple of places that even this isn't good enough when it comes to area filling polygons for vector graphics. These texts all recommend coding a software Bresenham's line draw routine as per my posts above. Perhaps one of the vector graphics gurus on here could give us a proper explanation why.

14 July 2009, 14:15	#28
korruptor TDI Join Date: Feb 2007 Location: Blitter Town Posts: 124	What's the norm (fastest?) in Amiga demos? CPU plot the 1pix per scan line then a blitter fill, or just let the blitter and do both?

14 July 2009, 21:21	#30
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	So that means that with a very small change I might even be able to get my line draw routine to work for filled vectors in the future too? Cool I say might as I've found a bug in my existing line draw routine that's screwing certain lines up so I'll need to spend some time tomorrow fixing that first... Nice one Toni.

15 July 2009, 11:06	#31
WayneK Registered User Join Date: May 2004 Location: Somewhere secret Age: 50 Posts: 366	That puts you ahead of most people on amiga who coded 3d vectors then, since afaik 95% of 3d demos on amiga used TEC/Cryptoburners line-draw routine rather than coding their own Good luck with the 3d stuff.

15 July 2009, 13:25	#34
Vortex Used Register Join Date: Nov 2008 Location: Headvillage / The Nethervoids Age: 50 Posts: 103	WHat are you doing with a system (friendly ? ) programmers guide anyway... (sorry, couldn't stop myself... )

16 July 2009, 12:33	#36
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Just a quick note for anyone mad or stupid enough to actually wanna try using my line routine - make sure you wait for the blitter to be ready before you call the .draw_line routine. If you don't, weird shit happens to your lines when you use the routine to draw multiple lines in succession. Hey, what can I say? I'm learning to use my own routine as I go.

27 July 2009, 17:40	#40
Vortex Used Register Join Date: Nov 2008 Location: Headvillage / The Nethervoids Age: 50 Posts: 103	Congratulations PMC! Good job! You must be very happy with the result. With these rotation routines you can have loads of fun. Vector balls (love them ), 3d star fields, filled vectors,... Need to get back to my paint job now, but I will try to move over the code to my miggy tonight and watch your code on the real deal.. By the way, did you test how much time your routine takes?

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)