|Re: [hatari-devel] Hatari screen test|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 5/27/20 11:34 AM, Nicolas Pomarède wrote:
Le 26/05/2020 à 18:43, Thomas Huth a écrit :
I've run now the test in a loop for 1000 times, and I never got a test
failure, even after decreasing the sleep time from 0.2 to 0.1. Are you
able to get a failure when running the run_test.sh script?
But well, if you feel more confident that way, feel free to change the
script to use the debugger instead the command fifo.
regarding these "synchronisation" problems using sleep (whose results
can sometimes vary depending on setups), couldn't this be handled with
some new natfeats functions specific to these regression tests ?
That's a good idea, it has least overhead, and
test program retains all control of testing.
For example natfeats 'save screenshot' would save current screen content
as a png, and you could call it from a fixed hbl position in the
fullscreen code, which would ensure you always capture a complete screen.
So, the test could be :
- natfeats "screenshot filename.png"
Being able to give a screenshot name is a good,
but I think I'll return an error if there are any
path separators given. Emulated program should
not be able to dictate on which directories it
- natfeats "print 'fullscreen test complete'"
- natfeats "quit hatari"
These are NF_STDERR & NF_EXIT natfeats calls.
This way, no more sync problem or sleep to adjust, you can even run
hatari in fast forward mode during the test and it will work.
They already can run in fast forward mode, and looking at Thomas'
run_test.sh, it already does.
I.e. 0.2s (and now 0.1s) wait can actually cover
a much larger range of VBLs, than what I thought
in my earlier mail...