Suggestions for learning

[gilgamesh]

Right, you'll need something more elegant for hidden surface removal. There are several algos, e.g. Painter's (with Newell's).

I wouldn't dig through Alpha Wave's sourcecode either, but what he has to say about accelerating 3D especially on 68k is interesting.

EDIT: Hopefully this will work on 68k in acceptable time.

[pmc]

OK Sting, got a better idea of what z-buffer is now, thanks.

Thanks for the link gilgamesh - interesting.

So, on a 68000 Amiga then, perhaps it's possible to make a vector routine capable of supporting concave (inconvex) objects by *not* doing hidden surface removal using normals and instead drawing all object faces from furthest to nearest by sorting on z values and relying on the fact that the near faces will overwrite ones further away.

You would end up drawing things that might not be visible at all by the time the rest of the faces were drawn on top of them but I'm guessing the time wasted doing this would still be less than a per pixel z-buffer approach.

Originally Posted by gilgamesh

I wouldn't dig through Alpha Wave's sourcecode either, but what he has to say about accelerating 3D especially on 68k is interesting.

Oh, and I meant to say, sorry - when I said what I did about source code I didn't mean to be rude about what you posted a link to - the article was indeed very interesting!

[Leffmann]

Sweet

There's a simple way of reducing this to 2 bitplanes. Since there's never more than 3 sides visible at the same time, you only need 3 colors, and can just keep and increase a counter for each visible side and use this to determine what color to draw in, and to find the equivalent color register.

If you're drawing concave objects you should still cull polygons facing away, as they will still be completely covered just as they were when the object was convex. An exception is of course if you want transparent objects, or open meshes with two sided polygons.

The problem then is just to resolve the order to draw the polygons in. You can also separate the mesh into convex sets and draw several polygons and merge them into the scene all at once. In an Amiga-blitter context this method should always be faster than doing the same with a single polygon at a time.

[frank_b]

Originally Posted by Samurai_Crow

@StingRay

I thought somebody on EAB had managed to make loops in their copper list using a similar technique. I haven't actually tried it yet though.

Mask of some off the compare bits. You can do loops with a compare that way.

[pmc]

Good morning people.

It's quite a long time now since I promised that I would post the source code to my vectors demo so I thought it was about time I kept that promise.

In comparison to the work of the scene coding greats on here (all the usual suspects: StingRay, Photon, hitchhikr etc. etc.) this demo is nothing special in any way at all. But, for me, I think it probably represents about the peak of the coding skills I've managed to learn over the last few years.

It definitely took me *a lot* of reading, thinking, calculating, coding and peering at my debugger to finish. The linedraw routine went through three iterations to get it to a fairly nicely optimised bit of code and the vector routines went through at least two iterations in an effort to improve the accuracy of them and take the shakes out of the objects.

Whether or not the way I've done things in this demo is good or bad is a whole different question.

All in all I feel pretty proud that I managed to go from where I started in this thread (ie. knowing *nothing* about vector routines) to a finished demo. As always however, I couldn't have managed it without all the people who posted in this thread with help and advice so I want to say a big thank you to all of you guys.

Hope you enjoy the source code, there's plenty of commenting in there and, as always, I'm here if you want to ask something more specific.

[Nostalgeek]

I bow to you, Mister. This is made of 100% genuine awesomeness.

As said in my other post, you're an inspiration.

Post more code! Post more code!

[Lonewolf10]

Ok, I have been working on a few things and learning a few things here and there. I have a few questions:

1) Which is best tst vs. cmp? Do they do the same thing and which is faster?

2) movem.l - when getting/retreiving data does it follow a preset order. For example:

   moveq #1,d0
   moveq #2,d1
   moveq #0,d2
   movem.l d0-d2,-(sp)
   movem.l (sp)+,d2/d0/d1

Would the above code generate values of #1 in d2,#2 in d0 and #0 in d1? Or regardless of the order of the destination registers (as long as the same number stored is retrieved) the data would always be restored as it was?

Is there a play raw sound example around on here somewhere? I think I have mastered the copper, understand sprites now and would now like to (attempt to) learn how to play sound. However, I can't find any decent examples (Google get's 4,660 useless results when searching for: m68000 amiga play sound in assembler)


Regards,
Lonewolf10

[StingRay]

Originally Posted by Lonewolf10

1) Which is best tst vs. cmp? Do they do the same thing and which is faster?

Tst checks if the operand is zero, not more. cmp is much more flexible and thus slower. cmp.w #0,d0 is the same as tst.w d0.

Originally Posted by Lonewolf10

2) movem.l - when getting/retreiving data does it follow a preset order. For example:

   moveq #1,d0
   moveq #2,d1
   moveq #0,d2
   movem.l d0-d2,-(sp)
   movem.l (sp)+,d2/d0/d1

Would the above code generate values of #1 in d2,#2 in d0 and #0 in d1? Or regardless of the order of the destination registers (as long as the same number stored is retrieved) the data would always be restored as it was?

When restoring registers the order is "low to high", i.e. your movem.l (sp)+,d2/d0/d1 is invalid and you'll either get an error message from your Assembler or it'll be converted to the correct movem.l (sp)+,d0/d1/d2 silently. What you wanted to try can be "emulated" with
move.l (sp)+,d2
move.l (sp)+,d0
move.l (sp)+,d1

Originally Posted by Lonewolf10

Is there a play raw sound example around on here somewhere? I think I have mastered the copper, understand sprites now and would now like to (attempt to) learn how to play sound. However, I can't find any decent examples (Google get's 4,660 useless results when searching for: m68000 amiga play sound in assembler)

Find my very simple and very old code to play a sample attached.

[Lonewolf10]

I DL'ed LiveWires.zip, but it doesn't compile in Devpac 2. Can anyone tell me where I can find a more recent version of Devpac?

@PMC

Have you considered putting any of your demo's on the Amiga Demo Archive? ( http://ada.untergrund.net/index.php )


Regards,
Lonewolf10

[pmc]

Originally Posted by Lonewolf10

I DL'ed LiveWires.zip, but it doesn't compile in Devpac 2. Can anyone tell me where I can find a more recent version of Devpac?

What error do you get...? I can give you a later version of Devpac.

Originally Posted by Lonewolf10

Have you considered putting any of your demo's on the Amiga Demo Archive?

My stuff is on pouet.net and almost all of it is on bitworld but I haven't uploaded to ADA although I do have accounts over there...

EDIT: Devpac 3.18 attached.

[Lonewolf10]

@Stingray

Thanks for the help and the code

@PMC

I believe it was the movec instruction which is 68020 and later(?). I run WinUAE in pretty much the same configuration as I ran my Amiga 600's (e.g 68000, ECS, 2MB Chip RAM, 8MB Fast RAM).
Thanks for Devpac3.18

I don't go on Pouet that much, usually ADA. Plenty of great demo's on both sites though


Regards,
Lonewolf10

[Lonewolf10]

Originally Posted by StingRay

Find my very simple and very old code to play a sample attached.

What is the line:

DELAY 1

supposed to do? I can't find any reference to a DELAY macro within either Devpacs I have (2 and 3.18). Am I overlooking something?
(I tried replacing DELAY 1 with a Dbra loop routine (count starting at #50), but whilst the code started playing the sample, it also crashed my Amiga!).


Regards,
Lonewolf10

[pmc]

@ Lonewolf10 - it's probably one of Sting's own macros defined in an include he uses (or used to use...?) but didn't give you with the source.

The code is more to give you an indication of how playing a sample works than to be directly assemble-able probably although I'm only guessing.

[Lonewolf10]

OK.

I saw that he used some of the registers (didn't label them though!) and was hoping to get the code working before labelling them. I guess now I'll label them and RTHM

(RTHM = read the hardware manual)


Regards,
Lonewolf10

[StingRay]

Originally Posted by Lonewolf10

What is the line:

DELAY 1

This is a macro to wait a little before writing to the audio registers. You can easily create your own.

Originally Posted by Lonewolf10

(I tried replacing DELAY 1 with a Dbra loop routine (count starting at #50), but whilst the code started playing the sample, it also crashed my Amiga!).

The code won't crash your Amiga so I suppose you did something wrong. What exactly happened?

Originally Posted by Lonewolf10

OK.
I saw that he used some of the registers (didn't label them though!) and

What do you mean with "didn't label them"? If you mean that I just used the plain hardware addresses instead of symbolic names such as AUD0VOL f.e., well, I never used that. Guess it's a matter of taste but I prefer the plain $dffxxx syntax.

[Lonewolf10]

Originally Posted by StingRay

What do you mean with "didn't label them"? If you mean that I just used the plain hardware addresses instead of symbolic names such as AUD0VOL f.e., well, I never used that. Guess it's a matter of taste but I prefer the plain $dffxxx syntax.

When using registers, I prefer to use the register names. No offense intended.

    movem.l    d0-d3/a0-a1,-(sp)
    move.l    (a3)+,d1        ;VOLUME
    move.l    (a3)+,d0        ;FREQUENCY
    move.l    (a3)+,d2        ;LENGTH
    move.l    (a3)+,a0        ;START

; >>>>> Code by Stingray from the English Amiga Board forums <<<<<
; a0=address of sample
; d0=frequency
; d1=volume
; d2=sample length (in bytes)

    lea    $dff000,a1
    move.w    #8,$96(a1)        ;Audio channels off (cut DMA action) (DMACON)
    move.w    #50,d3            ;set delay length
TESTSAMPLAY_DELAY:
    dbra    d3,TESTSAMPLAY_DELAY    ;loop until d3=-1
;    DELAY    1
    lsr.l    #1,d2            ; bytes -> words
    move.l    a0,$d0(a1)        ; pointer at sample        (AUD3LCH)
    move.w    d2,$d4(a1)        ; length (in words)        (AUD3LEN)
    move.w    d0,$d6(a1)        ; frequency            (AUD3PER)
    move.w    d1,$d8(a1)        ; volume (up to $40)        (AUD3VOL)
    move.w    #$8008,$96(a1)        ; and GO! (Channel 0 on)    (DMACON)
    move.w    #50,d3            ; set delay length
TESTSAMPLAY_DELAY2:
    dbra        d3,TESTSAMPLAY_DELAY2
;    DELAY        1
    move.l    #Empty_Sample,$d0(a1)    ; Point at empty data
    move.w    #2/2,$d4(a1)        ; (AUD3LEN)
    movem.l    (sp)+,d0-d2/a0-a1
    rts

Empty_Sample    dc.l    0,0        ;Empty sample

Volume is set at 40 (decimal), start and length are the starting and ending address of the sample to be played - I am using the same sample to test this with until I get it working, so I know the sample length (6046).

With the frequency set at 8000, I get a guru with the error code "8000 0004". With the frequency at 4000 I get a guru with the error code "8000 000B".
The sample seems to play fine, the problem appears to come when exiting the code...


Regards,
Lonewolf10

PS. Yes, when I use other peoples code I do make a note of it in my source. Credit where credits due, I always say.

[StingRay]

Originally Posted by Lonewolf10

When using registers, I prefer to use the register names. No offense intended.

None taken! I know the hw registers by heart and thus never use register names.

Originally Posted by Lonewolf10

     movem.l    d0-d3/a0-a1,-(sp)
    movem.l    (sp)+,d0-d2/a0-a1
    rts

The sample seems to play fine, the problem appears to come when exiting the code...

Watch your stack!

[Lonewolf10]

Ok, stack problem fixed and now I don't hear a thing
I'm gonna have to take a closer look at it over the weekend, I'm too tired now.

Edit:

@PMC

Finally got around to compiling your Livewires demo. It's pretty cool. Could do with some copper tricks though... plain rotating 3D objects have been done many a time - although even that is still way out of my league at the moment.


Regards,
Lonewolf10

[Lonewolf10]

Hmm.... I think I know why the code was failing. The length of the sample is converted to words, but because the sample has to be sampled twice per scanline the length needs to be doubled. Right?

A quick question:

1) what's the difference between loop and loop: when used as a marker on a new textline?


Regards,
Lonewolf10

[StingRay]

Originally Posted by Lonewolf10

Finally got around to compiling your Livewires demo.

Tsk tsk!

Originally Posted by Lonewolf10

Hmm.... I think I know why the code was failing. The length of the sample is converted to words, but because the sample has to be sampled twice per scanline the length needs to be doubled. Right?

The length of the sample is converted to words because the AudXLen registers ($dff0a4, $dff0b4 etc) need the length in words.

Originally Posted by Lonewolf10

A quick question:

1) what's the difference between loop and loop: when used as a marker on a new textline?

There is no difference, both are normal labels. Back in the day labels needed to end with : but nowadays that's not required anymore.