rowett wrote:Yes I did debate whether to tie the step back function to the current step size. It's trivial to do but would certainly warrant increasing the snapshot interval. Again, let me know what you'd prefer. Larger snapshot interval = slower step back performance.
I suspect you've probably played around with the possibilities and found a pretty good snapshot interval, so I won't try to second-guess that. However, it's definitely a corollary of Murphy's Law that the backwards step that I want to see will tend to be one step farther than the viewer allows!
In that case, I wouldn't mind too much if the backward step were kind of slow. I'd still rather be able to hit "b" and wait for a second or two -- maybe with a "Recalculating..." type message if the backtracking will take too long. One "b" keystroke and an under-five-second delay would still be a huge improvement over hitting Reset and having to manually run forward to the generation I want, all over again.
My initial reaction is that the step-back function
should be tied to the step size. If I'm running at x30, the thing that I barely missed that I want to go back and see will be at T-30, not T-1.
That maybe argues for automatically setting the snapshot distance to some multiple of the step size. 32 times step size might be too much, though, since you'd have to run over 600 ticks from the T-(30*32) snapshot to get to T-30. Backtracking would be slow, then faster, then slow again when the T-(30*64) snapshot has to be used.
-------------------------
I definitely see the problem with taking too many snapshots and eating up memory unnecessarily, though, especially for longer-running patterns. Might it make sense to keep snapshots taken at increasing intervals -- T=0, T=32, T=96, T=224, T=480, etc.? And/or just make new snapshots whenever they're needed?
If you generate snapshots only on demand, then the first time you run backward and forward over a given time interval, the "b" key might be a little slow -- maybe it even has to go back and run the pattern from near the beginning to get a good snapshot starting point.
But after that, it would be really fast to run forward and backward in the interesting time slice. I do this kind of thing in Golly a lot, using Space and Ctrl+Z. Most interesting reactions probably take less than 64 ticks, so the current two snapshots might well be enough.
Another idea might be to only bother generating those backtracking snapshots during idle time when a pattern is paused. When I'm looking at a reaction, I tend to spend a lot of time panning or zooming or just looking at the viewer -- there would usually be plenty of idle cycles, during which the viewer could go back and calculate the T-64 and T-32 snapshots, hopefully without becoming noticeably unresponsive.
-- Or is that too much of a headache for Javascript? It wouldn't need to be multi-threaded or anything -- would just have to obsessively check for input while running a copy of the initial pattern back up to T-64. Maybe that part of the backtracking system ought to be disabled for T>10,000 or something, but it seems as if it would work well for reasonable sized time slices...?
rowett wrote:The "b" hotkey doesn't currently deal very well with waypoints. In a future build it will more closely implement the SPACE behaviour (albeit backwards).
My only suggestion there is that the space bar doesn't really need to visit every time interval inside a PAUSE. Seems as if it might as well jump straight to the next actual change -- i.e., the next waypoint after the PAUSE. Otherwise, even a short pause in a waypoint script will near-disable the spacebar for a long time, with just the slow creep of the T progress bar to show that anything is happening.
P.S. Just noticed the undocumented "b" hotkey in build 154, which shows 16x16 tiles currently in use. Did that move to another key?
