AVS acting weird since winamp update

First of all, i have my avs folder backed up. I was on 5.24 which no longer works at all on my pc. Did a clean install of 5.31, then a clean reinstall of 5.24 again when the weirdness became apparent (still refused to work at all). Then another clean install of 5.31.

Now the weirdness. The 'alphaout' expression in effect lists seems to only work as 'alphaou' now. And half of PAK-9 AVS 5 is fucked up for reasons that are beyond me. It seems to only affect the newer more complicated features so that particular pack is the most obviously affected that i have. Example, the beanies don't move, AVS Blox just sits there with a piece at the top not doing shit, no rotation on nebulous.

A hearty WTF over here.

sounds like gettime isn't working, I've had problems with it before.

Raz, does 5.31 work with the vis_avs.dll from older verions?

Yes it does, and that fixed everything. With the dll from 5.24 everything is normal, with the dll from 5.31, it's all broke. That draws me to the conclusion that vis_avs.dll has been fucked with.

goodpoint, i tryed use a ape i just compiled for avs and it tells me there was a invalid exception and winamp must restart then it freezes and i must force close winamp. I smell a major bug. security issues might arise from this.

would it be a good idea to keep a backup of the current, working vis_avs.dll for future installs?

The version of vis_avs.dll the comes with 5.31 is a new build, version 2.8.1.3, built on 08 October 2006.
But the version the comes with 5.3 is the same old (and loved/hated) version (2.7.9.2) from 19 September 2005.

we could also see this as a good point.. at least someone on Nullsoft's side is still interested in AVS.

I had a similar problem when installing 5.31. It seemed to break the gettime() function in evallib. Reverting to previous vis_avs.dll version fixed it

And I'd rather not have some nub tinkering with avs.

*makes a copy of vis_avs.dll*

*installs 5.3*

*realises gettime doesn't work as pak-9 predicted*

*overwrites with backed up dll*

*avs works again and mrnudge is a happy boy*

I wonder how avs was broken and if the brokenness is in the publicly available source? I will have to check it out when I get home. I dread to think some mindless nub has broken it whilst tinkering.

And that it's now in the latest version, so anyone using it who doesn't have the time to go fucking around with dlls from previous versions can't see a big pile of presets.

Originally posted by jheriko
I dread to think some mindless nub has broken it whilst tinkering.

well you can blame me then for giving benski modded code to fix avs from not storing vis_avs.dat in the folder to follow the multi-user settings. afaik that is all that was changed, i made sure when doing my modifications that i didn't change anything else so it could be related to a compile option on the nullsoft build machines.

can you provide me one or two definite presets to try it out with and i'll happily look into seeing if i can fix whatever i messed up (how changing a getmodulefilename to a sendmessage has broken something else beats me 😕 )

-daz

I haven't tested the new version, so I can't tell if the gettime() function is the only thing that's broken.

Here's the most basic way to test the gettime function:

• The SuperScope fills reg00 with the time in seconds since you booted your system.
• The Text displays the content of reg00.

If avs is OOP then maybe one of the Objects must have failed in the linking process or compiliation but compiler did not find it. try debugging the dll and see what comes up.
even the example ape in the sdk tut failed to load and i got it to compile heck it even crashed winamp.

i'm sure benski wouldn't have put in a compile that failed to compile fully (knowing what he's like). is too late now for me to start messing around with things but will see what i come up with over the next few days

-daz

-_-' speaking of which how long till this is fixed? i have alot of work on avs that i would hate to lose because of an error. i do have another bug for you. in the errored up version of avs i use. every now and then the program crashes when ever i insert a preset using the + preset menu. any idea why. never did it before.

winamp crashed really often in earlier versions when adding render/trans elements with the + menu.. looks like it's taken a backwards step

Originally posted by DrO
well you can blame me then for giving benski modded code to fix avs from not storing vis_avs.dat in the folder to follow the multi-user settings...

Strange. This sounds totally unrelated. If I had to guess at the cause it would be that someone typoed in the evallib routine for gettime(). Here is a test preset:

render/superscope

init: n = 1;

point:
x = sin(gettime(0)+i);
y = 2*i-1;

Should be a slowly oscillating sine wave. With the bug it goes either very fast or random.

If this new source is public I will check it out when I get home. No compiler at work that supports the myriad of ms specific features that avs leverages. 🙁


EDIT: Nanakiwurkz: if you understood what OO, compiling or linking meant you wouldn't have made your suggestion. A 'missing object' means no code gets generated, i.e. no vis_avs.dll to be distributed with Winamp so that we can notice this bug. i.e. your statement is logically false as a consequence of the very fact that you wrote it!

well i've just tried both 2.81b and 2.81c with Warrior of the Light's example and it displays an incrementing number (which is probably the number of seconds since the system started - can't check the api in use but that's my best guess)

so from things, i'm guessing that incrementing number is not to be seen with the 2.81c build?

-daz

Originally posted by Nanakiwurkz
If avs is OOP then maybe one of the Objects must have failed in the linking process or compiliation but compiler did not find it. try debugging the dll and see what comes up.
even the example ape in the sdk tut failed to load and i got it to compile heck it even crashed winamp.

🧟

Just reinstalled the new avs dll. Strangely the gettime api appears to work when testing with text output and superscopes, but the old presets using it do not.

Must investigate more...

If you want to see a preset broken by it try loading my Starfighter Redux preset in winamp forums compilation 2, also in PAK-9 AVS 5 the CWT presets, Shooting Stars, Droplets, AVS Blox and Beanies seem to not work either... I have similar problems in all of my unreleased J10 presets too.

testing on my own machine and not one at work makes things soo much easier. i've had a look at things and i'm not sure why but the build i've just run seems to work the same as 2.81b does (but with my multi-user fixes).

working with the Starfighter Redux preset, with official 2.81c the flashing blob (best i can describe it just isn't there/visible) whereas with my test build and the 2.81b compile it shows clearly in the middle of the avs frame (now i'm hoping that's the correct result i should be seeing). i'm just going to do a fresh clean compile and will upload it in a bit (since i was dabbling with some fullscreen/multimonitor handling but never get things working correctly mainly since i've never directly done anything like it before)

-daz

http://www.nunzioweb.com/daz/temp/avs/vis_avs.zip is a clean compile of the 2.81b code with the changed files from here (well apart from the change in main.cpp to bump the version). so from what i can see it really does look like something went wrong with the nullsoft final build (at least when i compare builds on my dev box)

-daz

/me trundles in, sees no one's replied and walks off

-daz

so is the test build working or not because with the complaints about the 2.81c build being broken we'd like some confirmation on if the alternative build is working correctly so we can look into the issue on the build system as needed or am i just wasting my time trying to help... (since i'd also looked at a few of the minor wishlist things and seen a few i could do just menu/config tweaks but i get the feeling i'd be wasting my time from the current response)

-daz

sorry. i forgot about this thread! i will test your build when i get home.

edit: if i were you i would debug it using msvs, put a break point in the evallib gettime function and see if it catches the problem. since evallib uses those 'cut and paste' blocks of code you might have to make the evallib function call a copy of the original function so that you can step into the code there... i will try this myself later (provided the source code online is the latest ver)

from the tests i did when checking out before the final run on that build everything was matching up from what i could tell against the 2.81b version (and the relevant functions were all outputting correctly from what i could see).

i'm still not too sure why the nullsoft final build failed unless something wasn't configured correctly on their msvc6 setup (entirely possible since they dropped that as the main ide environment some time back)

-daz

works fine here. must have been a compiler problem or something

thanks for the confirmation on that and looks like J.Melo has confirmed it as fixed as well. now i know what is meant to be happening with those cases i'll see what can be done for the next winamp distro (if need be can always do a 'd' build based on my compile or something)

-daz