So, I spent a considerable amount of time rewriting the engine so that animation frames are stored from zero instead of one in the Frames container.
It's fixed a couple of issues already.
And now I know why!!! It appears that I made that change so that it was easier to react to the frame selector trackbar on the animation toolbar.
By starting animation frames at [1] I can set the frame in view by referencing the trackbar's position directly:
Frames[tbFrames-&gt;Position]
instead of
Frames[tbFrames-&gt;Position - 1]
Because the position parameter starts at 1.
I could set the range of the trackbar (using its min and max properties) from 0 to max frame - 1.
However, there's a tooltip that displays above the trackbar that shows the position and this would show zero for the first frame - which is not particularly user-friendly.
I think it's possible to override this (or I could possibly subclass the TTrackBar class), but it appears that I chose the easy option instead!

So, I spent a considerable amount of time rewriting the engine so that animation frames are stored from zero instead of one in the Frames container.

It's fixed a couple of issues already.

And now I know why!!! It appears that I made that change so that it was easier to react to the frame selector trackbar on the animation toolbar.

By starting animation frames at \[1\] I can set the frame in view by referencing the trackbar's position directly:

Frames\[tbFrames-&gt;Position\]

instead of

Frames\[tbFrames-&gt;Position - 1\]

Because the position parameter starts at 1.

I could set the range of the trackbar (using its *min* and *max* properties) from *0* to *max frame - 1*.

However, there's a tooltip that displays above the trackbar that shows the position and this would show zero for the first frame - which is not particularly user-friendly.

I think it's possible to override this (or I could possibly subclass the TTrackBar class), but it appears that I chose the *easy* option instead!

Frames[0], now I understand thee