AVS 2.8b1! :)

yup, Ateros ideas seem really really nice 🙂, atleast
array[x][y]=blabla;
would be good... its much more readable

i know you won't let me down, justin... /me winks sexily

O_o how far can one go

OK well here is my thinking:

• Making the arrays accessed via a function rather than a new language syntax is a lot easier (I know this ultimately doesnt matter that much to everybody else, but it changes it from a quicky day project to a much larger project that could potentially break a lot of other shit)
• Global variables that have names may be possible, but create a whole host of memory management issues -- i.e. if every preset creates its own global variables, they stay around forever? Garbage collection? See below.
• Arrays are a lot easier to keep local (not global) for the above reason.
• Otherwise, we'd have to do some sophisticated garbage collection-type things. Which takes time to implement, and lots of testing before we could really be serious about putting this in the main distribution.

So yes, we could go completely overhaul shit. But ultimately that'll just mean that it'll take tons of time and break shit and be a big pain in the ass. :/ I don't know what the best thing to do is...

-J

That all is true, it would waste a lot of time, but you got work to do with winamp 5, not some stupid 'plugin', uh?
thats why would open source avs be good idea, but yea... things will probably get messy like that

:\

do the arrays way you like them to do, we just gave you ideas 🙂

i can imagine nemo would be happier, if his presets in the Winamp 5 Newpicks had a different name

splendora.avs > NemoOrange - Splendora.avs ?

It would be great to have arrays. From what I've heard around here, you can do really great things with 'em. Would anybody be so kind to explain shortly and simple what they do? My math aint that good 😉.

arrays != math
arrays == programming

supersimple example: peaks

init:
n=576;
val=arrayalloc(n)//I hope new arrays have value 0 set for all items

frame:
t=0//or t=1?

point:
arraysetitem(val,t,max(arraygetitem(val,t)*.99,getspec(i,0,0));
x=i*2-1;
y=1-arraygetitem(val,t);
t=t+1

what does arrayfree do?

Justin:

I'm not sure how the evallib handles assignment and variable-address retrieval, but maybe if you could code it like this:

arraygetitem(array, 5) = foo;
bar = arraygetitem(array, 5);

Then you could put a pre-processor step in to convert from array[5] into that. That would rock 😉.

arrays will be fantastic. I dont know how many times ive stopped half way through some idea because i needed arrays.

BUT!

i fear that these betas and pre's are getting buggier and buggier with every release. I really hope that you will have time to iron everything out before the release of wa5.

I want arrays just as much as the next person, but i think its more important to have a generally stable avs. Im not griping.. i just hope you have time to fix everything... there have been sooooo many updates and so little time for beta-testing.

Originally posted by justin
Making the arrays accessed via a function rather than a new language syntax is a lot easier (I know this ultimately doesnt matter that much to everybody else, but it changes it from a quicky day project to a much larger project that could potentially break a lot of other shit)

That's why I don't know if array's should be worried about now. I think eventually it would be best to wait until it is a bit easier to do the full version and when there is a bit more time to do it. I don't ever really like languages that take the function approach to arrays and such. It is much more of a hassle to first have to use the functions, and then when you find time and switch it over - the old functions will still have to be included in new versions.

Just my opinion.

no, arrays are a very good idea, and would be extremely usefull. They would certainly allow us to do many things that we have been otherwise putting off. Such as propper tentacle effects, and speeding up older presets by making more complicated things into single scopes.

I dont think they would scare off the new comers, as they dont need to know about them if they dont understand it.

But still, i think its vital that the released version of 2.8 is just as stable as 2.6 is.

I'd say no arrays for now. They'd only be really useful with proper looping control structures (though you could always use a skip=1 superscope as a for loop 😉 ).

yeah, With no looping it is a real pain and will deminish the usefulness of arrays.

grrr... thats no good 🙁

👎
I have a ton of things I could use arrays for, and I'm sure that most of the other advanced programmers here do to. It's not something I'd want to stall the release of WA5 over, but I would *REALLY* like to see some proper array management.
I'll be blunt - that arrayalloc() shit sucks major ass. Like I said before, if that gets implemented, people will start using that and then there'll be no way to change it. I know it'd be a lot of major work, and I appreciate that - you're only human (well, to us you're an uberhuman) - but I think trying to use a bad form of array management would be a really bad idea.
As for garbage collection, why not create an internal list of every $global created, and then when a preset is turned off, delete all $globals in that list? Or, when the preset is turned off, look through all the variables and delete all the ones that start with $ (or whatever other marking they'll get)?
Another thing I'd still like to see is a user-expandable varlib. I don't know if this is possible, and if it's not I'd like to see it expanded again, especially if we're gonna be using arrays. (I'm going to assume for now that array[5][5] will take up 25 variable slots, correct me if I'm wrong).


justin is k1ng!!1

I think making one global array, like global variables, will be _realy_ good.
Global variables are almost ok, they'll be perfect if they could be accessed like this:

reg( variable ) = value;  // set value

and blahblah = reg( variable );  // read value

Or, if you'd like to continue using function only on the right side of equation, use this for setting value:

value = reg( variable );  // almost same thing

It's like eval("reg"+number+"=blahblah"); stuff in other languages 😉
And to access arrays with standard syntax ( array[ level1 ][ level2 ] ) will be hard (impossabile?) to program in just a few days, I understand.
I thing one 1-dimentional array will be enough for the first time.

P.S. maybe you don't want to do major stuff with AVS because it's free and doesn't do any good for you - maybe you should make a donation stuff, I'll give you 50$ or more if you do 🙂

Fragmer : Numbers work just fine.
For the second part... don't be lazy.
1-D array... It *can* be made into a 2D with a little improvisation I guess.

I searched, but didn't see this mentioned before:
When you take the sign of a global variable, it is always 1 or -1, never 0.

Originally posted by UnConeD
I'd say no arrays for now. They'd only be really useful with proper looping control structures (though you could always use a skip=1 superscope as a for loop 😉 ).

My fear of adding loop capability would be what if a preset does an infinite loop? 🙂

-J

make limit for times running a loop, or something like that

or only implement finite loops (for..next)

Now that someone mentioned it. I think loops might be much more useful than arrays. As for the infinite loop problem you have two choices, you could trust people not to send presets into an infinite loop. Or do what gaekwad2 said. I think the first would be better.

Maybe a harder but overall better solution would be to put in some kind of feature that allows presets made by other people to use loops. But doesn't allow n00bs to use loops unless a checkbox in the display options is checked. That way n00bs who don't need loops simply can't use them unless the checkbox is on. Which would prevent idiots from accidentally sending there presets into infinite loops.

Justin, would it be possible to make render/text display more than one line of text?

In Macromedia Flash, if a loop goes for too long (I think about 10 seconds) a popup comes up asking if you would like to abort the script. This happens every ten seconds if you select not to abort but the script is still looping. Perhaps this can be implemented in AVS.

OK I'll think about loops and arrays, and we'll do it later (post wa5.0).
Here is avs 2.8b2, which mainly just fixes the sscope skip bug in b1.



Ideally this will be the ver in wa5.0 that launches, well, any day now...

-Justin

I think arrays will be more useful than loops. I mean, loops are great, but priority of arrays is above loops.
Arrays will enable particle engines, complex random-scopes, complex flows etc. What major improvements can loops make? And - preset is recompiled at any change, every time you check a checkbox or type a symbol. Imagine that you're typing code and you didn't finish it and it's already compiled - and does infinite loop. Imagine how much harder it is to build loops (with standart syntax I mean) than arrays? I'm voting for arrays first!

I'd say they are the same priority. A lot of things that you would want to do with arrays can't be done til loops are implemented.

I have a feeling they will both be added at the same time to AVS.

yuh, arrays are nuffin without loops...

but thing i vote for is less buggier avs, this is above everything 😛

arrrays aren't nothing without loops - they are just a bit less. You can still use arrays to draw a cube or something much easier - just use array[curr_pixel] to get the predefined vertice for the 3D figure.

For example: square
INIT:
n=6;vertices[6][2]={{-1,-1},{-1,1},{1,1},{1,-1}};
FRAME:
q=0;
PIXEL:
x=vertices[q][0];y=vertices[q][1];
q=q+1;

Then it would be really cool if matrix/array math was added. 3D rotation and just about everything would be a bit easier, although possibly not faster.

IMO, it's more important to get avs stable and to do some "small" improvementsto avs right now like multiline text and maybe some others to have a proper release ready for WA5.

There's been so much progress that it might take me a few months to work all the stuff out i could do with those new features.

I agree that arrays, looping and a better assignment structure are valueable but for now they're not nessecary.

People have been messing around with avs for about 2 years without any changes, tweaking it to the max of its possibillities.

Now, there's a flood of new stuff and peopel keep on asking for more although it's been barely used yet.

Let's leave this stuff for coming up releases. 🙂