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

maximize list control within playlist dialog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

uniform curvature with respect to number of sides

// 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

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

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

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

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

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

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

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

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

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

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

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

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.