Texer II alpha

[[Ishan]]

way cool UCD! thanx.

[gaekwad2]

Another bug:
Resizing cuts off border pixels.
Try the attached BMPs

[UnConeD]

Actually that's not a 'bug' per se, it's 'by design'.

The texels on the edge of the texture-image are placed on the border of the rectangle of the particle. So 'the area of influence' of those texels is smaller. If I didn't do this, then the texels on the edge would have to blend with non-existant ones outside the image, which would require me to check the bounds of every single pixel (slow) or add a border around the image which duplicates the outer texels.

If you want to show your border texels, you need to manually add a border around your image. I chose this approach because it's the most flexible one. For example in additive mode, you'll want a black border around your image. With replace mode you'll want a 'duplicate pixels' border. With subtractive 2, you'll want a white border. Etc.

Bilinear filtering is messy on the inside because of this.

I did just change the code around a bit to be extra greedy with texels (causes a difference of half a texel or so), so as much border area as possible is covered, so perhaps it's better now. But if you want your border texels to be blended to the outside of the particle as well, you need to manually add a border.

[gaekwad2]

OK, thanks for the explanation!
Maybe you should write something about this in Help to prevent similar complaints in the future.

[shreyas_potnis]

here you go: a simple shockwva example

[UnConeD]

By the way, I've been experimenting with the 'large images crash Texer 2' and the results are weird.

Sometimes it works perfectly (I tried with both an 800x600 and a 4096x4096 picture) and sometimes it crashes in DDRAW.DLL (DirectDraw). The problem is that the error is caught by some internal handler (either Winamp or DDraw's) so I can't debug it easily.

In any case, my code was written to go up to 32767x32767 pictures without problems. Above that, integer overflow occurs (I use signed 16.16 fixed point for the bilinear filtering).

I'll try and see what's causing it, but to be honest I have no idea. The only thing I can think of is that a large image causes a certain process to take longer than it should, and a crash occurs during a normally instantaneous process.
I put my image loader inside a so called 'critical section' that is exclusive with the rendering code, so that no race conditions can happen.

Also, the particles will get clipped to the AVS window, so a huge image shouldn't offer any more problems than one as a big as the window.

[horse-fly]

interesting.... i will create a preset using a 32767*32767 bitmap, and we'll see how long it takes to download.. hahahahah bwah haha

[UnConeD]

Heh well I didn't write it on purpose *just* so you could go up to that size, it's more a side effect of using fixed-point math.

[horse-fly]

but still think of the size of the file...

over a billion bmp pixels... it would be enornmus

[Tuggummi]

Any date set for the final version?´
Oh and btw. have you planned what will happen to Texer 1 ? Is it still okay to use it? i think there could be some effects that can't be done with texer II... Take Example the worm-o-rama arcade mix

[Magic.X]

@Horsefly: If all pixels are of the same color, they should be easily zipped down to floppy size

@UCD: Ff everything fails just make sure that large pictures won't be loaded or even better, are excluded from the load-image combobox. Maybe add a checkbox "use images above xxx*xxx too" so we could still use em on our own risk. This is the best solution imho as long as the error cannot be traced back.

[UnConeD]

The problem is that I have no idea what the limit is, and I think it's even CPU dependant.

[Magic.X]

If i'ts caused by a thread-delay, noone can tell. You'd have to limit it to a reasonable size (eg 100*100) which should work on most pc's (we'd have to test it on some really od and crappy machines).

But how comes that this bug does only exist since texer2? The old version should work the same way.

[shreyas_potnis]

My PC is perfectly suited for the test

[Magic.X]

Go ahead please

[UnConeD]

Magic: I have no idea, which is why it's so darn hard to debug. The fact that it crashes in DDRAW.DLL makes it even weirder, because Texer2 gets nowhere near DirectX.
On top of that, if it were a problem with not having the image loaded properly, it would crash in TEXER2.APE. The code only reads from the image data, so heap/stack corruption is out of the question.
For now, I'm going to leave it like this.
What is an 800x600 BMP doing in your AVS dir anyway?

[[Ishan]]

hehe something i just made up.

[UnConeD]

Sorry atero, I can't help it. AAAAAAAAAAAAAAAAAAGH.

y=y1/(2+z1)*w/h;

Fix the aspect ratio please. It makes all those 3D scopes horribly squished. Like shreyas' avatar.


Nice preset though, reminds me of Tripex. Speaking of which, it had a couple of really nice particle scenes that should be easy to recreate in Texer II.

[sidd]

ahh. very true.. i must have another good look at tripex now.

im starting to see many nice presets from here and ff using t2. The resizablenessness is yet another breakthough. 'Tis a great time to be an avser.

[Deamon]

as it was always, sidd . Though yes, some tripex stuff comes in view again now indeedy. Still, some of it is normal scopable as well. Though you would need a killer-computer for that.

[gaekwad2]

A wise man once said:

originally posted by killahbite
very original to do something that already exists.. using inferior technics like avs

[jheriko]

Nice. I see point sprite models in the future.

[[Ishan]]

ooohhh! there's so much fun with T2.

[horse-fly]

any idea when the final is coming out?

[UnConeD]

When justin adds the help API.

In the meantime I've sped up the Texer 2 a bit, and added a Wrap-around function, which wraps particles around the border of the screen (handy for tilable patterns).

Haven't uploaded it yet though, but it's such a minor update that it really doesn't matter much.

[Deamon]

so you're not going to let them put it standard with avs?

[MrGabberPants]

Noooooooooooooooooooooooooooo, It maded my winamp crash, ne1 know y???

Help me pleeeeeeeez, I wana play wif it too.

[horse-fly]

texer 2 is in alpha stages... you use the program at your own risk

[[Ishan]]

Mrgrabber.....are you drunk??

[sidd]

small bugsy

If you choose one of the examples, and then change the texer image, and then change to another example, the image goes back to the default image.

This is fine, but the image listbox doesnt update. It still says whichever one you selected before, even though the default one is being used.

Also, i got a crash once when i mouse scrolled very quickely thought the list of texer images. But it hasnt happened since.

[Deamon]

I haven't had any crashes, though the first mentioned 'problem' occurs over here as well.

[Pixelcraft]

Hmm, yes, very nice

[UnConeD]

Fixed that XOR bug and the imagelist bug. Latest at:

http://acko.net/dump/texer2.zip

Help won't work on currently available AVS pre's, you need the (unreleased) pre9 for this.

[sidd]

did you say pre9????

[Nic01]

Yes, he did say pre9, now wake up
Don't bother with the amazement, let's just say for now that pre9 allows kinda individual help files.

As for pre10, that'd be v1.0, that'd be 3 days from now, 20/11/03.

[UnConeD]

Basically the help button opens up the same help dialog as the help button in the standard AVS components (superscope/dm/...) with a Texer 2 specific tab along side the others. In case you didn't know, this is one of the new things in AVS 2.7.

Justin simply didn't implement any way for APEs to use this dialog until pre9.

Here's the text in the texer 2 tab:

Texer II is a rendering component that draws what is commonly known as particles.
At specified positions on screen, a copy of the source image is placed and blended in various ways.


The usage is similar to that of a dot-superscope.
The following variables are available:

* n: Contains the amount of particles to draw. Usually set in the init code or the frame code.

* w,h: Contain the width and height of the window in pixels.

* i: Contains the percentage of progress of particles drawn. Varies from 0 (first particle) to 1 (last particle).

* x,y: Specify the position of the center of the particle. Range -1 to 1.

* v: Contains the i'th sample of the oscilloscope waveform. Use getspec(...) or getosc(...) for other data (check the function reference for their usage).

* b: Contains 1 if a beat is occuring, 0 otherwise.

* sizex, sizey: Contain the relative horizontal and vertical size of the current particle. Use 1.0 for original size. Only works if resizing is on.

* red, green, blue: Set the color of the current particle in terms of its red, green and blue component. Only works if color filtering is on.

* skip: Default is 0. If set to 1, indicates that the current particle should not be drawn.



The options available are:

* Color filtering: blends the image multiplicatively with the color specified by the red, green and blue variables.

* Resizing: resizes the image according to the variables sizex and sizey.

* Wrap around: wraps any image data that falls off the border of the screen around to the other side. Useful for making tiled patterns.



Texer II supports the standard AVS blend modes. Just place a Misc / Set Render Mode before the Texer 2 and choose the appropriate setting. You will most likely use Additive or Maximum blend.

Texer II was written by Steven Wittens. Thanks to everyone at the Winamp.com forums for feedback, especially Deamon and gaekwad2 for providing the examples and Tuggummi for providing the default image.

[horse-fly]

Originally posted by UnConeD
Fixed that XOR bug and the imagelist bug.

would this be the "no green in XOR mode" bug?

[Magic.X]

@UCD

I recently installed the new DX9b and all of a sudden i could use large images! Crashes still happen now and then but basically it works now even with those f**king huge bitmaps.

As you pointed out before, tex2 does'nt use DX, but check this yourselfes. Maybe you should add the advice to upgrade DX to your help.

[QuadHeliX]

Are PNG's supported in winamp 5 AVS UCD?

[UnConeD]

no.