Moon buggy fun

Bah I'll explain it again... the globvars hack is really, really, really unuseful. Here's how it works:

- Dot superscope calculates values, and draws them as colored pixels in the upper left corner, first row.
- Globvars hack reads those values and inserts them into the getosc data.
- Other components read those values as getosc.

Limitations:
- Range is 0..1 for input, -1...1 for output, so you have to rescale your range so it fits into that
- Precision is 1/255, not good for large ranges.

Because the typical 'read-in' code is quite large per scope, it's seriously not the way to go when you just need a global rand(). In this case you should use a regular getosc. It's only useful if you really, really need to do some complex calculations on a var that cannot be duplicated.

In its current state it's non-configurable and I'm sure if I released it as "Global Variables Hack" I'd get tons of people asking "I put in teh global var appe in my presetz and then in my scope I put foo=2 and in anoter scope it is not 2???? PLZ HLP!!1!!!".

Too bad... I hoped for something like an APE in which you can define vars that apply to all objects so that you don't have to re-type everyting for every item, so that it speeds things up a bit...

This means I still have to define pi for every object...
Too bad, too bad 🙁

im sure you could make some sort of global variables effect list.

Well, not really an effect list, but an APE that can import other APE's such as ssc's and dm's. You could maybe have specific globes assigned for all APE's within the 'effect list'.

Then again, this may be a pipe dream, my c knowledge isnt sparkly enough to justify the claim.

BTW, can you use the 'b' switch as a globe ucd? or is it predefined as boolean..

all of this would be so easy if we had source. =(
isnt one of us able to make a ssc and dm replica with the neccesary improvs?

The problem is mainly the scripting language. The actual DM/SSC mechanics are not that hard.

I don't have time to implement AVS' scripting language completely (though it is possible), plus I really don't want to reinvent the wheel. It's up to nullsoft to make the scripting engine available to APEs, not the other way around.

Nullsoft will do shit...I have the feeling they dont care about us...We complained in a lot of threads but,no results.Its up to UCD and his free time 🙂

Originally posted by Phaze1987
Nullsoft will do shit...I have the feeling they dont care about us...We complained in a lot of threads but,no results.Its up to UCD and his free time 🙂

Maybe we should start a petition to make AVS open source...

Either that or storm the Nullsoft headquarters and take the code by force 😉

some guy from the NSIS project talked of the possibility that not all code in avs is nullsofts own (but bought code-parts). this could be the main-reason why avs is not open-sourced (while NSIS is, and its from the same company).

i'm wondering what ryan geiss knows. he's mentioned on the team nullsoft site, and he did visualizations before. one must speculate, he knows more than he pretends 😉

I don't know, what parts would be proprietary? We know the scripting engine is Justin's, the dynamic movement stuff is cool and quite unique to AVS/Milkdrop afaik, but it's not really that hard to implement.

Working with pixel operations started waaay back in the demo scene... the only difference is that AVS does it in 32-bit color and makes it modular.

i am learning how to write compilers/interpreters, and am up to the challenge of coding an open source version of the avs if anyone is interested in helping... 🙂

open source would be good but it could be risk due to all of the potential n00b "updates" and "clever add-ons". it is unlikely that the scripting engine is made for avs, probably just a bought or freeware header. But even so, it would not be hard at all to make.. excpet for brackets and stuff, i hate that sort of thing.

Its up to UCD and his free time

well, now we have at least two other ape creators.. or at least they are getting there.. surely we could do a joint effort, maybe use a freeware text>script file, although then the syntax would be different from the original ssc, dm etc.

<edit> scratch all that, why dont we just ask nullsoft nicely for the scripting stuff specifically

we wouldn't have to make a scripting engine that was different though, we could emulate it completely using tools like flex and bison. as far as clever n00b add-ins and the like, if we ran a truly open source project, they would have to be contributed back to the project, and approved to get into the source tree. not everyone gets read/write access to the cvs tree.

u are right that there are more than just one capable programmer in the community, and i would like to consider myself one. however, the fact that i dont boot into windows very often now would probably pose a problem. although... it would be totally awesome to build a cross-platform version that you could have the option of building for either xmms or winamp3 🙂 and that is totally possible... all we would have to do is write the windowing/drawing code using something portable like sdl, and then just make sure that we can get the language parser to work on both, and we're golden 🙂 my offer still stands. if anyone is interested, this is a project that i will probably start in the near future.

well, if someone could emulate the scripting stuff properly we would all be a happier bunch. 🙂
Im not even going to try though, i think i need to master some other stuff before i get into that sort of tripe.

I am happy to start work on it as soon as i finish my current two projects >.< if anyone else is interested, maybe we should start up a sourceforge project 🙂

im down for that.. though im not much use.