I made my first demoscene effect in assembler!

[balrogsoft]

Hi, i made my first demoscene effect in assembler, i made little things in assembler some years ago, but now i'm learning a lot. I decided to make my first assembler effect this weekend, and i got it! I made a Chunky to Copper routine, and a rotozoomer effect. On my A600 is very slow, but on my A1200 with a 060, it runs very smoothly. I'm not very good with assembler (i'm a newbie), if somebody can give some suggestions to optimize my code, i will share my code:

ASM Source code

Executable

Thanks in advance.

[Karlos]

*** Interlude. A specialist from Finland will be along shortly  to answer all your questions ***


;-)

[Piru]

I'm a bit too drunk atm to make any detailed analysis, but I'll check it out later.

[EDIT]

But even when wasted I can give some ideas how to make it much faster (at least on older systems):

- Inline the innerloop (.NextX) subroutine calls.
- Use registers to store variables instead of memory. Do this at least for variables used in innerloop.
- Move out any 'y' related calculation from the .NextX loop, calculate these values before entering the X loop (this appears to have been done mostly, however).

[/EDIT]

[Karlos]

:lol:

[humppa]

Piru wrote:
I'm a bit too drunk atm to make any detailed analysis, but I'll check it out later.

:crazy:  :roflmao:  

[amiga92570]

 :pint:  :pint:  I think it helps!

 :-o

[DamageX]

Instead of calculating the coordinates of the source pixel in the texture every time you write a pixel to the copper list, I think it is faster to maintain a set of coordinates and modify them with predetermined values.

so your inner loop could look something like:

NextY:
move #30,d2 ; width of screen
NextX:
add.w d4,d0 ; modify source x coordinate (for every change
add.w d5,d1 ; modify source y coordinate  in x direction)
move.w #$07C0,d3 ; mask for y coordinate (32x32 texture?)
and.w d1,d3
lea Texture,a1 ; pointer to texture
add.w d3,a1
move.w #$07C0,d3 ; mask for x coordinate
and.w d0,d3
lsr.w #5,d3
add.w d3,a1 ; now we have the correct address
move.w (a1),(a0)+ ; copy a pixel from texture to screen
subq.b #1,d2
bne NextX
add.w d6,d0 ; modify source x coordinate (for every change
add.w d7,d1 ; modify source y coordinate  in y direction)
; probably something needs to be added to copperlist
; pointer in a0 so it points to next line
subq.b #1,LineY
bne NextY

hope that makes some sense and hasn't too many bugs...

for calculating the magic numbers in d4,d5,d6,d7
d4 = x_scale * cos(angle)
d5 = x_scale * -sin(angle)
d6 = y_scale * sin(angle)
d7 = y_scale * cos(angle)
(in my example code I use fixed-point math with 6 bits of fraction so multiply by 64)

[motorollin]

I bet you guys don't even need to run the executable. You can probably see the effect just by reading the code :lol:

jk

--
moto

[McVenco]

You can probably see the effect just by reading the code

:roflmao: :laughing:

[LawlessPPC]

very nice to see the word assembler these days

[Karlos]

Try to find a use for d3, d4, d5, d6 and d7. It seems you are only using d0 to d2. There are various frequently constants and variables in your code you could put into these registers to improve access times, at least on slower machines. Even on faster ones, a read from the datacache is not as fast as a direct register access.

[Karlos]

motorollin wrote:
I bet you guys don't even need to run the executable. You can probably see the effect just by reading the code :lol:

jk

--
moto

You don't see the (rotating) girl in a red dress? :lol:

[neuroflip]

Nice roto!!! but it's too slow on my a1200/030
it would be nice to see it with some optimizations... ride on!

 :-D  :-D  :-D

[balrogsoft]

Thanks a lot for your help, i decided to recode the routine, now i calculate the rotation of 3 points, with this 3 points i calculate the increment for every horizontal and vertical step, in ADA forum, an user gave me a link with a tutorial to make this effect as i explained. Now my routine works at decent speed on a plain A1200. I uploaded the new source and executable with the same name.

[Piru]

Okay, took a look at the code and optimized it couple of cycles. It should be slightly faster, but not much. I also fixed some small bugs from the startup code, made it render as fast as possible (it's much slower than vertical blank, so rendering from VBL doesn't make much sense), removed chipmem allocation, fixed random returncode etc.

ROTOZOOM.S
ROTOZOOM.exe