mikm

19th January 2003 01:21 UTC

optimal grid sizes
i don't know if this is possible, but for DMs,I think it would be great to have an 'optimize' setting for DM grid sizes
Basically, the creator enters a target framerate into the box. This would either be within a range (14 fps - 20 fps) or just a minimum framerate (40 fps but can be any faster).
So as not to sacrifice speed, this would be calculated initially. A button would be availible to recalculate if necessary (user changes window size).

or how 'bout something in the Misc section that will make the preset go at a certain framerate by slowing down the preset (basically it would adjust the 'windowed preformance bar'. Again, this would be calculated initially.

anubis2003

19th January 2003 04:00 UTC

The presets already run slow enough why would you want to slow them down any more? Optimized grid sizes would be nice, but it could yield bad results on some computers.

UnConeD

19th January 2003 05:16 UTC

If the grid-size is that unimportant to your preset that you allow it to have any value, then you should just set it to the lowest value that still looks good :p.

Zevensoft

19th January 2003 14:54 UTC

I say a better idea would have AVS building machine code from the formula box, and running through that for each pixel, thus removing the need for a gridsize.

anubis2003

19th January 2003 16:15 UTC

Speaking of this, does AVS generate any machine code, or does it just re-interpret it every time? I'm assuming it does use some machine code or else it would be very slow.

dirkdeftly

20th January 2003 08:23 UTC

if you're talking about superscopes and the like, no, i'm pretty sure avs doesn't. movements do, however, since they're static.

UnConeD

20th January 2003 16:23 UTC

The code is compiled into assembly undoubtably. Interpreting it would be waste of time.

anubis2003

20th January 2003 16:29 UTC

Thanks Unconed. I was pretty sure that is what it did, but wasn't positive.

dirkdeftly

20th January 2003 19:08 UTC

hmm...so why is it that superscope code has to be calculated every frame, but movement is just calculated once, when they're both (assumably) interpreted onload?

anubis2003

20th January 2003 19:26 UTC

Calculation and Interpretation aren't the same thing. I think AVS just makes an assembly equivalent of the typed code onload and then re-calculates the coordinates every frame. Movements(not DM's) do not change from frame to frame so they don't re-calculate every frame.
For example, if the movement is x=x+.01;y=y-.01; then the coordinate (0,0) will always be moved to (.01,-.01) every frame. In a superscope, however, this isn't necessarily the case.

UnConeD

20th January 2003 19:29 UTC

eh?

The script code for both movement and superscopes is compiled into assembly language instructions (i.e. raw machine code) at the beginning. This is the translation from the text you type "pi*sin(a)" into machine code "fld [address of a]; fsin; fld [address of pi]; fmul;" or something like that.

However, the compiled instructions still need to be executed to perform the actual calculation.

Because a trans/movement is static, the expression is evaluated once for every pixel at preset-loading.

For real-time dynamic effects like a DM or Scope, the code is executed once per-point/gridpoint every frame.

What are you getting confused about?

The reason the code of a scope or DM runs so slow despite it being compiled into machine code is undoubtably because the code it generates is not being optimized. Writing a fully optimizing compiler is not only tricky, but also a lot of work.
I guess Justin Frankel never thought his expression evaluator would be used to code raytracers ;).

On top of that, the IA-32 architecture is a mess, because it's been backwards compatible since the XT and has a rediculously low amount of registers for a modern cpu.