Suggestions for learning

[pmc]

Originally Posted by Vortex

Photon was ok with us using the Scoopex cruncher last time I checked...

Good stuff. I was just kidding regarding using Photon's cruncher - from what you say of your experience with it and from what I've seen so far it's a pretty handy piece of software.

Originally Posted by Vortex

Haven't touched the mig for 2 weeks or so...

I've not really had any time for any real coding either, just little experiments with getting timers and pointers working fully PC relative style. Mainly been playing with my real A1200 with any spare time - I need to get the harddrive partioned / formatted / installed with Workbench etc. so we can use it for testing the megademo later on...

Originally Posted by Vortex

Too busy preparing for IBC (www.ibc.org). Only 2 days left to get everything working. As usual there's stuff to finish before the show starts... (perhaps we should begin earlier next time... )

Good luck for the conference!

[pmc]

Originally Posted by StingRay

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.

The reason for that jerky cube movement was that my code was shitty.

Now, admit it - you're not surprised.

I've rewritten both the build matrix and rotate points routines to use the minimum of swaps and rols with the result that the accuracy has now improved enough for the cube to be nicely smooth.

I just *had* to get it smooth before it got released in the megademo.

Anyways, check the attached source to see...

[pmc]

Hello guys

My hidden lines routine has now been adapted into a demo part for the megademo. \o/

It can handle multiple objects - not just a cube now - and transitions between them.

Along with the other stuff that's going on in the part I've managed to get this routine up to rotating 48 points in one frame so I'm pretty pleased that it hasn't been so bad an effort after all.

After the megademo has been released I'll post the source code of the hidden line part here so anyone who's interested can check it out.

[korruptor]

Brilliant, can't wait to see it

[pmc]

Watcha boys.

There was a subtle error (so subtle in fact that I still can't find exactly what it is! ) in the previous blitter line draw code I posted in this thread.

It was causing a problem with just one of my objects in my vectors part for the megademo. The object looked perfect when running on WinUAE - the bug could only be noticed on real Amiga hardware. Very strange.

Anyways, I've now rewritten the line draw routine to be neater, take less memory (no octant tab + some other savings) and (hopefully) faster too.

This new version is bug free as far as I can tell on both WinUAE and real Amigas.

Enjoy.

EDIT: According to my testing, this rewrite shaves about a rasterline per line drawn off the execution time of the previously posted bugged version.

[korruptor]

Thanks man

[StingRay]

Originally Posted by pmc

There was a subtle error (so subtle in fact that I still can't find exactly what it is! ) in the previous blitter line draw code I posted in this thread.

Makes me smile for some reason, guess you know why. Nice that you fixed it (and apparently optimised it too :P). =)

[pmc]

Originally Posted by korruptor

Thanks man

No worries mate - glad to be of service.

Originally Posted by StingRay

Makes me smile for some reason, guess you know why.

Originally Posted by StingRay

Nice that you fixed it (and apparently optimised it too :P). =)

Yeah, very nice - would have been far too lame to release an old skool megademo part that only ran 100% properly on an emulator!

Getting rid of non required octant tables, redundant checking (why did I check for is it less *as well as* is it equal instead of is it less or equal!? ) and redundant bitwise manipulations does tend to speed things up a bit!

Still, I'm learning all the time and you know what they say: you only learn from your mistakes...

[Leffmann]

Nice job on the new routine, and a further optimization you can do is to skip comparisons between values you will be subtracting anyway, as a comparison is essentially a subtraction operation, and tells you the result you're looking for. Then you can find the dX, dY and dY-dX values right away to find the line octant. Reducing memory accesses by keeping intermediate values in registers is a great optimization too.

Here's a spoiler attached:

[pmc]

Nice one Leffman.

I'll take some time with what you've suggested here and look at your routine to round out what you've said.

Without getting all mushy on you () I've got a lot of time and respect for your coding knowledge both because of what you've posted in many threads here (not just mine) and because of the quality of those routines of yours you posted YouTube links to previously.

It's very much appreciated that you've taken time not only to look at my efforts but also to suggest other ways I can increase my understanding.

I've found the best way to learn is to think as much as I can for myself and write my own code then, when someone with more skills and experience (in this case you... ) tells me how I could have done it better, the lesson sinks in more.

Top man.

[pmc]

Originally Posted by Leffman

and a further optimization you can do is to skip comparisons between values you will be subtracting anyway, as a comparison is essentially a subtraction operation, and tells you the result you're looking for.

So, rather than:

compare, branch on result, do the subtration (to find dx / dy) ordered so that the result is always positive and store

I should do:

Subtract, correct result to positive as required and store, obviously preferrably in a data reg rather than a mem location.

[pmc]

Originally Posted by Leffman

Reducing memory accesses by keeping intermediate values in registers is a great optimization too.

Another speed question in relation to this:

Say I've run out of data registers and I've got no choice but to store a variable to memory temporarily.

Is it quicker to save the reg to memory with something like this:

move.w   d0,savereg(a5)

or push it on the stack like this:

move.w   d0,-(sp)

[Samurai_Crow]

@pmc

IIRC, predecrements and postincrements are expensive on the '020+. Do the former especially if it's a single-byte offset.

BTW, are you subtracting -128 from the heap when you allocate it and all of the other heap accesses then adding -128 back on at the end when you deallocate it? That will insure that you're getting as many single-byte offsets as possible on the heap. Obviously this only helps if your heap is bigger than 127 bytes.

[StingRay]

Originally Posted by pmc

move.w   d0,savereg(a5)

or push it on the stack like this:

move.w   d0,-(sp)

Latter is faster (and shorter) since you don't have a 16 bit offset.

If you are sure that the upper part of d0.l is unused you could also do:

swap d0 and use d0.w for other things and to restore your value you'd just swap d0 again of course.

[pmc]

OK chaps, after thinking on Leffman's advice I went away and coded another version of my linedraw routine (attached).

It now has no unnecessary sub.w / cmp.w combinations using only sub.w and neg.w as required instead.

Also it now no longer has any unnecessary moves to or from memory locations and does everything with data registers.

Judging from the speed tests I've run there's no real difference in execution time between this new version and the previous version I posted but I prefer this new version as it's much neater.

I've not checked the routine Leffman posted (that would've been cheating ) against this one so maybe there's still some optimising I could do but if there is I can't see how at the moment.

Of course, I'm always happy to be corrected and learn some more.

Originally Posted by StingRay

Latter is faster (and shorter) since you don't have a 16 bit offset.

I thought so but thanks for confirming StingRay.

Originally Posted by StingRay

If you are sure that the upper part of d0.l is unused you could also do:

swap d0 and use d0.w for other things and to restore your value you'd just swap d0 again of course.

Hmmm. That's a neat little trick - 8 longword data regs can be used as 16 word regs like that - providing, as you say, you do it carefully.

Nice one.

[pmc]

Hello people.

Since fixing the linedraw code I've made a few additional, very minor, optimisations to the hidden line demo.

The demo as a whole seems to be able to handle rotating, transforming and drawing objects with around a maximum of 48 points in one frame. This number would probably increase slightly if *all* the demo was doing was the 3D objects but I can't imagine there would be time for a vast number of additional points.

So, my question is: how do the coders from way back when do routines that will handle literally hundreds of points (for example the hidden dot ball in Phenomena's Enigma demo) in one frame?

Are they always done with precalcs and other cheats or is there some kind of "secret" I've completely missed to speed the 3D calcs up massively?

[pmc]

Originally Posted by pmc

Are they always done with precalcs and other cheats or is there some kind of "secret" I've completely missed to speed the 3D calcs up massively?

Per my previous post, anyone...?

[Leffmann]

If you don't want to use any tricks or precalcs it's just a matter of optimization, and restricting the effect while still making it look good.

If you just want to do rotations then you can drop the matrix and vector multiplications and do planar rotations in the X and Y planes, and drop the Z rotation. Rotating in 2 axes will still look good as the Z rotation doesn't reveal any more of the object.

Now you can also convert from cartesian to polar coordinates and reduce the amount of calculations further, and if you're doing a sphere like in the Enigma demo then you can drop the perspective calculations as well. I can get down to 4 multiplications and 5 memory look-ups per point like this, 19 instructions for the entire loop, plotting included.

The next step (on a plain 68K) would be to unroll the loop, and to be able to do really many points you would go back to matrix and vector multiplications and quantize your object into f.ex a 256*256*256 grid, precalculate the 256 steps along your rotated X Y and Z axes and use the X Y and Z components of each point in your object as indices into these tables.

[pmc]

Originally Posted by Leffman

The next step (on a plain 68K) would be to unroll the loop, and to be able to do really many points you would go back to matrix and vector multiplications and quantize your object into f.ex a 256*256*256 grid, precalculate the 256 steps along your rotated X Y and Z axes and use the X Y and Z components of each point in your object as indices into these tables.

OK I understand this - this is the approach taken to do vectors on the C64. Precalc'ed tables and indexing into these from the object coords. This is, in other words, a multiplication shortcut which would obviously speed things up nicely. While there's no real alternative to this approach to produce vectors on the C64, to my mind, this is still cheating in the strict sense of the word on the Amiga due to the precalcs.

Originally Posted by Leffman

Now you can also convert from cartesian to polar coordinates and reduce the amount of calculations further, and if you're doing a sphere like in the Enigma demo then you can drop the perspective calculations as wel

I don't understand this yet - mainly cos I can be slow on the uptake.

What are polar coordinates and how do they differ from x,y,z cartesian coords?

Also, why no perspective required for a sphere? Points that are "further away" still need to be drawn / plotted closer together no matter what the object don't they?

[Leffmann]

Originally Posted by pmc

OK I understand this - this is the approach taken to do vectors on the C64. Precalc'ed tables and indexing into these from the object coords. This is, in other words, a multiplication shortcut which would obviously speed things up nicely. While there's no real alternative to this approach to produce vectors on the C64, to my mind, this is still cheating in the strict sense of the word on the Amiga due to the precalcs.

It's a bit more complex than just precalculating a multiplication, basically you're precalculating 3 vectors multiplied by 3 scalars, and all added together. The code I mentioned of 19 instructions can do ~250 points per PAL frame on an unexpanded A500, and I doubt you can break 500 with a "generic" rotate and plot routine using no precalcs, so unrolling loops and precalculating code and/or tables, this method in particular, is the only way to get arbitrary objects of thousands of points in full frame rate.

Originally Posted by pmc

I don't understand this yet - mainly cos I can be slow on the uptake.

What are polar coordinates and how do they differ from x,y,z cartesian coords?

Also, why no perspective required for a sphere? Points that are "further away" still need to be drawn / plotted closer together no matter what the object don't they?

Polar coordinates consist of an angle and a distance. You can replace:

X' = X sin a - Y cos a
Y' = X cos a + Y sin a

with

X = D cos (A + a)
Y = D sin (A + a)

which is obviously faster.

You can add perspective to a sphere, but being what it is, especially when just made up of tiny points on the screen, it gives you a lesser impression of depth than perspective does on f.ex a cube. Try it and you'll see. At least it's the one shape that doesn't look completely wrong without perspective.