|Re: [hatari-devel] Hatari & physbase/$ff820x (Videl)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 21/01/2014 18:41, Douglas Little a écrit :
I suppose this is useful in a way, because it exaggerates tearing that
would exist on real HW, but be either invisible or much less visible, so
more likely to get noticed and fixed. But OTOH, if this is used to
optimize away dead time in a game loop, it requires special handling by
the programmer to treat Hatari differently.
If anyone is able to correct or confirm the above, I would appreciate
I haven't look at the videl code, but I guess it the same as the STF/STE
In that case, destination (emulated) screen is built one raster at a
time ; on every HBL, we convert 1 line pointed by the video address to
the internal bitmap image used by SDL.
As you say, depending on where the cpu is currently writing in the
"video ram" allocated to the screen, tearing may or may not happen, with
possibly different result than on real HW (especially if the cpu if
writing in RAM ahead of the video beam or not).
It's kinda hard to fix for now, ideal solution would be to check on
every write to RAM if the RAM location overlaps with the current beam
position, to simulate a screen that is rendered pixels by pixels, as if
an electron beam was also doing it in Hatari (when current write
location doesn't overlap with the screen memory, you can speed up things
by rendering a whole line at once).
Some STF demos (GEN4 Demo by ULM for example) show a tearing in the
middle of the screen because of this, as it uses a single video buffer
and write in it at the same time that the shifter is reading it.