2. AVS
  3. AVS acting weird since winamp update

Archive: AVS acting weird since winamp update


Raz

27th October 2006 16:01 UTC

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.

PAK-9

28th October 2006 13:36 UTC

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

Warrior of the Light

28th October 2006 14:32 UTC

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

Raz

28th October 2006 18:26 UTC

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.

Nanakiwurkz

28th October 2006 23:35 UTC

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.

Mr_Nudge

29th October 2006 11:54 UTC

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

QOALsoft

29th October 2006 12:52 UTC

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.

Warrior of the Light

30th October 2006 07:07 UTC

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

jheriko

30th October 2006 10:31 UTC

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.

Mr_Nudge

30th October 2006 11:42 UTC

*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*

jheriko

30th October 2006 12:19 UTC

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.

Raz

30th October 2006 17:59 UTC

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.

DrO

31st October 2006 20:18 UTC

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 :confused: )

-daz

Warrior of the Light

31st October 2006 22:56 UTC

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:

Nanakiwurkz

31st October 2006 23:40 UTC

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.

DrO

31st October 2006 23:44 UTC

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

Nanakiwurkz

31st October 2006 23:51 UTC

-_-' 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.

Mr_Nudge

1st November 2006 03:36 UTC

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

jheriko

1st November 2006 09:36 UTC

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!

DrO

1st November 2006 13:26 UTC

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

PAK-9

1st November 2006 18:50 UTC

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.
:igor:

jheriko

1st November 2006 19:05 UTC

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.

DrO

1st November 2006 20:20 UTC

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

DrO

1st November 2006 20:33 UTC

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

DrO

2nd November 2006 20:27 UTC

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

-daz

DrO

6th November 2006 22:56 UTC

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

jheriko

7th November 2006 09:54 UTC

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)

DrO

7th November 2006 11:05 UTC

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

jheriko

8th November 2006 21:45 UTC

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

DrO

8th November 2006 23:40 UTC

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

jheriko

9th November 2006 09:40 UTC

I am still curious why it went wrong. I've compiled avs using .net 2002/2003 before and there weren't any big problems that I can remember... need to try it under 2005 still though. 2005's project conversion is not as good, it fails to convert some of my 2003 projects nicely.. god knows what it might do with a vc6.0 project :P

DrO

9th November 2006 10:37 UTC

from what i've seen any compiles other than a msvc6 one never seem to work quite right for avs (random crashes, etc) so i'm pretty much confused by it all, heh

-daz

jheriko

24th November 2006 20:11 UTC

linesize is broken in the "fixed" version

annoying.

fsk

24th November 2006 20:12 UTC

nevermind

jheriko

24th November 2006 20:28 UTC

my bad

DrO

24th November 2006 21:18 UTC

eh? so is it broken or not?

-daz

Nanakiwurkz

25th November 2006 00:47 UTC

Broken function
i've discovered that gmegabuf is also broken.
i to prove this i used Grand-Childs text renderer superscope preset and found it to not be working. concluesion gmegabufs.
i hope this helps.

QOALsoft

25th November 2006 15:30 UTC

Nanakiwurkz have you read this topic?
http://forums.winamp.com/showthread....hreadid=260046

(Download vis_avs.dll 2.81d from the link on the thread)

Rocker

25th November 2006 16:49 UTC

Thanks DrO

jheriko

27th November 2006 10:07 UTC

NOT broken. It was my mistake.

DrO

27th November 2006 13:25 UTC

rightio. i was starting to worry that i'd made a broken build after all of the issues beforehand with the 2.81c build.

the complete zip of altered files is in this for anyone wanting to build avs on their own upto the 2.81d spec

-daz

TomyLobo

4th January 2007 23:47 UTC

/me downloads one of Jheriko's preset
/me craps all over Jheriko because it's not working
...weeks later...
/me tests one of his old presets
/me notices a slight inconsistency with previous behaviour
/me investigates further
/me notices that linesize is not working
/me checks AVS version
/me curses at the genius who included a new AVS version without mentioning it in the changelog

MaTTFURY

5th January 2007 01:38 UTC

who or what is making this and can we shoot them!!!

heath28m

5th January 2007 01:54 UTC

I have noticed than in 5.32 the avs's are actually more reactive and able to run faster and smoother with less CPU Usage...

I accepted it and went on deleted those which would no long respond, or feel short of full respond...I did have to delete some good ones.. But we had to sacrifice a few things to actually have an improvement possibly..( gets dagger, mask, and cloak..)

In the meantime, you could download The Private Compilation 2006, ( AVS Presets Thread )which will be a folder of 312 avs's that work.. on its way to be published .. may be awhile .. cause of the site having some maintenance things going on.. ( must have hired a new guy with ideas..)LOL

I just now found this thread after trying to solve the ssue and figure out what it was but this .. So now I am going to go have a look-see at this attached file..

TomyLobo

5th January 2007 02:24 UTC

lol
you aren't seriously advocating the use of presets whose non-shittiness depends on bugs that are already fixed?

heath28m

5th January 2007 02:41 UTC

I would say with some political plausible denial.."NO.. and then again most definitely not" but if thats what you make of it then..uhmm..

"GO RIGHT ON AHEAD!"

LMAO

Grandchild

5th January 2007 04:38 UTC

eh, tomy, just to be sure, by now you have downloaded the winamp update pack from the thread linked on the prev. page?

TomyLobo

5th January 2007 05:02 UTC

yes i did
until today i wasnt aware of an avs update (to 2.81c) though, because it was not mentioned anywhere but on the forums (which i dont read regularly anymore)
hence me saying that the bugs are already fixed

Grandchild

5th January 2007 12:17 UTC

i just *hope* that the next WA-update comes soon and that the new AVS is not again forgotten, because the average watcher doesn't know about or downloads the update pack i guess [i wouldn't have known about it, hadn't the thread being linked here]

jheriko

5th January 2007 12:24 UTC

I downloaded the AVS source last night to mess around with it. The source on the download page http://www.nullsoft.com/free/avs/ is not the latest source. There is the zip file on this thread from Dr0 (I didn't see it last night)... but still... it would be nice if it the page was updated

Incidentally I updated it to compile on .net 2005 with no problems... at least that I could find (i.e. not the original problem from this thread). The only changes I had to make were simple, mostly casts to clear up ambiguities, some default parameters removed from function pointers, etc...

I did notice, however, that there are somethings which are quite sensitive to optimisation. e.g. "Whole Program Optimisation" fails, because it puts off generating some things until link, which means that some of the evallib hax don't work. There was something else but I can't remember it now...

Does anyone know if/when the source will be updated?

Grandchild

5th January 2007 13:05 UTC

Originally posted by jheriko ...I did notice, however, that there are somethings which are quite sensitive to optimisation. e.g. "Whole Program Optimisation" fails, because it puts off generating some things until link, which means that some of the evallib hax don't work. There was something else but I can't remember it now...
does that mean there is still space for speed optimization? [because for the things it does, avs is quite fast, imo] or does it just mean there's some awkward programming work in there?

DrO

5th January 2007 13:25 UTC

Originally posted by jheriko
Does anyone know if/when the source will be updated?
ni idea since i don't know who has access to the cvs on that/bundle but i'll try to see what can be done. the main issue with non msvc6 compiles is that things can't be optimised as you've pointed out and also it's not a known reliable compile (hence why sticking to building it at least for the moment in an environment which it was designed/created in)

Grandchild: it won't be forgotten since it's already in the internal builds, it was just how the release was pushed before i got a chance to remind the devs to include it - the joys of uk/us time differences and me unfortunately working late on the day of release :( and i'm sure that it'll be added as a comment in the release notes (was an oversight in the other version when 2.81c appeared - the devs/myself are people at the end of the day and it does happen ;) )

the optimisations jheriko are refering to are build options for speed/size but generally there's little to be noticed even when not running dlls in such a manner without those optimisations from what i've experienced over the years (maybe a few percent if that).

Mattfury: blame me and then blame the nullsoft build machine (since i made a initial build that worked and then was recompiled by nullsoft and then i re-did the build and that's now the one in the pack/next winamp build). still not sure why the nullsoft build failed when that was done with the same project in msvc6 *shrugs*

-daz

jheriko

5th January 2007 16:44 UTC

Originally posted by DrO
the optimisations jheriko are refering to are build options for speed/size but generally there's little to be noticed even when not running dlls in such a manner without those optimisations from what i've experienced over the years (maybe a few percent if that).
-daz
Don't confuse your ability to write awesomely optimised code from the start with a lack of functionality. If you write sufficiently terrible code they can make a very noticeable change. :)

It also depends on the structure of the program. "Whole program optimisation" has a larger impact if your project has hundreds of small seperate files, for instance. Inline expansion only has an effect if you aren't already using inline where appropriate or using classes with inline definitions. etc...

I think I have access to the cvs through sourceforge, I seem to remember accessing it once, but my computer is in shambles atm. It heavily crashes over pretty much anything (AVS, emulated games, screensavers.. they all make it reboot on the spot at random) so it will be a while (i need to get an SATA cable this weekend and reinstall loads of junk) before I bother to check that out..

jheriko

1st April 2009 19:14 UTC

Just a little reminder... this still hasn't been fixed. :(

Fork me on GitHub