|Re: [hatari-devel] fixing errors reported by GCC 10 -fanalyzer
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 13/05/2020 à 20:17, Eero Tamminen a écrit :
On 5/13/20 7:59 PM, Nicolas Pomarède wrote:
it depends on the case, most of the time interpreting the results
means looking at the screen and checking if some pixels are aligned
or in different colors (depending on which video test is performed),
which is not usable with natfeats.
We can always add NatFeats call to request pixel
color(s) to be checked at specified screen
position(s), and output PASS or FAIL string
depending on whether there's a match.
There could be new "NF_TEST" NatFeats call for
doing emulator tests. One of the call sub-IDs
would do this particular test, e.g. using
following stack signature:
ScreenColorMatch(uint16_t x, uint16_t y, uint16_t pixels, color_t *colors);
This would be really too complicated to check pixels at specified
position, the pattern can be changing, but the result could be still
well, at least that's how some my own test work : it's easy for a human
to look at the screen and see if it works or not, it would be
overkill/more complicated to write a program that would compare
different screenshot or look for a pattern.
There could be other ways to test for overscan, for example check the
value of the video counter after doing some frequency switches, but
that's not how I did it for my own use.
Maybe someone will feel like writing such program (even if in the case
of the overscan, it's someone much faster to run 3 or 4 specific demo
and see if they work ("Closure" by Sync can be a good candidate)