camillo

5th October 2002 16:04 UTC

New APE plugin
HI!
I made my first APE plugin for Winamp3.
You can find it here:

http://www.winamp.com/components/det...onentId=122157

Can you tell me what do you think about it?
If you are an AVS coder, do you think it could be useful?

I need some positive answers to go on and make it better and better.

Thanx
Camillo

jheriko

5th October 2002 17:05 UTC

That would be useful for feeding DMs but it is completely unreactive to the sound, which kind of puts me off of ever using it.

Xion(810)

5th October 2002 17:42 UTC

I kinda like it, and I am experimenting with it myself...

UnConeD

5th October 2002 19:02 UTC

I don't like it at all.

1) The interface... this is the 100% stereotypical programmer interface: let the user enter numbers in an obscure format and disallow any immediate visual feedback. Instead, why not use sliders for the individual constants, or even just different editboxes. Also note that the words 'int' and 'float' are meaningless to non-programmers. What do the constants mean by the way? Your instructions tell the user what to do, but not how to do something.

2) Why do you need to push that button to see the result? Why not recalculate whenever the constants change?

3) The name. It's a render effect so it should be in the render section, not in the main one.

4) Resolution dependence. The APE uses a fixed coordinate system rather than adapting itself to the window size.

5) Aliasing artifacts. The colors don't blend smoothly, there are sudden jumps. This causes apparent horizontal and vertical lines to appear. I assume this is because you calculate a fixed color ramp between the two colors once, which is not detailed enough.

6) Speed. The APE causes a huge FPS hit. Maybe you need to optimize it some more?

Sorry if I sound too critical, but AVS is a really great piece of software because all its components are powerful and well thought out. I've written some APEs as well, so I know what I'm talking about.

Xion(810)

5th October 2002 22:06 UTC

Coned, what kind of crap computer are you using? I made a preset with it and it's running smooth at 26fps...:weird:

UnConeD

6th October 2002 02:16 UTC

Thank you for calling my computer crap for no particular reason.

I didn't say it ran at 5 fps or something, but I find that the performance hit is too high for this simple render effect. Even my metaballs run faster here, and they do a 30x30x30 marching cubes + rasterisation of the resulting mesh.

jheriko

6th October 2002 04:36 UTC

Thank you for calling my computer crap for no particular reason.

camillo

7th October 2002 11:10 UTC

1) The interface... this is the 100% stereotypical programmer interface: let the user enter numbers in an obscure format and disallow any immediate visual feedback. Instead, why not use sliders for the individual constants, or even just different editboxes. Also note that the words 'int' and 'float' are meaningless to non-programmers. What do the constants mean by the way? Your instructions tell the user what to do, but not how to do something.

2) Why do you need to push that button to see the result? Why not recalculate whenever the constants change?

3) The name. It's a render effect so it should be in the render section, not in the main one.

---

Yathosho

7th October 2002 11:27 UTC

Originally posted by camillo
[Camillo] The reviewer put it in that section; I know it is wrong

camillo

7th October 2002 12:18 UTC

section

unconed was referring to the section in the avs editor

UnConeD

7th October 2002 13:27 UTC

To place an APE in a submenu, just name it "Submenu / Name". AVS will split it up at the slash.

And as far as the jumps in palette are concerned, they're definitely there. I'm a kind of 'pixelspotter' though (I can easily see details in pictures, compression artifacts et al. that others don't). It's not very noticable. Check the image to see what I mean below. I put the image through a blur filter, which has causes a much smoother result to appear. Compare the areas indicated by the arrow (the images are zoomed 200%; I blurred before zooming of course), you'll see the left one has jumps in the color.

http://acko.net/dump/renderplasma.png

Oh and I wouldn't submit APEs to Winamp.com until they have an APE section. People will think it's a regular plug-in. Chances are they won't get it to work (I get tons of mails of people who download my presets and don't even get them to work), and if they do, they'll complain it's not varied enough.

As for the interface issue, you say "it's the only one that allows a variable number of inputs". Not so. You created this interface from the idea 'the user needs to input a variable number of coefficients representing different layers'. This is bad. The good idea is: 'the user needs to setup a variable amount of layers, each with its own coefficients'. Here's a different proposal:

http://acko.net/dump/renderplasma2.png

camillo

7th October 2002 14:06 UTC

yep
About the blurfilter... I tried it averaging with the next 6 pixels in a row, but it is TOO slow...
Maybe I am doing wrong with the ape architecture...
How do you code apes?
My ape sweeps all pixels of the avs window and renders it on the fly.
Then it sweeps everything again with the blur.
Should I soften during render?
Should I use double buffering? Having smaller buffer in memory and stretching it on to screen? Or whats the right mode? My code is very smooth and optimized... I really don't know how to improve it without going to asm.

I really dont know why Winamp site is so negligible with apes.
There's no download section and no forum section.
I think they want to push scripting and skinning.
Did you asked for that?

Good idea for the interface.
But I will concentrate on the interface after optimizing my effect.

Camillo

UnConeD

7th October 2002 14:24 UTC

I wouldn't use a blur filter if I were you. I think the problem is that you're calculating the color gradient in advance, but that it's not detailed enough.
Or maybe there are rounding errors that cause the numbers to jump a bit?

And actually the only way to speed up your code is indeed to use ASM. Almost all my APEs these days have hand-optimized assembly in the render section, simply because it's so much faster. Especially if you use MMX: you can blend and add 32-bit pixels with minimal effort, like this:

movq mm0, pixel1;
movq mm1, pixel2;
paddusb mm0, mm1;
movq pixel1, mm0;

This will take the 32-bit 'pixel1' and 'pixel2', will add them together channel by channel and will clip the value at 0xFF.

In C/C++, this would be something like:

min(0xFF, (pixel1 & 0xFF) + (pixel2 & 0xFF)) | min(0xFF00, (pixel1 & 0xFF00) + (pixel2 & 0xFF00)) | min(0xFF0000, (pixel1 & 0xFF0000) + (pixel2 & 0xFF0000))

I don't need to tell you that the first is just a tad faster ;). And in fact, most color-related things are actually a lot easier in MMX/ASM than in C++. You'll be happy you switched ;).

camillo

8th October 2002 09:42 UTC

cool
But why the minus? Shouldnt be there an average value?
Like:

((pixel1 & 0xFF) + (pixel2 & 0xFF))/2 | ((pixel1 & 0xFF00) + (pixel2 & 0xFF00))/2 | ((pixel1 & 0xFF0000) + (pixel2 & 0xFF0000))/2

I cant find any reference about MMX assembler instructions.
It seems to me that Intel blown them away or is secretely hiding them in its archives.

Could you please tell me an active link to some mmx instruction list?
Also the site www.mmx.com seems to be gone.

Maybe if you have some files about mmx, could you please email them to me?

Thanx
Camillo

camillo

8th October 2002 11:11 UTC

mmx!!!
ok i found something here about MMX:

http://www.intel.com/design/intarch/...xprog.htm#1466

Camillo

UnConeD

8th October 2002 11:57 UTC

Your code does a 50/50 blend, mind does an additive operation.

Actually I thought Intel had a pretty nice MMX page, showing how to use it for color operations. I don't have the URL anymore though and their site is hard to find anything on.

Karnov

8th October 2002 13:34 UTC

Quote: