UnConeD

17th October 2002 23:56 UTC

Render Picture II
As you might know, I'm working on a "Render > Picture" replacement that expands the flawed original.

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

This is what it looks like at the moment. Firstly, it's faster than the original for most pictures (except tiny ones), because it calculates the enlarged image only once rather than every frame. This also means it does bilinear filtering at no cost at all (only the pre-processing takes a bit longer, but that happens only once). I also implemented all the standard blend modes (replace, 50/50, additive, maximum, sub1, sub2, multiply, xor, adjustable).

Currently it only does .bmp, but I'm currently figuring out libpng (for .png support). Once that's done, I'll try JPEG, if I find a good library.

However I have a few questions about what else I should do. For instance, the original component has a "blend 50/50, onbeat additive" mode. This would logically expand to an extra output selection box for onbeat, so you can do any combination of regular and onbeat modes. However, I've almost never used this feature, so I'm not sure if I should implement it. Do you guys ever use it?
You could easily duplicate this effect by using two instances of the picture renderer in onbeat-switched effect lists, where one receives an inverted beat pattern.

Next is aspect ratio correctness. Implement it?

Finally any other suggestions? I don't want to turn it into one mega component though, because you can do quite a lot with AVS already. This APE is of course mainly aimed at experienced AVSers, so I'd like as little fluff as possible: only really useful stuff.

Karnov

18th October 2002 04:15 UTC

Next is aspect ratio correctness. Implement it?

Tuggummi

18th October 2002 06:36 UTC

Could it be possible to define the position of the picture? (like in text)

Yes you can do it with movements, but if it's faster to implent it directly to the ape it would be better.

I was also wondering about defining the picture size also. Possible? fast?

Or am i just talking crazy :igor:

Zevensoft

18th October 2002 07:57 UTC

Yeah, have an option for size based on both percent and absolute pixels.

Yathosho

18th October 2002 11:46 UTC

hm, does this work with transparent PNGs aswell?

UnConeD

18th October 2002 12:15 UTC

If I manage to read PNGs, making an additional blend mode "Alpha channel" shouldn't be a problem.

jheriko

18th October 2002 13:17 UTC

Alpha channel sounds infinitely useful. I don't suppose youd be able to make a 'draw alhpa channel only' option? Then you could make 'quake 3 shader' style effects for textures. :)

Either that or have multiple blend modes for the alpha channel... but I think that would be the more awkward way to do it.

Tonic

18th October 2002 15:24 UTC

If you could add possibilities for "On "N" beats change picture" will be cool. User may chouse folder with pictures and program will load pictures in name order or randomly from this folder on every "N" beats. Or may be instead of loading from one folder user may create playlist with pictures (from different folders) than program will load files from this playlist again in playlist order or randomly.

UnConeD

18th October 2002 15:48 UTC

If you want to use multiple pictures, wouldn't the improved AVI player be better?

As I said, I don't want to make a mega APE, just fix the flawed Render / Picture.

"alpha channel sounds infinitely useful. I don't suppose youd be able to make a 'draw alhpa channel only' option? Then you could make 'quake 3 shader' style effects for textures."

jheriko

18th October 2002 16:03 UTC

I was just thinking about saving on pictures. Where as you would need two pictures for a texture and an alpha channel you could save on the number of pictures needed by using the same one for both. You might want to use the alpha channel from the picture on something else as well as the picture, say if you wanted to add blend some scopes over a picture (for whatever reason) and you wanted a circular black hole in the middle, you could recycle the alpha channel from the picture to multiply with the scopes to get the hole in the middle of them to match exactly with the hole in the middle of the texture so that when you add them together you don't end up with scopes in the hole.

UnConeD

18th October 2002 16:38 UTC

Just do a subtractive blend of a picture of the alpha channel on the scopes? By the way, additive blending doesn't need an alpha channel :).

I'm only going to do replace-alpha blending. Most other modes don't need it (you can modify the picture itself), and I fail to see the point of an alphablended XOR for example :). Besides, you could use a regular AVS buffer blend for that anyway (see what I mean with keeping it simple? :)).

jheriko

18th October 2002 16:51 UTC

Like I said... I was just thinking about saving on the number of pictures used. You'd only need 1 picture rather than 2, it keeps the pack size down. Its not mega important, I just thought that it would be nice.

This Render/Picture II sounds really good anyway, and really fast.(framerate = god)

:)

dirkdeftly

18th October 2002 20:14 UTC

For the blending, I think this would be the fucking shit:

Normal blend: blend options (adjustable slidebar and %)
X On-beat blend: blend options (adjustable slidebar and %)
. X On-beat frames: n
.(X After beat decay: x)

(blend options: ignore, replace, max, min, sub1, sub2, buffer, multiply, pixel w/alternate, line w/alternate, xor, adjustable)

X is a checkbox, and (...) is an option that's only useable when using adjustable blend. On-beat frames keeps the blending option for n frames, and after beat decay (only with adjustable blend on both normal and on-beat) starts decaying the on-beat setting back to the normal setting at rate X. Adjustable % is a textbox to specifically set what percent of the picture is used (instead of just a slidebar). Lastly, the pixel/line w/alternate means that it uses the alternate set of pixels and lines.

The aspect ratio correction NEEDS to be there. Have it just be correct, instead of making it correct on either the x- or y-axis. Also have it correct ******ds OR inwards. (in other words, if the picture is taller but thinner than the window, have it either expand to the width, or shrink to the height.)

Was that too many suggestions? :p

UnConeD

18th October 2002 20:29 UTC

Buffer blend is not possible because APEs can't access the internal AVS buffers. You'll have to use an effect list.

I just implemented minimum blend, because it's just switching around two lines from the maximum code :).

Why would you need a percentage box? I doubt you'll notice the difference between 38 and 39%.

Does anyone *every* use those alternating pixel/line patterns? :) Think of stuff you're going to use, not stuff that just sounds cool :P.

Have it just be correct, instead of making it correct on either the x- or y-axis. Also have it correct ******ds OR inwards.

nixa

19th October 2002 21:52 UTC

Cool we are going to have a new Unconed ape. :)
What is minimum blend and how does it work?

dirkdeftly

19th October 2002 23:49 UTC

Minimum blend blends the two pixels as little as possible.


I meant that instead of correcting on the x-axis OR the y-axis, which can result in either shrinking or zooming the picture, do one or the other in all cases. So if correct inwards is turned on, you would shrink either the x-axis or the y-axis to fit the window, and vice versa for correct ******ds. Do I make sense now?

BTW, I have uses for both a manual percentage text-box and an alternate every other pixel. They're hard to explain, though. And come to think of it...they don't really apply to render / picture. Never mind ;)

UnConeD

20th October 2002 03:18 UTC

Minimum blend simply compares the channels of the two pixels and always takes the lowest value, just like maximum blend takes the highest value from the two.

E.g. blend (128, 0, 200) with (0, 50, 100):

minimum: (0, 0, 100)
maximum: (128, 50, 200)

Tuggummi

21st October 2002 09:45 UTC

Does anyone *every* use those alternating pixel/line patterns? Think of stuff you're going to use, not stuff that just sounds cool :P.

Montana

21st October 2002 11:48 UTC

steven, what does the xor blend actually do

UnConeD

21st October 2002 12:06 UTC

It performs a bit-per-bit binary XOR... just like the regular AVS XOR mode.

Montana

21st October 2002 12:30 UTC

umhh, the thing is that i meant was that i did't understand what the xor blend avs does actually (how does it work)?

jheriko

21st October 2002 14:13 UTC

The binary XOR does an exclusive or on the bits by returning 1 if the bits are different and 0 if they are the same.

eg.


00101101
xor
11011101
---------
11110000

In AVS it just uses the colour for the foreground and background to XOR, the colours are in hex in the form 00RRGGBB where RR,GG,BB are the red, green, blue out of 255 in hex. Since hex digits are equal to 4 bits each you can easily convert this into binary and do the XOR blend. For instance, xor blending a = red=255,green=64 and blue=8 with b = red=64,green=128 and blue=0 you convert this to hex, then binary:

a=00FF4008
b=00408000

(ignoring the front zeroes)

   F    F    4    0    0    8
a=1111 1111 0100 0000 0000 1000

   4    0    8    0    0    0
b=0100 0000 1000 0000 0000 0000

          11=B 15=F 12=C 0=0  0=0  8=8
a xor b = 1011 1111 1100 0000 0000 1000 

UnConeD

21st October 2002 15:35 UTC

The reason AVS uses 32-bit as well is for processor reasons. The Pentium memory bus is 32-bits wide and has to fetch data from 32-bit aligned addresses.

Suppose AVS used 24-bit instead, it would sometimes have to fetch 64-bit to get one whole pixel:

R1 G1 B1 R2 | G2 B2 R3 G3 | B3 R4 G4 B4

In order to get the second pixel, the two first chunks have to be
fetched.

R1 G1 B1 00 | R2 G2 B2 00 | R3 G3 B3 00 | R4 G4 B4 00

So by padding with zeroes, you get an increase in memory size, but a large speed-up as well.

And yes, usually 32-bit color means RGBA (with an alpha/transparency channel) instead of RGB0.

jheriko

21st October 2002 15:42 UTC

[offtopic]

Meh.. the x86 architechture is crap. All of its problems spawn from intels foolish desire to make every single processor fully backwardly compatible, I mean who wants to run software written for the 4004 on a Pentium 4? Thats just insanity.

Personally I think that they should start a new architecture from scratch and make their processors be compatible with both for a few years, then phase x86 out. Or they could slowly introduce the new one... anyway, it shouldn't be too hard a thing to organise and maybe they would learn a lesson, like 'do things properly in the first place'.

[/offtopic]

UnConeD

21st October 2002 18:30 UTC

Isn't that what IA-64 is supposed to be?

jheriko

21st October 2002 18:55 UTC

I'll have to ask about that, most of what I know about the architecture comes from the intel (propaganda filled) manual and pak-9 (who is doing a degree in software engineering). But as far as I am aware the IA-64 is going to retain all backward compatability, its one of the things that intel is most proud of (god knows why) so it will still have all of the flaws of x86.

Apparently one of the biggest flaws is the program counter which uses two registers because it needs 20-bits, so it uses 2 16-bit registers where a single 20-bit or 32-bit register would do fine, and also make everything run much faster.

jheriko

22nd October 2002 18:50 UTC

Heres an email I got from P9 on how flawed x86 is.

yea I don't have time right now to list the shit things about x86 but I assure you there are many. Oh, okay you twisted my arm, here's a couple:

When intel made their processors (8086) they made 16 bit registers, and you could access the top and bottom part of the registers as 8 bit. So the register AX could also be accesed as AL and AH (A low/A high). But when they added all the crap on to pentium processors to make them 32 bit, they just slapped another 16 bits to make the registers bigger (so AX for exaple became EAX). BUT, they didn't make it so that you could access the registers top 16 bits independantly, only the lower. This meant it was backwardly compatible with older software that stil accessed ax,bx etc... But why the hell didn't they make it so that you could access the top 16 bits? it just ripps off a load of capability for no reason.

I think I already told you about the instruction pointer/code segment
register fuck up too.... Rather than make 1 24 bit (I think 24 bit is
enough) register that was the instruction pointer, they made a code
segment register that points to the beggining of the code in memory, then ANOTHER register (the instruction pointer) that points to the point above the code segment register where the next instruction is.WHY intel? WHY? what a big fat waste of a register.

P9

UnConeD

22nd October 2002 18:58 UTC

If you think regular x86 is incomplete, check out MMX. It's as if they took a list of all possible instructions, and then picked only a few implementations.

For example, you can't shift 8 packed bytes, only 4 packed words or 2 packed dwords. Or, comparisons only work on signed integers, not unsigned. So you have to flip the sign bit before and after doing a comparison of unsigned ints.
Division is also missing.

All in all, quite annoying :P.

jheriko

22nd October 2002 19:00 UTC

I thought that they tidied that up with SSE and SSE2. I know that they included a lot of other packed types, like double and single precision floats.

UnConeD

22nd October 2002 23:26 UTC

Yeah but SSE is far less common than MMX. Plus, it seems MSVC++6.0 doesn't understand SSE instructions... so I can't use them at the moment anyway.

goebish

5th November 2002 01:00 UTC

:D nothing yet availlable?:D

UnConeD

5th November 2002 01:59 UTC

Well I do have a working .bmp renderer with bilinear filtering and all the AVS output modes (which is already better than render/picture 1), but I haven't fixed PNG support yet. LibPNG is still crashing sometimes.

However, there is a different problem I didn't see: libpng and zlib (the two required for png support) combine to about 180KB. If I were to add JPG support, it would mean even more size.

Since people would have to distribute the APE along with their packs, it would probably be bigger than just using .bmp's.

I'll see if I can't crunch it down some more by cramming everything into the APE, but it's still a major bummer.

Anyway I decided to put down R/P2 for now and pick up an older project of mine: an open-source compiler for AVS code ;), for use in APEs.

jheriko

5th November 2002 19:00 UTC

I'm pretty sure that you could make the APE do the file loading and stuff. As long as you know the file format or have some source it shouldn't be too difficult. I think that there are a few .jpg tutorials around and definately tons of targa ones.

I'd recommend looking through places like flipcode.

(I'd look for you but I'm so damn lazy :p)

goebish

5th November 2002 20:41 UTC

have a look at: http://www.programmersheaven.com

Tuggummi

6th November 2002 08:17 UTC

Sad to hear that you have problems, since this is the first ape i actually would want to use, it would be very handy in my Bitmapped pack which im planning to do somewhere in the future... Well i think it will probably be ready by the time i start to make that pack :p

But what if i start to make presets with the old picture render and then use the ape when it is done, would it cause any complications etc.?

Yathosho

6th November 2002 18:39 UTC

hmm, nsis uses bzip2 compression and will use even more effective 7zip compression in future. it's still gonna be a big file i guess, but well, that's what it takes sometimes.

Yathosho

3rd March 2003 14:29 UTC

i'm not quite sure, who seriously took a look at the source-code. but who ever is on it, how about support for SVG files?

legohead

4th March 2003 04:29 UTC

.gif support would be highly useful (moreso than .jpg which shouldn't make much difference than a .bmp). That way I can render transparent/masked pics which would be damn nice.

Zevensoft

4th March 2003 04:56 UTC

PNG would be the ultimate.

blaz

18th April 2004 21:35 UTC

thank you UnConeD, you are a good.
this is something that I needed the most.

UnConeD

19th April 2004 02:45 UTC

Don't resurrect ancient threads with meaningless posts.