Whorld

Curve Angle

2009-08-15T14:20:00.000-07:00

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

2009-07-14T14:18:00.000-07:00

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

2008-04-05T22:28:00.001-07:00

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

2008-02-06T22:16:00.000-08:00

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)

2008-01-26T22:15:00.000-08:00

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

2008-01-25T22:12:00.000-08:00

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

2006-06-19T00:54:00.000-07:00

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

2006-06-19T00:53:00.000-07:00

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));

maximize list control within playlist dialog

2006-06-05T00:53:00.000-07:00


void CPlaylistDlg::OnHideControls() 
{
        m_HideControls ^= 1;
        CWnd    *wp = GetWindow(GW_CHILD);
        while (wp != NULL) {
                if (wp != &m_List)
                        wp->ShowWindow(m_HideControls ? SW_HIDE : SW_SHOW);
                wp = wp->GetNextWindow();
        }
        PostMessage(WM_SIZE);
}

void CPlaylistDlg::OnSize(UINT nType, int cx, int cy) 
{
        CToolDlg::OnSize(nType, cx, cy);
        if (m_HideControls) {
                CRect   r;
                GetClientRect(r);
                m_List.MoveWindow(r);
        } else
                m_Resize.OnSize();
}

void CPlaylistDlg::OnShowWindow(BOOL bShow, UINT nStatus) 
{
        CToolDlg::OnShowWindow(bShow, nStatus);
        if (bShow && !m_HideControls)
                m_Resize.OnSize();
}

MIDI support for video functions

2006-06-02T00:52:00.000-07:00

Assuming MIDI ranges equal 5 (the default):


Video Select

num     MIDI    Video
pad     Values  Clip
0       0..12   0
1       13..25  1
2       26..38  2
3       39..51  3
4       52..63  4
5       64..76  5
6       77..89  6
7       90..101 7
8       102..114        8
9       115..126        9
.       127     None

Note that a value of 127 disables video. If this is undesirable, set Video Select's MIDI range to 4.99 instead of 5.


Video Blending 

num     MIDI    
pad     Values  Blending        description     ROP code        GDI name
0       0..12   ~Src & Dst      AND inverted source with destination    DSna    
1       13..25  ~Src | Dst      OR inverted source with destination     DSno    MERGEPAINT
2       26..38  Src & ~Dst      AND source with inverted destination    SDna    SRCERASE
3       39..51  Src & ~Dst      OR source with inverted destination     SDno            
4       52..63  Src & Dst       AND source with destination     DSa     SRCAND
5       64..76  Src | Dst       OR source with destination      DSo     SRCPAINT
6       77..89  Src ^ Dst       XOR source with destination     DSx     SRCINVERT
7       90..101 ~(Src & Dst)    AND source with destination, invert result      DSan            
8       102..114        ~(Src | Dst)    OR source with destination, invert result       DSon    NOTSRCERASE
9       115..127        ~(Src ^ Dst)    XOR source with destination, invert result      DSxn            

Video Cycle Length

num     MIDI    Cycle
pad     Values  Length
1       0..12   1
2       13..25  2
3       26..38  3
4       39..51  4
5       52..63  5
6       64..76  6
7       77..89  7
8       90..101 8
9       102..114        9
0       115..127        10

Note that numpad zero sets the cycle length to "all" which is effectively 10.

pre-fetching video

2006-05-16T00:49:00.000-07:00


bool CPlaylistDlg::PreFetchVideo()
{
    CAviToBmp   vid;
    for (int i = 0; i < BANKS; i++) {
        int count = m_Bank[i].GetSize();
        for (int j = 0; j < count; j++) {
            LPCSTR  Path = m_Bank[i][j].m_Path;
            if (IsVideo(Path)) {
                if (!vid.Open(Path))
                    return(FALSE);
            }
        }
    }
    return(TRUE);
}

This takes approx. 10 seconds for all 340 clips. We can't pre-open the clips because AVIStreamGetFrameOpen won't open more than 75 AVI files simultaneously (it fails with no error message). Not sure why just opening and closing the clips helps. Something to do with disk caching? Not sure how *much* it helps either.

The 10 second delay can be avoided by doing the pre-fetch in a background thread. Note the CoInitialize! AviFileOpen fails without it. This gives me a bad feeling that VfW isn't thread-safe...


UINT CPlaylistDlg::PreFetchVideoThread(LPVOID pParam)
{
    CoInitialize(0);
    CPlaylistDlg    *pd = (CPlaylistDlg *)pParam;
    if (!pd->PreFetchVideo())
        AfxMessageBox("Can't pre-fetch video");
    CoUninitialize();
    return(0);
}

in CPlaylistDlg::Cache:
AfxBeginThread(PreFetchVideoThread, this, 
    THREAD_PRIORITY_BELOW_NORMAL, 0, 0, 0);

The 75 clip limit is apparently NOT due to XVID, it occurs with Cinepack too.

Test to determine how much of Open delay is due to AVIStreamGetFrameOpen. Result for 100 Opens:


        total   avg     min     max
Open    4.915   .049    .007    .087
GetFr.  0.790   .008    .007    .009

A second run gave very similar results:


Open    3.119   .031    .007    .087
GetFr.  0.741   .007    .007    .009

Result: AVIStreamGetFrameOpen is less than 15% of the average, but more importantly, it has a static cost of ~8 milliseconds. This makes a reasonable case for trying the partial pre-open strategy (pre-open all clips but without doing AVIStreamGetFrameOpen, and then do AVIStreamGetFrameOpen when the clip is selected).

exporting a looped movie

2006-05-10T00:48:00.001-07:00

Tried exporting a bidirectional movie (plays forward and then plays in reverse). It's smoother than just letting the video jump back to the beginning but there's still a visible transition when the rings change direction.


int PassFrames = m_RangeLast - m_RangeFirst + 1;
int TotalFrames = (PassFrames - 1) * 2;
pd.Create();
int j = m_RangeLast;
pd.SetRange(0, TotalFrames);
for (int i = 0; i < TotalFrames; i++) {
    if (i >= PassFrames)
        sm.Seek(--j);
    sm.Read();
    HBITMAP bm = View->MakeDIB(&OutFrameSize, &m_InFrameSize, GetScaleToFit());
    bool    retc = bta.AddFrame(bm);
    DeleteObject(bm);
    if (!m_DisplayOutput)   // prevent view from painting
        View->ValidateRect(NULL);   // must revalidate before SetPos
    pd.SetPos(i);
    if (pd.Canceled())
        return(IDCANCEL);
}

Lissajous

2006-05-10T00:48:00.000-07:00

Tried it. It's too predictable and hugs the edge of the frame too much. Not so good! The random motion is better.

video mirroring quadrant selection

2006-05-09T00:47:00.000-07:00


CSize   FrmSz(m_Size);
CSize   SrcSz(vp->GetFrameSize());
CPoint  SrcPt;
if (m_st.Mirror) {
    FrmSz.cx = (FrmSz.cx + 1) >> 1;
    FrmSz.cy = (FrmSz.cy + 1) >> 1;
    switch (Quadrant) {
    case 0: // upper left
        SrcPt = CPoint(0, SrcSz.cy - 1);
        SrcSz.cx >>= 1;
        SrcSz.cy >>= 1;
        SrcSz.cy = -SrcSz.cy;
        break;
    case 1: // upper right
        SrcPt = CPoint(SrcSz.cx - 1, SrcSz.cy - 1);
        SrcSz.cx >>= 1;
        SrcSz.cy >>= 1;
        SrcSz.cx = -SrcSz.cx;
        SrcSz.cy = -SrcSz.cy;
        break;
    case 2: // lower left
        SrcPt = CPoint(0, 0);
        SrcSz.cx >>= 1;
        SrcSz.cy >>= 1;
        break;
    case 3: // lower right
        SrcPt = CPoint(SrcSz.cx - 1, 0);
        SrcSz.cx >>= 1;
        SrcSz.cy >>= 1;
        SrcSz.cx = -SrcSz.cx;
        break;
    }
} else {
    SrcPt = CPoint(0, SrcSz.cy - 1);
    SrcSz.cy = -SrcSz.cy;
}
HDC sdc;
vp->GetDC(&sdc);
StretchBlt(dc, 0, 0, FrmSz.cx, FrmSz.cy, sdc,
    SrcPt.x, SrcPt.y, SrcSz.cx, SrcSz.cy, m_VideoList.GetROP());
vp->ReleaseDC(sdc);

more optimizations

2006-04-24T00:46:00.000-07:00

In Draw:
replaced CRect::OffsetRect in Bounds calc with inline
replaced CRect::PtInPect in inner loop with inline (BIG difference)
only calculate iorg if making Curves

benchmarks:
hot rod, 1024 x 768, maximized (but not full screen)
default patch, fill & outline, speed = 20 "curve fill bench.whl"
total Draw time for 1000 frames at 25 FPS, in seconds
average ring count = 193


v1.1.01 v1.4.04
---------------
12.643  12.831
12.630  12.641
12.629  12.639
12.629  12.830
12.638  12.651
12.633  12.638
12.637  12.833
12.636  12.645
12.630  12.840
        12.643
        12.633
        12.671
        12.644
        12.639

AVG     AVG
12.634  12.698

1.4.04 has a noticeably larger deviation: most of the samples cluster around 12.64 but every fourth sample or so clusters around 12.83. No idea why! Generally the results are encouraging however. If we go by the averages, 1.4.04 is 64 microseconds slower per frame, which translates to an extra 1.6 milliseconds per second at 25 FPS. If we go by the worst case, 1.4.04 is 210 microseconds slower per frame, i.e. an extra 5.25 milliseconds per second (half a percent). Neither difference is likely to be significant.


Same exact test but without fill (still on hot rod):
v1.1.01 v1.4.04
---------------
0.428   0.413
0.428   0.413

For non-fill case, 1.4.04 is FASTER! Awesome. Presumably inlining PtInRect in the innermost loop made the big difference, let's see.


1.4.04 no fill, using CRect::PtInRect:
        0.447
        0.448

Yup, CRect::PtInRect was bad stuff. Not sure whether it was the function call or inefficiency within PtInRect itself, or maybe both.

An interesting question: why is the difference worse with fill/outline? Almost all of the added code gets executed regardless of draw mode. The only exceptions are the Convex test to decide rp.Color vs. PrevColor, and the (Curve || PrevCurve) test. Surely these can't account for 64..210 microseconds per frame?

per-ring curve decision benchmarks

2006-04-24T00:45:00.001-07:00

Bottom line: The per-ring version (1.4.03) is very slightly faster than 1.4.02. The data shows a consistent improvement of between 5 and 10 microseconds per frame. This is the opposite of the expected result. Perhaps moving the curvature test into the main loop allowed the compiler to better optimize the initial pass (for trail)? It could also be a change in cache behavior.


#include "benchmark.h"
float sum;
int cnt;
void CWhorldView::Draw(HDC dc)
{
CBenchmark  b;
.
.
.
sum += b.Elapsed();
cnt++;
if (cnt == 1000) {
    CString s;
    s.Format("%d %f %f\n", cnt, sum, sum / cnt);
    AfxMessageBox(s);
}

total time (sum) in seconds for 1000 frames

default patch
1.4.02  1.4.03
--------------
1.448   1.436
1.448   1.436
1.442   1.435
1.442   1.439
1.446   1.440

default patch, speed and canvas scale at max
1.4.02  1.4.03
--------------
5.400   5.390
5.396   5.390

help changes for 1.4

2006-04-24T00:45:00.000-07:00

add Odd Curve and Even Curve to parameters (done)
move Canvas Scale and Hue Loop Length from Options/General to Master (done)
change ReadFromPatch to Patch Mode and expand as needed (done)
update keyboard accelerators (done)

using multimedia timer instead of windows timer

2006-04-16T00:43:00.000-07:00

We can't use a multimedia timer all the time (as was suggested on the MFC forum), because it significantly increases CPU useage, e.g. 75% vs. 33%. Windows task-switching overhead is the most likely culprit, especially since using a custom timer thread instead of a multimedia timer produces identical behavior.

We could use a multimedia timer only during non-client modal states, but there's still a visible glitch, due to the phase difference between the windows timer and the multimedia timer. The difference varies from 0 to 1 timer periods, and I can't see any obvious way to avoid it. It's better than doing nothing, but it may have other side effects, so the SendMessage technique shown above may still be the best shot.

corrupt Mirror, Origin, Drawmode in patches

2006-04-14T00:44:00.000-07:00

The first cases appeared on 10/08/2005. Many of the "frosty" patches had it, and the corrupt data propagated from them to other patches, via hybridization. All patches were fixed today. I can't replicate the behavior nor can I find any obvious cause in the current code.

closing aux frame displays file save dialog

2006-04-11T00:44:00.000-07:00

In CMainFrame::DetachView, must remove aux view from document.


    GetDoc()->RemoveView(m_AuxView);    // remove aux view from our document

prevent non-client clicks from pausing app

2006-04-11T00:43:00.000-07:00

The following works, provided the "Show window contents while dragging" system property is unchecked. The only side effects are a) left-clicking on the menu bar moves the cursor to the center of the menu bar (strange, but not really a problem), and b) close happens on button down instead of button up.


void CPersistDlg::OnNcLButtonDown(UINT nHitTest, CPoint point)
{
    switch (nHitTest) {
    case HTCLOSE:
        SendMessage(WM_SYSCOMMAND, SC_CLOSE, 0);
        break;
    case HTCAPTION:
        SendMessage(WM_SYSCOMMAND, SC_MOVE, 0);
        break;
    default:
        CDialog::OnNcLButtonDown(nHitTest, point);
        break;
    }
}

void CPersistDlg::OnNcRButtonDown(UINT nHitTest, CPoint point)
{
    switch (nHitTest) {
    case HTCAPTION:
    case HTSYSMENU:
        SendMessage(WM_CONTEXTMENU, (LONG)m_hWnd, MAKELONG(point.x, point.y));
        break;
    default:
        CDialog::OnNcRButtonDown(nHitTest, point);
        break;
    }
}

benchmarks for drawing AVI frames

2006-04-05T00:41:00.000-07:00


test video: "Movie_051112214725 comp.avi"
Release mode
Master Rings = 0
Window size: 632 x 459
# samples:      1000 (40 seconds)
averages (times in seconds)

Dell / Windows 2000
---------------------
using BitBlt, SRCCOPY
total           0.032182 <- i.e. avg duration of DrawAviFrame
get frame       0.013667 (42.5%)
create bitmap   0.009647 (30.0%)
blit            0.008469 (26.3%)
misc            0.000400 (1.2%)

using StretchBlt, SRCCOPY
total           0.047449 <- exceeds timer period! 47% worse than BitBlt
get frame       0.013653 (28.8%)
create bitmap   0.009758 (20.6%)
blit            0.023656 (49.9%)
misc            0.000383 (0.8%)

using StretchBlt, SRCINVERT
total           0.059013 <- 148% of timer period! 25% worse than SRCCOPY
get frame       0.013646 (23.1%)
create bitmap   0.010457 (17.7%)
blit            0.034508 (58.5%)
misc            0.000402 (0.7%)

Hotrod / XP
---------------------
using BitBlt, SRCCOPY
total           0.004478 <- i.e. avg duration of DrawAviFrame
get frame       0.002263 (50.5%)
create bitmap   0.001238 (27.6%)
blit            0.000881 (19.7%)
misc            0.000096 (2.1%)

using StretchBlt, SRCCOPY
total           0.006912 <- 54% worse than BitBlt
get frame       0.002257 (32.7%)
create bitmap   0.001240 (17.9%)
blit            0.003314 (48.0%)
misc            0.000100 (1.4%)

using StretchBlt, SRCINVERT
total           0.008200 <- 20% of timer period, 19% worse than SRCCOPY
get frame       0.002267 (27.6%)
create bitmap   0.001239 (15.1%)
blit            0.004592 (56.0%)
misc            0.000102 (1.2%)

Conclusion:
Hotrod is 7.2 times faster, but StretchBlt mode is bad stuff.

#include "benchmark.h"
double  blitsum;
double  createsum;
double  getfrmsum;
double  totsum;
int samps;
...
totsum += b.Elapsed();
samps++;
if (samps == 1000) {
    CString s;
    double  total = totsum / samps;
    double  getfrm = getfrmsum / samps;
    double  create = createsum / samps;
    double  blit = blitsum / samps;
    double  misc = total - (getfrm + create + blit);
    s.Format("total\t%f\ngetfrm\t%f (%.1f%%)\ncreate\t%f (%.1f%%)\nblit\t%f (%.1f%%)\nmisc\t%f (%.1f%%)", 
        total, 
        getfrm, getfrm / total * 100, 
        create, create / total * 100, 
        blit, blit / total * 100, 
        misc, misc / total * 100);
    AfxMessageBox(s);
}

effect of ROPs on background

2006-03-31T00:40:00.000-08:00


reverse polish notation! read right to left!

P       Selected pen
D       Destination bitmap
a       Bitwise AND
n       Bitwise NOT (inverse)
o       Bitwise OR
x       Bitwise exclusive OR (XOR)

1       R2_BLACK        0       makes everything black
2       R2_NOTMERGEPEN  DPon    black outlining leaves bg unchanged, else pen is inverted and translucent (correct when bg is black, else darker)
3       R2_MASKNOTPEN   DPna    black outlining leaves bg unchanged, else pen is inverted and translucent (correct when bg is white, else darker)
4       R2_NOTCOPYPEN   Pn      overwrites bg, inverted drawing color
5       R2_MASKPENNOT   PDna    white outlining leaves bg unchanged, else pen is translucent (correct when bg is black, else darker)
6       R2_NOT          Dn      reverses bg: outlining or overlap shows bg unchanged (it's inverted twice)
7       R2_XORPEN       DPx     the coolest
8       R2_NOTMASKPEN   DPan    white outlining leaves bg unchanged, else pen is inverted and translucent (correct when bg is black, else lighter)
9       R2_MASKPEN      DPa     white outlining leaves bg unchanged, else pen is translucent (correct when bg is white, else darker)
10      R2_NOTXORPEN    DPxn    similar to xor
11      R2_NOP          D       drawing is invisible
12      R2_MERGENOTPEN  DPno    drawing in white leaves bg unchanged, else pen is inverted and translucent (opaque when bg is black)
13      R2_COPYPEN      P       straight copy
14      R2_MERGEPENNOT  PDno    black outlining leaves bg unchanged, else pen is translucent (correct when bg is white)
15      R2_MERGEPEN     DPo     black outlining leaves bg unchanged, else pen is translucent (correct when bg is black)
16      R2_WHITE        1       makes everything white

more zoom/origin hell

2006-03-25T00:40:00.000-08:00

The really weird thing is, it looks much better if the origin DOESN'T move in mirror mode!!! So it's actually not broken at the moment, except for

1) the move and return thing, and that's gone now that the normalized origin isn't zoomed
2) the problem with trail (outer rings move when they shouldn't)
3) make DIB must still use center zoom, otherwise scale to fit will screw up mirrored snapshots

zoom/origin hell

2006-03-23T00:39:00.000-08:00

Unmirrored zooming is supposed to be origin-centered, i.e. you zoom into or out of the ring origin. This isn't allowed in mirror mode because it would change the image. In mirror mode, you zoom into or out of the *mirror origin* (i.e. the center of the screen), and let the ring origin move as needed so that the image stays the same.

origin behavior with zooming, version 1.1:


mirror  drag    behavior
no      no      stationary: correct
yes     no      moves: correct
no      yes     stationary: correct
yes     yes     stationary (or with damping, moves and then returns): BOGUS

origin behavior with zooming, version 1.3 (trail):


mirror  drag    behavior
no      no      moves: BOGUS
yes     no      moves: correct
no      yes     stationary, but with damping, moves and then returns: BOGUS
yes     yes     stationary (or with damping, moves and then returns): BOGUS

Note that random origin may have the same problems as drag origin; it's hard to tell.

Trail complicates things further, because if the origin moves and returns, the trail pattern is lost.

Really there are two separate problems:

1) The damping feature of the origin motion prevents the ring origin from moving during zoom, or causes it to slip back. As a result, zooming in mirror mode changes the mirror imagery. This behavior always occurred in mirror mode, but somehow it went unnoticed; adding trail made it more noticeable, by causing it to affect unmirrored mode also.

The likely cause is that When you zoom in mirrored mode, the view's normalized origin changes, but the main frame's target origin (also in normalized space) DOESN'T change, so the view eventually slips back to the target origin. This can be solved by saving the normalized origin before zooming the view, and then correcting the target origin by the difference between the new normalized origin and the saved one.

2) Adding trail broke zooming into the ring origin. It could be argued that this was a bad idea anyway and that we should always zoom into the mirror origin, in which case this bug is actually a feature. However, this argument doesn't really hold up, because zooming into the ring origin is typically more interesting than zooming into whatever happens to be in the center of the screen.

This problem could possibly be solved by a temporary coordinate space change, so that the zoom scaling is done in ring-origin space instead of mirror-origin space. You could calculate the difference between the master ring origin and the center of the screen, and then for each ring, subtract the difference from its origin, multiply by zoom, and add the difference back on.

FillPath vs. StrokeAndFillPath

2006-03-20T00:39:00.000-08:00

benchmark of FillPath vs. StrokeAndFillPath with null brush:
no significant difference

uniform curvature with respect to number of sides

2006-03-20T00:38:00.000-08:00


// decrease curvature as number of sides increases
// behavior is somewhat more orderly but not as interesting either
double  s = 1.0f / float(Ring.Sides - 2);
Ring.EvenCurve = float(m_Parms.EvenCurve * s);
Ring.OddCurve = float(m_Parms.OddCurve * s);

help changes for 1.3

2006-02-28T00:37:00.001-08:00

add Random Ramp to Waveforms GIF (done)
add Trail to Master Controls (done)
add Convex to Trail (done)
add Convex to Effects (done)
modify Origin Motion for Trail (done)
modify Mouse Modes for Trail (done)
modify Canvas Scale for new origin limits (done)
modify Zoom for new origin limits and Window/Zoom (done)
modify Panic for Trail reset (done)
update shortcut tables (done)
add Trail to features list on web site (done)
idea: comprehensive list of menu commands?

help changes for 1.2

2006-02-28T00:37:00.000-08:00

Master offsets are now saved. Affected topics: Master Offsets, Playlists
Add oscillator override (new topic)
Add MIDI setup's Advanced checkbox
Zero controllers / Panic reset oscillator frequency overrides

MIDI color oscillator overrides

2006-02-27T00:28:00.000-08:00

Frequency AND amplitude, for each color component (HLS), for both foreground and background color is 2 * 3 * 2 = 12 knobs. It turns out to be too much to handle live. Better to control the frequencies only, and hard-code the amplitudes:


                amp     freq (range)
color speed     1       .1
lightness       .25     .1
saturation      .5      .1
bk hue          180     .01
bk lightness    .25     .1
bk saturation   .5      .1

don't draw to video memory

2006-02-23T00:28:00.000-08:00

Supposedly mirrored mode is faster because it reduces drawing by 3/4, but even if this difference is eliminated (by restricting drawing to the upper left quadrant), mirrored mode is STILL faster. The reason is that mirrored mode always draws to system memory. The solution is to draw to system memory in all cases.

awesome matt trail demo

2006-02-07T00:27:00.000-08:00

patch "pinwheel fab color", master 158, zoom 119, damping 95.5, tempo 14.96, unmirrored, fill, outline (requires serious hotrod action)

This demo proves that trail is way better than odd shift and should be up next on the enhancement list.

allow user to register BmpToAvi

2006-02-03T00:27:00.000-08:00

Cool idea, but unnecessary: now that the installer correctly handles upgrading (each release must have a new project GUID, but the same upgrade GUID), this situation can't arise anymore.


if (bta.GetLastError() == CBmpToAvi::ERR_CREATE_SOURCE
&& hr == REGDB_E_CLASSNOTREG) {
    static const LPCSTR BmpToAviName = "BmpToAvi.ax";
    if (AfxMessageBox(IDS_MEX_BTA_INSTALL, MB_YESNO) == IDYES) {
        CPathStr    path = CMainFrame::GetAppPath();
        path.Append(BmpToAviName);
        if (PathFileExists(path)) {
            CString cmd;
            cmd.Format("regsvr32 /s \"%s\"", path);
            int retc = system(cmd);
            if (retc)
                AfxMessageBox(IDS_MEX_BTA_CANT_REG);
            else
                goto retry;
        } else {
            CString s;
            s.Format(IDS_MEX_BTA_NOT_FOUND, BmpToAviName);
            AfxMessageBox(s);
        }
    }
}

no more 2 GB limit

2006-02-03T00:26:00.000-08:00

I took a look at the OpenDML stuff, but in the end I decided to solve this the MS way: I wrote my own DirectShow show source filter that inserts frames (as bitmaps) into a video stream.

That turned out to be the *easy* part! The SDK's "ball" example was a pretty good starting part for writing a DirectShow source filter. The only real problem is that the ball filter draws the frames itself, whereas I needed to draw the frames in the application, and then pass them to the source filter. Turns out MS thought of that: you can override the DoBufferProcessingLoop function, cool.

There's also the minor detail of how to call my filter's "add frame" function from the application: turns out that requires creating a new COM interface. A bit of research, but not too bad. And of course I need some application code to create a filter graph, connect all the "pins" together and run the graph. There are examples of this all over the place, nothing new here.

The real problem came from an unexpected direction: how to set the video compression options? The Vfw AVIFile API had a wonderful function called AVISaveOptions: it displayed a dialog listing all your video compressors, and allowed you to select one and configure it. And in DirectShow? Nothing like that exists. Insane but true.

So I wound up writing a DirectShow Video Compression dialog object. You pass it your source and destination filters, and it displays the dialog, and returns a fully-configured compressor filter.

The bottom line? I have developed two reusable technologies:
1) A DirectShow BMP to AVI converter.
2) A DirectShow Video Compression dialog

I suspect both could be useful to other developers, so I'm going to submit them to CodeProject later. Right now my priority is integrating them into a new version of Whorld.

data rates

2006-02-01T00:25:00.000-08:00

In AVIFile's Video Compression dialog, tried setting data rate for a few encoders:
indeo video 5.1
Intel indeo video R3.2
used steve1, crop, 320x240, frames 5000-5200
In both cases, checking the box caused the data rate in the file to drop by almost half REGARDLESS of what number was typed for data rate. crazy!

Things that weren't obvious

2006-02-01T00:24:00.000-08:00

1) IAMVfwCompressDialogs must be used AFTER THE COMPRESSOR IS CONNECTED, otherwise Configure ignores SetState and reinitializes the dialog every time
2) IAMVideoCompression must be created on the OUTPUT PIN of the compressor, not the on compressor itself
3) any size other than 320 x 240 causes first-chance exception in QCAP.DLL (debug only)

more problems: can't seem to set output bit rate, maybe that just doesn't work


IPin    *pComprOut = CDSBmpToAvi::GetPin(ip->pCompr, PINDIR_OUTPUT);
if (pComprOut != NULL) {    // if we got compressor's output pin
    IAMStreamConfig *pStreamCfg = NULL;
    m_hr = pComprOut->QueryInterface(   // get IAMVideoCompression
        IID_IAMStreamConfig, (void **)&pStreamCfg);
    if (pStreamCfg != NULL) {   // do GetFormat after input pin is connected
        AM_MEDIA_TYPE   *pmt;
        m_hr = pStreamCfg->GetFormat(&pmt);
        if (SUCCEEDED(m_hr)) {
            printf("get format ok\n");
            if (pmt->formattype == FORMAT_VideoInfo) {
                VIDEOINFOHEADER *pvh = (VIDEOINFOHEADER *)pmt->pbFormat;
                printf("%d\n", pvh->dwBitRate);
                pvh->dwBitRate = 10000;
                m_hr = pStreamCfg->SetFormat(pmt);
                if (SUCCEEDED(m_hr)) {
                    printf("set format ok\n");
                }
    //          DeleteMediaType(pmt);
            }
        }
    }
}

DirectShow source filter

2006-01-29T00:21:00.000-08:00

CodeGuru's snake sample prog doesn't work, it hangs
to register or unregister a filter (e.g. ball.ax):
regsrv32 ball.ax
regsrv32 /u ball.ax
then draw a filter graph using graphedt.exe
to view, connect ball -> video renderer
to create AVI file, connect ball -> AVI mux -> file writer
this works fine, but important questions remain
1) how do you run the filter chain without using graphedt?
2) how do you get the app to communicate the frames to the filter?
3) where does the source filter's GUID come from?

invalid pixel format

2006-01-10T00:19:00.000-08:00

Ben C's Gateway won't run Whorld in DirectDraw mode: it gives the error DDERR_INVALIDPIXELFORMAT. He initially had DirectX 8.0, I upgraded to 8.1 but it didn't help. Checked the Display Settings, he had 24-bit 1024x768. Tried 640x480, didn't help. Try 16-bit color?

POINTF vs DPOINT

2006-01-03T00:18:00.000-08:00

Using POINTF (e.g. for Pucker) saves 8 bytes in the RING struct, which reduces the disk throughput requirements for snapshot movies. It doesn't seem to measureably worsen CPU usage. The downside is trading 15 digits of precision for 7. For items that remain constant over the life of a ring (e.g. Pucker), it might not matter, but for items that are incremented per frame (e.g. origin), it definitely *does* matter.

hogging CPU breaks About dialog

2005-12-22T00:18:00.000-08:00

If main is saturating the CPU, Help/About makes the app modal, but no dialog is displayed. The bug occurs with any dialog created via DoModal, but it does NOT occur with the common dialogs (e.g. CFileDialog), presumably because they use a different creation method. Help/About is currently the only non-common modal dialog accessible directly from the main menu, which is why the bug wasn't discovered earlier.

One workaround is to disable the main timer in CAboutDlg::OnInitDialog, and then re-enable it in ShowWindow. An easier one is to do an explicit ShowWindow in CAboutDlg::OnInitDialog.

changing hue loop length

2005-12-21T00:17:00.000-08:00

Changing the hue loop length without compensation causes distracting jumps in hue. Reflecting the hue position prevents jumps entirely when the loop length is increased, and minimizes the probability of a jump when the loop length is decreased. Without changing the base position, it's impossible to prevent jumps entirely in the latter case, because the current hue may no longer fall within the range of the loop.


if (m_st.HueLoop && m_st.HueLoopLength) // try to avoid hue jump
 m_st.HueLoopPos = Reflect(m_st.HueLoopPos, m_st.HueLoopLength);
m_st.HueLoopLength = Length;

limiting random origin motion

2005-11-11T00:13:00.000-08:00


double  RandOrgRange = 1;   // 0 to 2, default is 1
DPOINT  RandOrgBias = {0, 0};   // -.5 to .5, default is 0
double  ofs = (1 - RandOrgRange) / 2;
m_TargetOrg.x = double(rand()) / RAND_MAX
    * RandOrgRange + ofs + RandOrgBias.x;
m_TargetOrg.y = double(rand()) / RAND_MAX
    * RandOrgRange + ofs + RandOrgBias.y;

seed of life

2005-11-09T00:13:00.000-08:00

It's dependent on the frame rate. Frame rate, birth rate, ring spacing, and skew angle delta interact to determine how many ring tunnels are generated.

If birth rate = 1, ring spacing = 5, and skew angle freq = 1, at 25 FPS you get 5 ring tunnels (a 5-way seed of life), because you're generating 5 rings per second, and each ring has a fifth of the skew angle delta (.2 Hz = 72 degrees), and 5 clock ticks.

at 30 FPS, with the same settings, you get a 6-way seed of life.

Color speed can also be adjusted to achieve a constant color for each tunnel. 14.4 (a fifth of 72) works for the 5-way at skew angle = 1; 90 works for most of the others.

Since the rings continue to intersect at the origin no matter how big they get, the rings will never be entirely off-canvas, and thus will never be deleted. This is a dangerous side effect and yet another argument for a max rings parameter.


Useful formulas:
        Birth   Ring    Skew    ring    color
FPS     Rate    Space   Ang Hz  tunnels speed
25      .25     5       1.25    1       90
25      .5      5       1.25    2       90
25      .75     5       1.25    3       90
25      1       5       1.25    4       90
25      1.25    5       1.25    5       72
25      1.5     5       1.25    6       90
25      1.75    5       1.25    7       90*
25      2       5       1.25    8       90*
25      2.25    5       1.25    9       90*
25      2.5     5       1.25    10      72*

*colors are stable but tunnels don't appear in spectral order

objects needing more comments

2005-10-27T00:12:00.000-07:00

ctrlresize, replacefilesdlg, masterdlg, parmrow, playlist, numbersdlg, viewdialog

adding HLS color to existing snapshots

2005-10-25T00:12:00.000-07:00


ar << sizeof(RING);
ar << m_Ring.GetCount();
POSITION    pos = m_Ring.GetHeadPosition();
for (int i = 0; i < m_Ring.GetCount(); i++) {
    RING    rp = m_Ring.GetNext(pos);
    double  h, l, s;
    int c = rp.Color;
    CHLS::rgb2hls(GetRValue(c) / 255.0, 
        GetGValue(c) / 255.0, GetBValue(c) / 255.0, h, l, s);
    rp.Hue = h;
    rp.Lightness = l;
    rp.Saturation = s;
    ar.Write(&rp, sizeof(RING));
}

Movie format could save space

2005-10-24T00:11:00.000-07:00

The movies are using the snapshot format, which includes all of the ring info. In the ring info, the rotation and shift deltas and the HLS color are not used at all during movie playback. These attributes constitute 40 bytes out of 120, or one third of the total size of the ring structure. The actual savings could be nearly a third, since most of the space in a movie is taken up by rings (hundreds of rings per frame).

The savings would require adding a second serialization method, e.g. MiniSerialize, which would be used by the SnapMovie object. The method could be optimized by placing the deltas and the HLS color at the start of the ring structure, because then it would still be possible to do a single write directly from the ring, instead of copying to an intermediate structure first.

A problem with this approach is that it would longer be possible to export a complete (non-mini) snapshot from a movie, since some of the information would be missing. The HLS color could be restored from RGB, but not the deltas. On the other hand the deltas aren't useful in snapshots so maybe it wouldn't matter.

NOTE that WinZip reduces Steve1.whm by 61%, and Steve2.whm by 73%.

Space-saving benchmarks:

60 seconds, 25 FPS, default speed, window maximized but not full-screen, wait for full ring count before starting to record, sizes in MB, ring counts are rough averages


patch           rings   old     new     less
kaleid          1000    172.5   108.8   37%
pinwheel        500     98.0    62.5    36%
lotus light     300     71.4    46.5    35%
cross           150     34.6    26.3    24%

useful nugget of ring conversion code:


nr.RotDelta = rp.RotDelta;
nr.ShiftDelta = rp.ShiftDelta;
nr.Hue = rp.Hue;
nr.Lightness = rp.Lightness;
nr.Saturation = rp.Saturation;
nr.Rot = rp.Rot;
nr.Steps = rp.Steps;
nr.Scale = rp.Scale;
nr.Shift = rp.Shift;
nr.StarRatio = rp.StarRatio;
nr.Sides = rp.Sides;
nr.Delete = rp.Delete;
nr.Reverse = rp.Reverse;
nr.Color = rp.Color;
nr.Pinwheel = rp.Pinwheel;
nr.LineWidth = rp.LineWidth;
nr.DrawMode = rp.DrawMode;
nr.Spacing = rp.Spacing;

array of CArrays not optimized correctly

2005-10-20T00:10:00.000-07:00

It looks like dereferencing an array of CArray objects can causes MFC to call the [] operator, instead of inlining it, even in Release mode. Presumably this is why:


int CPlaylistDlg::FindHotKey(DWORD HotKey) const
{
    int Patches = GetCount();
    for (int i = 0; i < Patches; i++) {
        if (HotKey == m_Bank[m_CurBank][i].m_HotKey)
            return(i);
    }
    return(-1);
}

generates twice as much code as:


int CPlaylistDlg::FindHotKey(DWORD HotKey) const
{
    int Patches = GetCount();
    for (int i = 0; i < Patches; i++) {
        if (HotKey == (*m_Patch)[i].m_HotKey)
            return(i);
    }
    return(-1);
}

Oddly, this is bad too:


int CPlaylistDlg::FindHotKey(DWORD HotKey) const
{
    int Patches = GetCount();
    const PATCH_LIST    *p  = &m_Bank[m_CurBank];
    for (int i = 0; i < Patches; i++) {
        if (HotKey == (*p)[i].m_HotKey)
            return(i);
    }
    return(-1);
}

but this is fine (1 line longer than original):


int CPlaylistDlg::FindHotKey(DWORD HotKey) const
{
    int Patches = GetCount();
    for (int i = 0; i < Patches; i++) {
        if (HotKey == m_Bank[m_CurBank].GetData()[i].m_HotKey)
            return(i);
    }
    return(-1);
}

MainFrame bloat

2005-10-08T00:10:00.000-07:00

2662 lines and counting, ouch
non-message handlers 1139
message map 166
message handlers 1200

things that could move easily:
ShowDemo: only 32 lines but could get bigger

not so easy
GetInput: 83 lines and could get bigger

odd shift

2005-10-08T00:08:00.000-07:00


double  xshift[2] = {rp.Shift.x * m_st.Zoom, (rp.Shift.x + rp.OddShift.x) * m_st.Zoom};
double  yshift[2] = {rp.Shift.y * m_st.Zoom, (rp.Shift.y + rp.OddShift.y) * m_st.Zoom};

Notice that the calculation is NOT corrected for radius. This causes the effect to decrease with distance from the origin. Correcting for radius gives a very different and less pleasing effect. The display becomes too busy, and at extreme values, the image is distorted into a narrow cylinder. The first objection could possibly be addressed by limiting the size of the ring list.


To correct the above for radius:
double  xshift[2] = {rp.Shift.x * m_st.Zoom, (rp.Shift.x + rp.OddShift.x * rp.Steps) * m_st.Zoom};
double  yshift[2] = {rp.Shift.y * m_st.Zoom, (rp.Shift.y + rp.OddShift.y * rp.Steps) * m_st.Zoom};

Some possible names for "odd shift":

Shear: incorrect usage
Extrude: incorrect usage
Tilt: too vague
Tunnel: too vague, also other parameters can produce this effect
Relief: too vague
Stamen: too obscure
Center Fold: misleading, the new version corrects for radius, see below
Splay: means legs spread at various angles, not various lengths
Deform: vague, not a noun, misleading negative connotations
Bias: misleading connotation of unfairness
Fold: vague, possibly misleading
Asymmetry: vague, too long a word

10/29/05 corrected for radius but also centered, much better


DPOINT  splay = {rp.Splay.x * rp.Steps, rp.Splay.y * rp.Steps};
double  xshift[2] = {
    (rp.Shift.x - splay.x) * m_st.Zoom, 
    (rp.Shift.x + splay.x) * m_st.Zoom};
double  yshift[2] = {
    (rp.Shift.y - splay.y) * m_st.Zoom, 
    (rp.Shift.y + splay.y) * m_st.Zoom};

Controls should be polar as with Skew: Splay Radius, Splay Angle

Some interesting interdependent terms:
Contort: Twist, wrench, or bend severely out of shape
Pinch: To press, squeeze, or bind painfully
Buckle: Bending, warping, or crumpling; a bend or bulge
Rumple: An irregular or untidy crease
Crumple: To crush together or press into wrinkles; rumple
Crease: A line made by pressing, folding, or wrinkling
Wrinkle: A small furrow, ridge, or crease on a normally smooth surface
Pucker: To gather into small wrinkles or folds

And the winner as of 12/17/05 is:
PUCKER

totally cool demo: default patch, ring spacing 11.192, pucker radius -.406, pucker angle -65.88 / ramp up / 180 / .08, master speed 222

another one: patch_051028050234, rings = 75, pucker rad = .268, angle = ramp up / 180 / .5, speed = 495

optimized 12/19/05 (two less Zoom multiplications):


DPOINT  pucker = {rp.Pucker.x * steps, rp.Pucker.y * steps};
DPOINT  shift = {rp.Shift.x * m_st.Zoom, rp.Shift.y * m_st.Zoom};
double  xshift[2] = {shift.x - pucker.x, shift.x + pucker.x};
double  yshift[2] = {shift.y - pucker.y, shift.y + pucker.y};

ring list size limit

2005-10-08T00:03:00.000-07:00


in AddRing, at the very end:
while (m_Ring.GetCount() > whatever) {
    if (Ring.Reverse)
        m_Ring.RemoveHead();
    else
        m_Ring.RemoveTail();
}

Bézier curves

2005-10-08T00:02:00.000-07:00


in Draw:
#if 1
    m_pa[i] = m_pa[0];  // close the shape
    Polyline(dc, m_pa, sides + 1);
#else
    CPoint  pt2[200];
    int j = 0;
    for (int i = 0; i < sides; i++) {
        pt2[j++] = m_pa[i];
        if (i & 1)
            pt2[j++] = CPoint(m_pa[i].x, m_pa[i].y);
    }
    pt2[j++] = pt2[0];
    PolyBezier(dc, pt2, j);
#endif

scene rotation

2005-10-01T00:01:00.001-07:00


in DefState:
    0   // Rotation

in Addring:
    Ring.Rot = Ring.RotDelta * Offset + m_st.Rotation;

void CWhorldView::Rotate(double Degrees, bool Repaint)
{
    POSITION    pos = m_Ring.GetHeadPosition();
    double  r = DTR(Degrees);
    while (pos != NULL) {
        RING&   Ring = m_Ring.GetNext(pos);
        Ring.Rot += r;
    }
    m_st.Rotation = fmod(m_st.Rotation + r, 2 * PI);    // wrap to limit magnitude
    if (Repaint)
        Invalidate();
}

Note that this causes unexpected behavior (addition, subtraction, cancelation) when rotation is inverse of LFO rotation. Also X/Y shifts are NOT rotated, so for example if Aspect Ratio is 2, the asymmetry will remain orthogonal instead of rotating. Solving this would require changes to the drawing code.

benchmarks for movie recording

2005-10-01T00:01:00.000-07:00

------------
PIII, Kaleid, 1024 x 768, 30 FPS, speed = 680, 2500 samps: min = .001197, max = .004851, avg = .001821, sdev = .000362

avg .002 = .06 @ second = 6% avg usage for recording
-----------
AMD, Kaleid, 1024 x 768, 30 FPS, speed = 680, 2500 samps: min = .000167, max = .000611, avg = .000322, sdev = 8.8329E-05

avg .0003 = .009 @ second = .9% avg usage for recording
------------
AMD test repeated over 5 minutes: min = .000172, max = .005491, avg = .000485, sdev = .000129

all samples were < than 1 ms except for a single single spike of 0.005491 at 3:38
------------

glitch #1: Jeff & Sean

2005-10-01T00:00:00.000-07:00

Sean:

1. Visible tearing of image: DirectX is supposed to care of this no? Would full-screen mode affect it? Possibly affected by frame rate and CPU loading.

2. Should sync to beat automatically.

3. Should support multiple trackballs and other input devices at once.

Jeff:

1. Support for MIDI notes would be helpful since he's using an Oxygen 8. Notes could act as toggles for the function keys.

2. Tempo nudge should NOT resync, or at least there should be an alternate nudge that doesn't resync. Sean agrees.

3. Rotation of the entire image (as opposed to rotate speed), especially via MIDI.

4. Zoom should go further out: can do this with MIDI.

movie disk requirements

2005-09-28T00:00:00.000-07:00

The data rate of a WHM movie file is linearly proportional to scene complexity (as measured by ring count), and is also affected by the frame rate. Typical data rates range from .4 - 3.0 MBytes @ second, which means a 1-hour recording can require anywhere from 1.5 to 10 GB.

Both ATA 100 and Firewire A can sustain write data rates of at least 30 MB @ second, with minimal CPU loading, so performance probably isn't an issue. Disk space could be an issue, particularly on older machines.

Using WinZip on a WHM file typically yields a 60% - 70% size reduction. Recording to a compressed folder yields a 40% - 60% reduction, but causes the display to freeze at regular intervals on a PIII machine. The Gnu zlib compression library might have less impact, but some increase in CPU load is inevitable. To reduce disk usage, it might make sense to compress WHM files after recording. The app could include an option that does this automatically, but it would have to be done from a separate low-priority thread, and even then performance might be affected by context switching.

A higher-order solution would record user input instead of recording ring data. This would reduce the data rate to a negligible amount, but at the expense of greatly increased complexity and fragility. This method should be explored for a future version.

A very rough estimate of the data rate resulting from input recording:

Record cursor delta for every frame: 8 bytes (2 ints) @ frame
Record 16 MIDI controllers for every frame (worst case): 48 bytes @ frame
Keyboard commands are too infrequent to affect the estimate
8 + 48 = 56 bytes per frame; at 30 FPS, 56 * 30 = 1680 bytes @ second
That's 6MB per hour in the absolute worst case

Some benchmarks:

Uncompressed 1024 x 768 video at 30 FPS: 70.5 MB @ sec
Lotus light, speed around 700, 30 FPS, 1 minute = 131 MB (2.2 MB @ sec)
Cross, speed around 700, 30 FPS, 1:36 = 80 MB (.83 MB @ sec)
Kaleid, speed around 700, 30 FPS, 1:36 = 282 MB (2.9 MB @ sec)

Another interesting possibility: Recording the view's oscillators and STATE member but not the rings, and then regenerating the rings on playback/export

1 oscillator = 44 bytes * 16 = 704 bytes @ frame
view STATE member = 104 bytes + 704 = 808 bytes @ frame
call it 1K bytes @ frame, at 30 FPS = 30K bytes @ second (108 MB @ hour)

making a WMV-9 DVD

2005-09-22T23:59:00.000-07:00

Toshi says no need to change frame rate for WMV; between 5 and 20 MBits per sec should be good, and 1024 x 768 is fine. Must compress the bitmaps first to make enough room to create an AVI, expect on the order of 75% compression overall.

additional MIDI control

2005-09-12T23:58:00.000-07:00

on/off: mirror, fill, outline, xray, invert hue, invert fill, invert outline, invert xray, rotate hue, reverse

zoom should be damped, no?

show size in status bar message while resizing

2005-09-10T23:57:00.000-07:00

You must handle WM_ENTERSIZEMOVE and wM_EXITSIZEMOVE to show the initial size and restore the default message.


LRESULT CMainFrame::OnEnterSizeMove(WPARAM wParam, LPARAM lParam)
{
    CRect   r;
    m_View->GetClientRect(r);
    CString s;
    s.Format("%d x %d\n", r.Width(), r.Height());
    SetMessageText(s);  // must do all the above in OnSize too, but only if window is visible
    return(TRUE);
}

LRESULT CMainFrame::OnExitSizeMove(WPARAM wParam, LPARAM lParam)
{
    SetMessageText(AFX_IDS_IDLEMESSAGE);
    return(TRUE);
}

Note that this only works if the system property "show window contents while dragging" is set. Otherwise you only see the initial size, because WM_SIZE isn't sent until the drag ends. WM_SIZING *is* sent, but it doesn't help, because it passes us the size of the frame, whereas we want the size of the view. Oddly, there seems to be no way to determine the client area that would result from a given window size. CalcWindowRect does the reverse: it gives us the size of the window needed for a given client area.

CalcWindowRect bug

2005-09-06T23:56:00.000-07:00

This bug first appeared during the development of movie export. Moving the export to a separate process made it go away, but now it's back in version 1.0.73. Most likely the AVI file DLL was falsely accused and the movie export could have been part of the main app, but that's a secondary issue.

The symptom is, the app crashes in RowDialogForm's CalcWindowRect during the construction of the Parms dialog. It doesn't crash in debug, only in release, and creating a console window makes it go away (great!). Deleting the unused m_Template member variable from CPersistDlg.h also makes it go away. This last symptom clearly points towards a memory corruption problem of some kind. In the release debugger, the problem begins when CRowDialog::OnInitDialog calls CViewDialog::OnInitDialog. After this call, CRowDialog's "this" and HWND are trashed. Note that neither CViewDialog nor its immediate base class (CPersistDlg) override OnInitDialog, so this is effectively a call to CDialog::OnInitDialog.

Removing the call to MakeVJAccelTable in CMainFrame's ctor also makes it go away.

The really bad news: the app only crashes when you execute it from the IDE; running from Explorer is OK.

Other observations:
in Frame's ctor list, m_ResultsDlg(m_View), is incorrect initialization, m_View isn't the dialog's parent and in any case it's NULL! deleting this line doesn't help though...

could be passing 'this' to dialogs isn't such a good idea after all, seems like CMainFrame's 'this' keeps changing somehow or is that just the debugger being bad in release mode?

The solution: in CalcWindowRect, casting GetParent() down to CRowDialog isn't always correct. Initially, the parent is the dummy frame, not CRowDialog. Use a dynamic downcast to determine the parent.

The moral of the story: Downcasting is dangerous so use dynamic downcast and verify the result!

movies

2005-08-29T23:56:00.000-07:00

pjbmp2avi.exe seems to work fine, with the CinePack codec at 100% (default) it's about 11MB for 36 seconds.

Storing snapshots with window size at 720x480 (DVD fullscreen) yields 80K snaps on average, with no appreciable slowdown: 80 * 25 * 60 = 120MB @ minute. This seems better than storing bitmaps.

Actual date rate test: demo speed = 975, 18.4 minutes, size 1.256 GB, rate = 73MB @ minute

Random waveform bug can be demonstrated using new OscTest, settings: random, .01, .5, .05, .1

almost there

2005-08-28T23:55:00.000-07:00

During crossfade, random waveform's frequency change glitches horribly, fix this. Also fix a minor glitch when patch is switched without crossfade: in this case clear the view's previous parameter info to prevent interpolation. Ring growth and master speed glitch too but it's less noticeable.

Overall it looks gorgeous and feels incredibly powerful and exciting, it's a different whorld. Master speed of 901 is very nice, maybe use this speed for demo? Maybe a bit too fast, 603 is good too...

Random waveform bug can be demonstrated using new OscTest, settings: random, .01, .5, .05, .1

more on clumping

2005-08-27T23:55:00.000-07:00

oscillator must move into view so it can be subclocked (non-integer clock increments). See 1.0.69c.

clumping

2005-08-24T23:54:00.000-07:00

The clumping problem goes all the way back to the beginning. It occurs when master speed and/or ring growth) are big enough to cause multiple rings per timer tick. When the view's timer hook adds multiple rings, the rings all share the same properties, which causes those rings to form an easily distinguishable group or "clump".

The worst offenders are rotation and skew (AKA shift). Both of these are zeroed at birth, and then incremented by the view's draw function. A major reduction of clumping can be obtained simply by offsetting each ring's initial rotation and skew. The offset is a delta multiplied by a fraction. The fraction is calculated by dividing the ring's index by the total number of rings that will be born for this timer tick. If four rings will be born, the fractions for the rings will be 0, .25, .5, and .75 respectively, and if the current rotation delta is .2, the initial rotations for the rings will be 0 * .2, .25 * .2, .5 * .2, and .75 * .2.

The only complication is that the rings are generated in reverse order. This means the indices have to be inverted, e.g. by using (count - 1 - i) instead of i, which means the count must be computed before the ring-adding loop begins. The count can be computed as:


int(m_st.RingOffset / m_Parms.RingSpacing) + 1;

Also note that the resulting offsets must be multiplied by RingGrowth to be effective.

The next-worst offenders are the LFOs. The LFOs are outside the view, but they only modify the view parameters on timer tick boundaries. This means that any LFO has the potential to cause clumping. The high road would move the oscillators into the view but this is a drastic change and has many side effects. The low road is to interpolate between the current and previous parameter values. In practice interpolation seems to work very well for all parameters except ring growth and ring sides. The view timer hook must calculate a delta between each parameter's current and previous values, like so:


for (int j = 0; j < 16; j++)
    delta[j] = (((double *)&prevparm)[j] - ((double *)&m_Parms)[j]) / count;

And then within the ring-adding loop, overwrite m_Parms with interpolated values:


for (j = 0; j < 16; j++)    // NOTE: don't do this to ring growth or # sides
    ((double *)&m_Parms)[j] = ((double *)&prevparm)[j] + delta[j] * (count - 1 - i);

And finally, restore m_Parms.

Interestingly, this seems to work perfectly with sine LFOs, but exhibits a noticeable periodic discontinuity with triangle LFOs. This seems to indicate an undiscovered problem with the above method, or possibly a bug in the oscillator object.

The final offender is the ring color. This is calculated in the view's timer hook, which means all the rings in a group will have the exact same color. This can probably be solved by interpolation as well.

front page image

2005-08-18T23:53:00.000-07:00

1896x1038x72
canvas size to 1280x700
save for web at 50% jpeg high
result 640x350 +/- 35K

reverse and per-ring draw mode

2005-08-06T23:52:00.001-07:00

In reverse, innermost ring fill test must be steps < minimum size AND steps < previous radius. This prevents possible holes when switching from forward to reverse, e.g. in lotus light.

The new freedoms must have a price, let's see:

250 iters of default patch, total time spent in Draw:

1.0.64:
.2269
.2237
.2263
.2251
AVG=.2255

1.0.63:
.2256
.2255
.2271
.2273
AVG=.2263

It got faster? Not likely. Try again using 250 iters of Pinwheel No Rand:

1.0.64
.5856
.5863
.5852
.5857
AVG=.5857

1.0.63
.5876
.5854
.5850
.5874
AVG=.5863

Very strange. Try a longer test? 1000 iters, window maximized, Pinwheel no rand with Ring Growth = 3 and Canvas Size = 300:

1.0.64
17.779
17.784
17.770
17.762

1.0.63
17.780
17.780
17.797

1.0.61 (no reverse or per-ring draw at all)
17.789
17.776
17.793

Well, somehow it got faster...

mouse sensitivity

2005-08-06T23:52:00.000-07:00

Overall much better now that ranges are correctly accounted for.
Speed, zoom and hue all feel about the same.

Trackball is too twitchy at sensitivity = 100%, it feels best around 65%.
Maybe nominals should be lower? Try some other devices and average the results.

edit slider

2005-07-23T23:52:00.000-07:00

can be used in:
x-fader dialog, for pos
row dialog? for val
master dialog, for all except damping?

line width: DC pen optimization

2005-07-22T23:51:00.000-07:00

Don't re-select the DC pen when it's already selected: the GetStockObject and SelectObject calls are considerably more expensive than the test that avoids them.

Benchmark comparing wide-line version to original (default patch, total time spent in Draw function, 1000 calls) reveals that the wide-line version takes 0.06% longer:

old way:
1.3425
1.3459
1.3457
1.3393
1.3419
1.3411
1.3449
AVG = 1.3430

new way:
1.3433
1.3453
1.3428
1.3405
1.3467
1.3431
1.3456
AVG = 1.3439


#include "benchmark.h"
#define MAXSAMPS 1000
double  samp[MAXSAMPS];
int samps;
bool done;
void  CWhorldView::Draw(HDC dc)
{
Benchmark b;

...

if (samps < MAXSAMPS) {
    samp[samps++] = b.Elapsed();
} else {
    if (!done) {
        FILE *fp = fopen("test.txt", "w");
        double  sum = 0;
        for (int i = 0; i < samps; i++) {
            fprintf(fp, "%f\n", samp[i]);
            sum += samp[i];
        }
        fclose(fp);
        done = 1;
        CString s;
        s.Format("%f", sum);
        AfxMessageBox(s);
    }
}

another test, using Pinwheel but with # sides set to 20 and no LFO, 2500 samples

new 21.6328
old 21.5634
0.32% slower

again:
new 21.6226
old 21.5317
0.42% slower

line width

2005-07-22T23:49:00.000-07:00

creating a 1-pixel wide CPen and selecting it takes 85 micros (avg)
best case is around 8 micros, worst case is 850 to nearly 1000 (!)


m_Pen.DeleteObject();
m_Pen.CreatePen(PS_SOLID, 1, rp.Color);
SelectObject(dc, m_Pen);

setting DC pen color and selecting DC pen takes 2 micros (avg)
best case is 1 micro, worst case is 5

CPen way is anywhere from 2 to 1000 times slower
it's worth it to branch if you plan on doing a lot of 1-pixel wide lines

lotus cross

2005-07-20T23:48:00.000-07:00

lotus cross looks cool with these master settings:
speed 458
zoom 54
damping 51
tempo 20

Alt (menu) key

2005-07-18T23:47:00.000-07:00


BOOL CMainFrame::PreTranslateMessage(MSG* pMsg) 
{
    // in full screen mode, ignore the Menu key, so we don't go modal
    if (pMsg->message == WM_SYSKEYDOWN && pMsg->wParam == VK_MENU && m_IsFullScreen)
        return(TRUE);
    return CFrameWnd::PreTranslateMessage(pMsg);
}

zoom

2005-07-08T23:46:00.000-07:00

zoom can position origin off-canvas, resulting in no rings

in SetNormOrigin, must clamp:


    m_Origin.x = CLAMP(round(m_Size.cx * m_st.NormOrg.x), m_Canvas.left, m_Canvas.right - 1);
    m_Origin.y = CLAMP(round(m_Size.cy * m_st.NormOrg.y), m_Canvas.top, m_Canvas.bottom - 1);

Optimizing message order in a message map is useless

2005-07-05T23:46:00.000-07:00

MFC caches the most frequently used messages anyway, to avoid repeated table searching.

mouse damping

2005-07-02T23:44:00.000-07:00

Zone rings does damping from the timer hook: It repeatedly computes the difference between the origin and the mouse cursor, multiplies the difference by a normalized damping factor, and adds the result to the origin. The damping factor ranges from 0..1, 0 = maximum damping, 1 = no damping. At damping = 1, the result is always equal to the entire distance between origin and cursor, so the origin jumps immediately to the cursor position. At damping = 0, the origin would never move at all. Maybe the damping factor is kept above zero to prevent this.

mercedes lissajous

2005-06-25T23:42:00.000-07:00

mercedes looks good with these lissajous values:

delta .01
delta2 .02
phasedelta .0211
rad .25
origin .35
bit too fast though...

also nice colorspeed effect:
colorspeed 3.39 pulse wave amp = 2 freq = .05 pw = .333

lissajous origin

2005-06-25T23:40:00.000-07:00

constant phase difference: affects width of oval, difference of PI/2 gives a line


linear phase difference change:

x = sin(theta + phasetheta);
y = cos(theta)

and

x = sin(thetax);
y = cos(thetay);

are equivalent forms, assuming thetax has a different delta than thetay.  What's important is the *ratio* of theta to phasetheta (or thetax to thetay).  When the ratio is a simple fraction, the shape is simple and predictable; ratios that aren't simple fractions (e.g. .51) tend to produce elaborate net-like shapes.

trig phase difference change:

x = sin(theta)
y = cos(theta + sin(phasetheta));

Again, it's the ratio between the deltas that matters.  Incrementing theta by .1 and phasetheta by .01 will have the same effect as .2 and .02.

original:
    static double rad = .25;        
    double ox = sin(theta + sin(phasetheta) + i);
    double oy = cos(theta2);
    m_View->SetNormOrigin(ox * rad +.35, oy * rad +.35, FALSE);
    theta += .01;
    theta2 += .02;
    phasetheta += .0311;

slower and better:
    static double rad = .25;
    double ox = sin(theta + sin(phasetheta));
    double oy = cos(theta2);
    m_View->SetNormOrigin(ox * rad +.35, oy * rad +.35, FALSE);
    theta += .001;
    theta2 += .002;
    phasetheta += .00211;

demo crossfade

2005-04-30T22:27:00.000-07:00

randomize phase of parms whose frequency goes from zero to nonzero first, in A and B if freq AND amp are zero, set freq to 1e-6 so phase change will stick


for (int i = 0; i < ROWS; i++) {
    if (!m_CrossDlg.GetInfo(reverse ? CCrossDlg::SEL_B : CCrossDlg::SEL_A).m_Row[i].ModFreq
        && m_CrossDlg.GetInfo(reverse ? CCrossDlg::SEL_A : CCrossDlg::SEL_B).m_Row[i].ModFreq) {
        m_Osc[i].SetPhase(double(rand()) / RAND_MAX);
        printf("randomized %s\n", ParmInfo::GetRowData(i).Name);
    }
}

corrected ring deletion: cascade delete

2005-04-22T23:28:00.000-07:00

In previous versions, deleting a ring also deleted all subsequent rings in the list. This was only perceptible when the erroneously deleted rings happened to be visible. This situation occurs in certain demo patches which use a large star factor.


demo patches affected:

drastic change:
cross   Y   totally different; occasional nice moire but mostly too cluttered
lotus light Y   rings persist too long and spoil the drama
mercedes    Y   rings persist too long and spoil the drama

slight change:
pinwheel fab color  Y   "tunnel" state clears differently, but it's fine
pinwheel    Y   occasional very slight difference at edges
shimmer Y   occasional slight difference at edges
tentacles   Y   slight difference: occasional stray threads hang around

no change:
good2   N   no difference
kaleid  N   no difference
real pinwheel   N   no difference

"all at once" cascade:
        m_Ring.RemoveAt(CurPos);
        while (NextPos != NULL) {   // delete remaining rings
            CurPos = NextPos;
            m_Ring.GetNext(NextPos);
            m_Ring.RemoveAt(CurPos);
        }

gradual cascade, similar to original behavior, but smoother:
    POSITION DelPos = NULL
// main loop
        m_Ring.RemoveAt(CurPos);
        DelPos = NextPos;   // start cascade delete
// end of main loop
    if (DelPos != NULL) {
        RING&   rp = m_Ring.GetNext(DelPos);
        rp.Steps = 1e9; // mark ring for deletion
    }