Curve Angle

some benchmarks, all in microseconds, 100 rings, running average of 100 samples:

574 previous version: no curve angle support
765 curve angle support, but curve angle2 calc commented out
767 curve angle support, but curve angle2 calc skipped by zero test

same test but with 20 sides instead of 5:
1.843 previous version: no curve angle support
2.547 curve angle support, but curve angle2 calc commented out
2.564 curve angle support, but curve angle2 calc skipped by zero test

same test on bad box:
297 previous version: no curve angle support
378 curve angle support, but curve angle2 calc skipped by zero test

Either way best case is curve calc now takes approx. 33% longer. However the good news is the entire point calc is only about 20% of the draw function time *in line mode*.

Whorld Choir

According to my calculations, the plasmagon patch would take almost 6 million years to return to its starting position, and that's not counting the pinwheel global oscillator. Yikes! I guess I can see why there's no such thing as LCM for real numbers but it bothers me somehow.

0.03 33.33333333
0.07 14.28571429
0.08 12.5
0.09 11.11111111
0.003 333.3333333
0.004 250
0.005 200
0.006 166.6666667
 1.83715E+14 seconds
 5825579.068 years

Whorld/GL: only the beginning

It seems that Whorld's drawing code can't be directly ported to OpenGL, because OpenGL doesn't even handle concave polygons, never mind self-overlapping polygons or shapes composed of Bezier curves. The good news is, it might be possible to use a combination of GDI and OpenGL. GDI provides a function called FlattenPath, which turns a path containing Bezier curves into a (very large) set of line segments. This flattened path could then be passed to the glu tessellation functions, which would turn the path into a set of simple polygons that could be rendered directly in OpenGL. It all sounds a bit Rube Goldberg, but it might be worth it to achieve transparency and the many other effects available in OpenGL. The GDI FlattenPath function seems to be very fast, at least compared to the actual rendering done by StrokeAndFillPath.

compensating frame rate

If you change the frame rate, and want your patches to look the same, you must compensate the following variables: Ring Growth, and Color Speed. If you double the frame rate, halve Ring Growth and Color Speed. Yes, the app should take care of this for you, but for the moment it doesn't.

Patches that depend on a particular relationship to the frame rate (e.g. the Seed of Life patch) will require further tweaking.

Note that changing the frame rate will change the relative speed of the cascading delete, and there's currently no way to compensate for it. Sorry!

bezier benchmarks (categorized)

frames = 500
playlist: new curve alg bench.whl
patch: default
Master Offsets:
Star Factor = 1
Even Curve = .2
Odd Curve = .2
draw mode = line (or fill/outline)
NOTE: app should be MAXIMIZED at 1024 x 768

Dell / W2K
draw mode: lines only
back buffer: auto (video memory)
OnTimer = 0.054 (0.29%)
Draw = 18.992 (99.71%)
math = 0.600 (3.15%)
GDI = 18.393 (96.57%)
total = 19.047
secs@frame = 0.38 (26.25 FPS)
2nd pass: similar

Bad Box / XP
draw mode: lines only
back buffer: auto (video memory)
OnTimer = 0.008 (0.16%)
Draw = 4.854 (99.84%)
math = 0.263 (5.41%)
GDI = 4.590 (94.42%)
total = 4.862
secs@frame = 0.010 (102.84 FPS)

Bad Box / XP
draw mode: fill/outline
back buffer: auto (video memory)
OnTimer = 0.008 (0.05%)
Draw = 16.735 (99.95%)
math = 0.270 (1.61%)
GDI = 16.466 (98.34%)
total = 16.744
secs@frame = 0.033 (29.86 FPS)
2nd pass: similar
not too good!

Bad Box / XP
draw mode: fill/outline
back buffer: system memory
OnTimer = 0.016 (0.09%)
Draw = 17.916 (99.91%)
math = 0.276 (1.54%)
GDI = 17.639 (98.37%)
total = 17.931
secs@frame = 0.036 (27.88 FPS)
2nd pass: similar
system memory is not helping

Z Dell / XP
FPS: 25
draw mode: fill/outline
back buffer: auto (video memory)
OnTimer = 0.014 (0.06%)
Draw = 21.519 (99.94%)
math = 0.145 (0.67%)
GDI = 21.374 (99.26%)
total = 21.533
secs@frame = 0.043 (23.22 FPS)
7 FPS *SLOWER* than Bad Box with back buffer in video memory? just terrible

Z Dell / XP
FPS: 25
draw mode: fill/outline
back buffer: system memory
OnTimer = 0.017 (0.12%)
Draw = 14.446 (99.98%)
math = 0.146 (1.01%)
GDI = 14.300 (98.88%)
total = 14.463
secs@frame = 0.029 (34.57 FPS)
brand-new 2.66 GHz Dell is maximum 5 FPS faster than 3-year old Bad Box?
system memory *is* helping in this case, WTF?

benchmarks for improved curve generation

In previous versions, curves were unstable (i.e. they would jitter) when star factor was negative. This occurred because the curve points were being computed from integer vertices. The new version computes the curve points from real vertices. Also, the curves points are now generated at the same time as the vertices, in a single loop, instead of in a second pass. This is more efficient, and eliminates the need for a second point array.

Comparing 1.6.06 and 1.7.03

Only the math portion of Draw is compared.

playlist: new curve alg bench.whl
patch: default
Master Offsets:
Star Factor = 1
Even Curve = .2
Odd Curve = .2

Benchmark includes code between
while (NextPos != NULL) {
and
rp.Delete = !RingVisible;
plus MakeCurves in 1.6.06

1000 frames

pass 1.6.06 1.7.03
---- ------- -------
#1 .001157 .000998
#2 .001161 .000995 (14% faster)

In summary, the Draw math takes less time in 1.7.03, despite having added some major new features (global parameters, curve shear). Presumably the speedup is due to a combination of better-optimized code and reduced memory usage. The global parameters aren't free, but their cost is minimal: 1.7.03 drops to around .000930 if m_GlobRing is removed from Draw.

Total time for Draw in 1.7.03: .025 in line mode, off the chart in fill mode

Same exact tests, but on the bad box:

pass 1.6.06 1.7.03
---- ------- -------
#1 .000654 .000468
#2 .000653 .000468 (28% faster)

Total time for Draw: .009 in line mode, .022 in fill mode

swarm

in AddRing:

int     swcnt;  // number of vertices in swarm polygon
int     swidx;  // index of swarm polygon's current vertex
int     swrad;  // radius of swarm polygon, in pixels

double  theta = (PI * 2) * (double(swidx) / swcnt);     // can be better optimized
Ring.Shift.x += sin(theta) * swrad;
Ring.Shift.y += cos(theta) * swrad;
swidx++;
swidx %= swcnt;         // can be better optimized

NOTE that this feature requires the skew curve fix (see above), otherwise curves will be horribly distorted.

skew curve fix

Skew distorts curved rings; to avoid this, MakeCurves must use the skewed origin.

wrong:
iorg = CPoint(round(org.x), round(org.y));

correct:
iorg = CPoint(round(xshift), round(yshift));