Another video capturing problem about beebjit HOT 3 OPEN

Interesting. This command line uses -fast without -accurate, which uses a different paint path.

I think this might be a simple-ish fix: in video_paint_timer_fired(), if you move the line "p_video->has_paint_timer_triggered = 1;" outside of all "if" statements, does that work without any side-effects?

from beebjit.

(Also, it should in theory be possible to remove the -cycles command line parameter and rely on the -exit-on-max-frames to handle the exit.)

from beebjit.

I think this might be a simple-ish fix: in video_paint_timer_fired(), if you move the line "p_video->has_paint_timer_triggered = 1;" outside of all "if" statements, does that work without any side-effects?

It fixes my reduced testcase and my original testcase and it doesn't break BBCMicroBot's testsuite (though that's not all that thorough - for example, it doesn't currently test "clapperboard" mode, so didn't catch this breakage).

It looks like it probably doesn't make a difference exactly where this line gets moved to, but FWIW this is the exact patch I tested with:

diff --git a/video.c b/video.c
index 01c7d7e6..0245b052 100644
--- a/video.c
+++ b/video.c
@@ -1259,12 +1259,12 @@ video_paint_timer_fired(void* p) {
                timing_get_total_timer_ticks(p_video->p_timing));
   }
 
+  p_video->has_paint_timer_triggered = 1;
   if (!p_video->externally_clocked) {
     /* For accurate mode, this triggers the start of painting, and paint will
      * occur at the usual 50Hz virtual time.
      */
     if (timing_timer_is_running(p_timing, timer_id)) {
-      p_video->has_paint_timer_triggered = 1;
       video_wall_time_vsync_hit(p_video);
       /* A bunch of unconsumed framing changes will have built up. Clear the
        * the flag so the screen isn't immediately cleared after the first paint.

from beebjit.