Suggestions for learning

[pmc]

Nice one Toni - definitely a good feature to be aware of for those guys like me addicted to using your superb emulator for coding.

Originally Posted by Toni Wilen

now it is real, proper cycle-exact emulation. Believe it or not

If you say so then I'm a believer!

[StingRay]

Originally Posted by Toni Wilen

Semi-offtopic:

You can use latest winuae betas 'v' debugger command to see exactly how DMA and CPU use bus cycles. (undocumented feature: use 'V' to see current frame, 'v' always shows complete previous frame)

Nice and useful feature, thanks for the info!

It should be very very accurate now (major rewrite few weeks ago). Pre-1.6.2 cycle exact was only approximately cycle-exact, now it is real, proper cycle-exact emulation. Believe it or not

I'll go with the title of an old Anarchy demo: "Seeing is believing". =)

[pmc]

Watcha boys.

I've been away on my summer holidays over the last couple of weeks but now I'm back and getting back into "coding mode" again.

Originally Posted by Leffman

You're just a tiny bit of structure and a few dot products away from drawing (convex) hidden line objects. Don't think in lines, think in faces. You have all the code and knowledge to make it work, you just need to determine if a face is hidden, and if it is you just don't draw it.

Been thinking about this. Check the attached source. It's a small update to my 3d cube routine. There's a couple more data structures in the source now - a face list, a number of edges list and a points list.

Instead of only drawing lines between points the routine now draws the object by drawing each face of the object by using these new data structures.

Doing it this way means drawing some duplicate lines but I want to get my routine closer to being able to draw different objects (not just a cube!) and also perhaps towards getting hidden line removal / filling too.

[pmc]

Well, it looks like I finally managed it.

Check out the attached source for a working hidden line vector cube routine.

As usual, I've gotta say thanks to a couple of guys:

@ Leffman - thanks for making me think of the object as made up of faces and not lines. Once I started thinking that way it became clear that a hidden face calculation would work when applied to trying to get hidden lines working -

@ StingRay - thanks for the general support and encouragement -

[Leffmann]

Nice job What's next on the list then?

[pmc]

Originally Posted by Leffman

Nice job What's next on the list then?

Cheers man.

Next on the list is to adapt this routine into a demo part for inclusion in the first Retro Megademo!

[gilgamesh]

That's really cool.

[pmc]

Originally Posted by Gilgamesh

That's really cool.

Thanks Gilgamesh Which bit? Getting hidden lines working or adapting it for the demo?

[gilgamesh]

Both

[pmc]

Too kind.

[pmc]

Hello people.

Is it possible to use a processor's FPU to speed up vector stuff on the Amiga?

In what way and how would someone go about doing that?

I've got an A1200 with an 060 accelerator card & the 060 has an FPU but I must admit I've never done any coding on that system. Might be an interesting side project for me.

I suppose you need to be a bit more system friendly with how the code runs than I normally am in order to keep the 060 accessible via the driver software that I presume gets loaded by the OS on startup for the card - or am I totally wrong?

Are there any demo examples out there that require an FPU to do their vector stuff?

[StingRay]

Originally Posted by pmc

Hello people.

Hi PMC =)

Originally Posted by pmc

Is it possible to use a processor's FPU to speed up vector stuff on the Amiga?

In what way and how would someone go about doing that?

You can use the FPU to do all the matrix calculations which means better accuracy. Also, once you start coding perspective corrective texture mappers you don't want to do that using fixed point, believe me.

Originally Posted by pmc

I suppose you need to be a bit more system friendly with how the code runs than I normally am in order to keep the 060 accessible via the driver software that I presume gets loaded by the OS on startup for the card - or am I totally wrong?

You don't really have to care about the 060, as long as you avoid any dirty tricks there's no problem.

Originally Posted by pmc

Are there any demo examples out there that require an FPU to do their vector stuff?

All later TBL and Loonies demos f.e. but I suppose FPU is mainly required for the persp. mapper. I may be wrong though.

[pmc]

Watcha Sting

Originally Posted by StingRay

You can use the FPU to do all the matrix calculations which means better accuracy.

Ah OK - cool.

Originally Posted by StingRay

Also, once you start coding perspective corrective texture mappers you don't want to do that using fixed point, believe me.

LOL. If you say so, I believe! Those texture mappers must be "a bit tricky" then shall we say?

Originally Posted by StingRay

You don't really have to care about the 060, as long as you avoid any dirty tricks there's no problem.

So I can just zap the OS as normal and still have the 060 and its FPU run my code?

Cheers for pointing me at those demo prods - I'll take a look.

[StingRay]

Originally Posted by pmc

LOL. If you say so, I believe! Those texture mappers must be "a bit tricky" then shall we say?

Not hard to do if you use FPU, if you try doing it with fixed point you'll have to deal with a lot of underflow errors etc. I never got my fixed point perspective mapper to work correctly despite using 2:30 fixed point etc.

Originally Posted by pmc

So I can just zap the OS as normal and still have the 060 and its FPU run my code?

Yep.

[pmc]

2^30 fixed point not accurate enough!

Originally Posted by StingRay

Yep.

Nice one.

As always mate, your advice is much appreciated.

[StingRay]

Originally Posted by pmc

2^30 fixed point not accurate enough!

Not for the 1/z calculations which are required for the perspective correction. Check attached source to get an idea, it's the integer version of my persp. mapper, done in 2002. I never bothered to try it again using fixed point.

Originally Posted by pmc

As always mate, your advice is much appreciated.

You're welcome! Looking forward to your megademo. \o/

[pmc]

Originally Posted by StingRay

Check attached source to get an idea

Thanks man - I'll check it out.

By the way I went away and checked out Ocean Machine by TBL. Heavy texture mapping in that one so I presume heavy FPU use as well... Gotta say - Kalms:

At the moment I'm struggling a bit converting the code for the current routine I'm working on for the megademo to entirely PC relative (requirement for Vortex' trackloader) but I'll persevere. I'm sure there'll be some useful lessons learned along the way.

[StingRay]

Originally Posted by pmc

By the way I went away and checked out Ocean Machine by TBL.

Not my favourite TBL demo (I still prefer their older stuff like Rain, Panacea or Darkside) but top notch engine indeed, one of the best available on Amiga.

Originally Posted by pmc

At the moment I'm struggling a bit converting the code for the current routine I'm working on for the megademo to entirely PC relative (requirement for Vortex' trackloader) but I'll persevere. I'm sure there'll be some useful lessons learned along the way.

Fastest approach would be to pack the executables using some absolute address cruncher. Then you can just load them into memory at the correct address and don't have to adapt your code at all. However, having 100% pc relative code is nice too and can make life easier. =) And it's not that hard to achieve either, just sacrifice an address register (if you can) and use that throughout the whole code thus avoiding 32bit relocs. I.e. instead of

	move.l d0,some_Var

you could use

	lea VARS(pc),a6
	move.l d0,some_Var-VARS(a6)

Hope that helps.

[pmc]

Originally Posted by StingRay

Fastest approach would be to pack the executables using some absolute address cruncher.

I suggested that to start with but Vortex is in charge on the loading / decrunching side so I'm fitting in with his vision.

For our sins we're using Photon's Scoopex cruncher / decruncher - what *are* we thinking! (Hi Photon. )

     lea VARS(pc),a6
     move.l d0,some_Var-VARS(a6)

So it might be a good idea for me to reformat my data into one of those rsreset type structures I've seen you using... OK, cheers.

I'll check that other TBL stuff.

[Vortex]

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

Haven't touched the mig for 2 weeks or so... 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... )