Suggestions for learning

[Vortex]

Originally Posted by pmc

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?

Yes, or even 1/4 degree steps...

[pmc]

@ Vortex Yeah, really happy I got it working.

The thing I'm most happy with is that apart from a couple of little errors I made that held me up a little bit I basically did all the code for the 3D matrix, rotations and perpsective transform in about a day and half of real time.

That might not be good compared to the real coding heroes out there but for me is a breakthrough - I think I'm getting better at coding little by little.

I did speed test the line draw routine when I did that one - takes about two and a half raster lines per line drawn. Haven't speed tested the 3D routines yet but I will do...

Check your email account - I'll assemble the source to executable and crunch it and send you it on email - should make it faster and easier for you to transfer to your Amiga.

[pmc]

@ Vortex - OK another probably stupid question then. For one degree step angles I can just write a list of angles like:

1,2,3,4,5,6,7,8

How would I write a list of angles like

1,1.5,2,2.5,3,3.5?

There's no way for the assembler to code those decimal pointed numbers into binary for the Amiga is there...?

Or am I being a donut? (=most likely )

[StingRay]

Originally Posted by Vortex

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

Had to add double buffering to the routine to make my 1337 timer work. ;D

[pmc]

Yes I was being a donut - no surprises.

I thought about it for a couple of minutes, which is what I should do before I ask obvious questions anyway.

Instead of writing a list of angles and then using these to lookup into my sin and cos tabs I just write out a list of 2^14 sin cos values and read these in instead without converting from decimal angle numbers.

Then I can use half or even quarter steps cos I'll be referring to the angles directly by their 2^14 whole fixed number representation.

OK - another thing to do to my routine then...

[pmc]

Cool.

Cheers StingRay.

By the way, I mean your testing is cool. If my routine is taking 88 of a max 91 rasterlines to draw a wireframe cube then my routine is definitely NOT cool.

[StingRay]

Originally Posted by pmc

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.

Go for it, first of all, add double buffering. :P

Originally Posted by pmc

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?

The sin/cos table I use in my 3d engine has a size of 40960 bytes. Hint hint. =)

Originally Posted by pmc

Enlighten me more Obi-Wan!

I hope I did without spoon-feeding you too much. =)

[pmc]

Originally Posted by StingRay

I hope I did without spoon-feeding you too much. =)

Just enough to make me think for myself and that, after all, is what I should be doing really. Your tutoring was spot on.

Thanks for your continuing advice and encouragement as always mate.

[pmc]

Watcha chaps.

Been having a think about optimisation for my 3D cube routine. It seems to me that the main thing to do would be to cut down the number of muls to the absolute minimum possible.

After something mentioned to me by Vortex the other day I've been looking at the matrix and rotation calculations.

In a matrix like this:

1 2 3
4 5 6
7 8 9

when the angle of rotation of x, y & z is equal, values 1 & 9, 2 & 6 and 4 & 8 are equal. So, re-using those values takes the routine that builds this rotation matrix from 16 signed multiplications down to 11.

Also, I've been thinking that, at least for a 100 * 100 * 100 cube, the only values required to represent all the points are combinations of 50 & -50.

So, if I multiplied 50 & -50 by all the values in the matrix I would have the values that could be used to construct all of the rotated points of the cube. I would only have to put these values into the correct x, y & z orders for all the various rotated points.

Doing this would take the 72 muls required to rotate all the point values one by one through this matrix down to the 18 required to multiply 50 by the 9 matrix values and -50 by the 9 matrix values.

Bearing in mind the duplicate matrix values though, this could be reduced even further as the multplication of 50 & -50 with values 1, 2 & 4 of the matrix would also provide the result of the same calculation with values 9, 6 and 8 respectively. This should save another 6 muls from the rotate points routine.

Going from 88 to 23 muls prior to perspective transform will save loads of time.

Now I just need to find a way to do the above theory in code...

Of course, any comments or suggestions as to whether I'm totally barking up the wrong tree or not are welcome.

[pmc]

Hello again boys.

Well, I went away and optimised my 3D wireframe cube routine.

Check out the attached source code for the optimised version but in brief, the improvements are:

There are no more x,y,z angle tabs - just 2^14 fixed point cos and sin tables.

The number of muls in the build_matrix and rotate_points routines has been reduced from 88 to 20.

The two muls #256 from the perspective_transform routine have been replaced with ext.l and lsl.w #8. That should make StingRay's eyes feel better!

I still need to add double buffering and improve the cos and sin tabs so that the cube is less shaky but it's definitely now a much faster routine.

Talking of which, StingRay, would you mind running the new version through your speed tester routine so I can get an idea of just how much faster it is?

[Vortex]

Excellent job... All this spinning must make you dizzy

Question: What if I want to rotate around each axis at different 'speeds'...? (Yeah I know, spoiling all the fun this question is... ).
Anyway, let me say I'm really impressed by what you've accomplished so far. It's gonna be a very nice mega demo...

Cheers,

Lars

[pmc]

Originally Posted by Vortex

Question: What if I want to rotate around each axis at different 'speeds'...? (Yeah I know, spoiling all the fun this question is... ).

Not a bad question.

It can definitely be done, including with the optimised version of the routine. You'd just need to read in separate cos / sin numbers for the x, y & z angles. This would only affect the build matrix part of the code as this is the only part where differences in x, y & z angles have an effect on the calculations. Obviously, doing these angles separately would mean the current build matrix routine would need to be amended slightly and would probably get a little more complicated - but not too much.

The reason I used only one angle for x, y & z is mainly cos I just want a spinning cube and equal angles gives (I think...) a nice spin.

Originally Posted by Vortex

Anyway, let me say I'm really impressed by what you've accomplished so far.

Cheers man, appreciated. To be honest I've really enjoyed doing this routine. I've done lots or reading, lots of pre-planning and lots of work with the debugger checking calculations. Plus this is really the first routine where I've done what I would consider 'real' optimisation. It's all kinda made me feel more like a proper coder.

Originally Posted by Vortex

It's gonna be a very nice mega demo...

I hope so! Next up for this routine is to try to get hidden lines working I think - not sure if I'll succeed in that aim as I think it's gonna tax me pretty heavily but, as always, I'll enjoy the challenge!

[pmc]

Originally Posted by Toni Wilen

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.

Originally Posted by pmc

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?

As a follow up to this earlier discussion I thought I'd try those small changes on my 3D cube routine to see if I would get a filled cube.

Unfortunately the blitter area fill didn't work properly.

In my line routine I did this:

bltcpth --> screen bitplane
bltdpth --> dummy screen biplane scratch area
set line mode and sing bit (one pixel / scanline line mode) bits in bltcon1

Then I did a blitter area fill but got the blitter fill turning off and on at the wrong places which is the problem you're supposed to get when trying to use blitter area fill for vector graphics polygons instead of a software Bresenham's line draw algorithm.

Any ideas people (Toni...?)? Did I still miss out doing something in my line routine?

[Leffmann]

Did you check your minterm? You need to invert the pixels when you intend to fill the outline, or you will have an odd number of pixels typically at the corners which will result in horizontal lines.

[pmc]

Watcha Leffman.

I've never done area fill ever before so I just followed the HRM advice and did a straight copy D=A ($F0 minterm).

Do you know what I should try using?

[Leffmann]

No I meant for when you draw the lines, the minterm must be $4A to invert each pixel it draws.

[pmc]

Ah OK, my mistake, I follow now.

Amending the minterm to $4A unfortunately didn't work.

I see what the problem is.

The blitter single pixel per scanline mode works *but only for the line being drawn* - it takes no account of other lines you might draw with the blitter that cross the same horizontal scan line.

For example, you could draw a vertical line:

|
|
|

and in single pixel mode the blitter will make this a solid line (no gaps). However, if you think of a perspective transformed cube head on with no rotation, you actually end up with several solid vertical lines like this on screen:

1...2.........3...4
|...|.........|...|
|...|.........|...|

Which means that the blitter turns on area fill at point 1, off again at point 2, on again at point 3, off again at point 4 etc. across the cube.

Because of this I don't think blitter area fill is adequate for vector graphics.

[Leffmann]

The blitter line draw and area fill modes are intended for just this and they will draw filled polygons if you just use them right. The majority of filled 3D graphics you see in classic demos use nothing but the blitter. The $4A minterm will invert pixels and so any common edges between faces that you draw will cancel each other out and you will end up with a correct outline, though you should detect these common edges and not draw them at all since it wastes clock cycles.

Use ASM-One to save the screen memory to disk and convert it to an IFF with GfxMaster or similar and attach so we can see, it makes it easier to see where things go wrong.

[pmc]

Originally Posted by Leffman

The majority of filled 3D graphics you see in classic demos use nothing but the blitter.

Interesting to know.

I realise the blitter area fill works in a very simple way and that to get it to do what you want requires drawing edges properly but I suppose I was just being hopeful that the little trick Toni explained would give a nice shortcut.

I should know better than that really.

Anyway, for those interested, if you do just try to take a shortcut like I did in these little tests what you end up with is as per the attached .png image.

[Leffmann]

Ok the problem here is that you're drawing excess lines which invert the filling. You need to draw a clean outline for the blitter to fill it solid, and the way you typically do this is by defining the set of lines that outline each polygon in your model. In the case of a cube you would define 4 lines per face and the lines that are common between two faces would simple cancel out (again, ideally you should detect duplicate lines and not draw them at all to save time) and you would end up with a clean outline resulting in a solid fill.

EDIT: attached a simple illustration to show how individual faces in 1 bitplane are drawn and the effect of the common edges being cancelled out for a clean outline that can be filled correctly.