Re: [hatari-devel] vsync & video base address setting

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 23/04/2023 à 17:40, Miro Kropáček a écrit :

> What about the other problem I've mentioned - i.e. the frame will be 
> rendered *exactly* at the line 309.9, I set $ffff8201 but then the 
> reload happens and $ffff8203/0d will be ignored? Is it possible to 
> happen on the ST? (it's not rhetorical question, Jo Even could observe 
> the very same thing when developing his game "L'Abbaye des Morts" on 
> Falcon before he started waiting for vbl - the screen would render 99 
> times okay and then suddenly jump on the 100th time).

Ijor mentionned this once in atari-forum and he told that from line 310 
to 313 (end of vbl / start of next one) the video counter in 
ff8205/07/09 will be constantly reloaded with content from ff8201/03/0d. 
so even if the write overlaps line 310 it shouldn't be a problem.

>     this can be a problem because you can't write to the 2nd buffer as it
>     will be displayed next. but you can't write to the 1st buffer either as
>     it's possibly being displayed for 1 extra VBL.
>     Easiest solution : use triple buffering to ensure you always have 3
>     buffers :
>
> Funny you mention it, I'm testing my triple buffer solution in Hatari in 
> ST/E mode to make sure I got it right (Falcon mode is not precise so I 
> can't rely on it) but wanted to make sure that I get double buffering 
> right first.
>
> I'm really surprised how difficult this is on the ST, I thought that 
> it's just me being dumb. I wonder how it is solved in games which were 
> typically not 1VBL... maybe they got a constant time per frame?

yes if you want to avoid triple buffering you need to know in advance 
how many vbl you need to render one frame and set new screen address at 
vbl n-1 ; either you use a constant number of vbl for each frame or you 
need to have a way to measure how many percents of the frame you already 
rendered on each vbl and trigger a screen address change when needed.


Nicolas