I redraw always every frame.
The fps in the demonstration video of foxblock are at most 40.
Then there is either a bug in your code (you don't update your internal screen pointers from one you get form SDL_Flip() ), or old version of SDL that had some bugs with this.
But I still don't see how I can get flicker with triple buffers, even with vsync off. If I'm drawing on buffer N, then the display should be using either buffer N-2 %3 or buffer N-1 %3 (if vsync is on it should always be N-1 %3, otherwise it can be a mix between N-2 %3 and N-1 %3). Right?
It's not hard to think of such case:
- Your timing code takes some time reference, let's say it's 0ms
- Kernel had some work to do (write out to SD or whatever), your game has no control for 30ms
- You get control back and call SDL_Flip() to send a buffer you got ready before kernel became busy, pointer to buffer  with that frame makes it way to hardware. At the same time LCD/dispc has just started redrawing buffer  so hardware is not using your new pointer, puts it into a shadow register for next frame. SDL_Flip() gives you a pointer to buffer .
- Your timing code sees 30ms passed, so it needs to do another frame, you do it (let's say the scene is simple and takes < 1ms), call SDL_Flip() and get a pointer to .
- Now is let's say your timing code calculates 30-16 = 14, which means it needs to sleep 2ms to limit to 60fps, let's say it does that but LCD update will only progress for maybe 30% of screen over all this, and you start redrawing  which it's still displaying..
I don't know if your timing code is like that but maybe that can give you an idea how things like that happen.
Of course if someone wants to do a properly timed sample that demonstrates that I'm wrong and it's SDL's fault, please go ahead, but with such severe problems as in Ziz's video I'm pretty sure it's a problem in his code (or SDL version there is old).