JPGs would be mostly useless because it deals with small pictures usually. I won't implement GIF support for various reasons, though I might consider PNG/MNG if I can get that to work.
Texer II alpha
89 posts
this is pure leetness 🙂 Thank you UCD !
Will the final version be integrated with the 'gear' that comes standard with AVS? D'you think you can get Justin to that?
The question is, do I want to give away the code I worked a LOT of time on to a company owned by AOL?
it comes down to that..
i would keep it..
plus it would just be a headfuck if you suddenly need to update it.
i would keep it..
plus it would just be a headfuck if you suddenly need to update it.
Bug detected:
Loading huge pictures will cause Winamp to crash. I currently use the Wa2.91 with avs2.7pre8.
This is not really a problem because why the hell would someone like to texer a 800*600 image? But sometimes i accidently picked one and its fucking annoying to loose your code...
I guess that texerII is not able to buffer such big images.
Either please preread the size and pop up a message if it is above a certain size saying that it cannot be loaded or fix it so it will work with any size.
thnx
Loading huge pictures will cause Winamp to crash. I currently use the Wa2.91 with avs2.7pre8.
This is not really a problem because why the hell would someone like to texer a 800*600 image? But sometimes i accidently picked one and its fucking annoying to loose your code...
I guess that texerII is not able to buffer such big images.
Either please preread the size and pop up a message if it is above a certain size saying that it cannot be loaded or fix it so it will work with any size.
thnx
I gues your anvser is no🙁
@fsk: why would you like to draw lines?
This ape is just for point drawing purposes, those points will get replaced with a picture of your choice and resized by code.
Try to create a line ssc and then add a trans/texer(I) to the scope this is what it would look like what you're requesting...
This ape is just for point drawing purposes, those points will get replaced with a picture of your choice and resized by code.
Try to create a line ssc and then add a trans/texer(I) to the scope this is what it would look like what you're requesting...
I asked for a seperate ssc2 ape and i asked because i think Steven would write a line comand faster than I can spell my nick and because the curent ssc sucks and I have a feeling Justin aint gonna fix it.
Oh, i didn't got that. 😉
So your request goes here i think 😁
So your request goes here i think 😁
way cool UCD! thanx.
Another bug:
Resizing cuts off border pixels.
Try the attached BMPs
Resizing cuts off border pixels.
Try the attached BMPs
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.
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.
OK, thanks for the explanation!
Maybe you should write something about this in Help to prevent similar complaints in the future.
Maybe you should write something about this in Help to prevent similar complaints in the future.
here you go: a simple shockwva example
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.
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.
interesting.... i will create a preset using a 32767*32767 bitmap, and we'll see how long it takes to download.. hahahahah bwah haha
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.
but still think of the size of the file...
over a billion bmp pixels... it would be enornmus
over a billion bmp pixels... it would be enornmus
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 🙂
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 🙂
@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.
@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.
The problem is that I have no idea what the limit is, and I think it's even CPU dependant.
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.
But how comes that this bug does only exist since texer2? The old version should work the same way.
My PC is perfectly suited for the test 😁
Go ahead please 😁
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? 🤪
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? 🤪
hehe something i just made up.
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.
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.
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.
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.
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.