Irrelevant

2nd December 2003 16:14 UTC

Suggestions...
I've read the sticky, and I don't think any of these are there...


An option you could set for superscopes (and anything else with access to w & h) to reset when you change the screen size or go to/from fullscreen. As it stands, I find that I sometimes get gaps or distortion if I resize the window if the visualisation has a dot-SSC.

A setting in effectlists to run them only once, when the preset loads (and perhaps also if you resize the window, see above).

The ability to access w & h in a trans/move. (Also recalculating as above.)

A third 'wrap' option so that anything out of range would be black.

Something which can load to / save from any buffer, according to a formula. (I might be able to write this one myself, when it becomes possible to access the built-in script features in an APE.)

An 'int(foo)' function (I know you can use 'foo | 0', but it'd be neater, y'know?)

A way to *seriously* expand the multiline script boxes, perhaps into a seperate, resizable, notepad-esque window.


I think that's all for now.

Jeez, not asking much, am I? :rolleyes:

fsk

2nd December 2003 16:42 UTC

I think all but the first and last one are already in:).

UnConeD

2nd December 2003 18:33 UTC

w/h in trans/movement is sw/sh.

Scopes should be coded to adjust themselves to w/h onframe rather than oninit... it's a coding bug not to do this, has nothing to do with AVS.

Most of your requests are already in the new AVS. APEs can access the evallib, the help dialog, the buffers and the global vars, plus there's support for SMP (chunked) processing.

First-frame only effect lists can be done through a simple piece of code in the new codable effect lists.

dirkdeftly

3rd December 2003 05:12 UTC

actually...an even better idea would be to have a brand new eval box that runs onsizechange or something....

UnConeD

3rd December 2003 06:26 UTC

C'mon, in that case we should add tons of boxes. It's not a problem to reevaluate your width/height dependant variables per frame.
Plus if you really need an onsizechange, you probably know how to code already.

Irrelevant

3rd December 2003 18:00 UTC

I know I can do that, I just figured that that would result in an extra free() and malloc() every frame. Which sounds rather slow.

I suppose if you have codable effect lists you can also use them to load/save from a random buffer somehow.


I suppose these aren't in the wish list because they've already been implemented...

dirkdeftly

4th December 2003 02:53 UTC

Umm, ucd, how is it that we should add "tons of boxes"?

And actually, I just thought of something: an onsizechange variable, so you could do an if(sizechange,[code],0). It'd solve the problem, and no extra box clutter....

UnConeD

4th December 2003 08:41 UTC

tadaa:

sizechange=bnot(band(equal(lw,w),equal(lh,h)));
lw=w;lh=h;

dirkdeftly

4th December 2003 15:44 UTC

*sigh*

way to keep glossing over my point ucd. i appreciate it. am i ever going to get this across to you, or are you going to keep shooting me down for no reason?