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