Screen Pointer Update glitch

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
User avatar
Orion_
Captain Atari
Captain Atari
Posts: 455
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

Screen Pointer Update glitch

Post by Orion_ »

I'm coding a little demo and because my code is a bit slow, I use the triple buffering technique which allow to start writing my next screen even if the next screen to show up is not already starting to be drawn by the TV.
But, because of this I don't wait for the next VBL, I just set the new screen address at any time, and it appears to make some glitches sometimes, the screen seems garbled, I suppose this is because the new screen address is set at the wrong time (for example when the screen address is set during the next frame switch ?)
how can I avoid this ?
how can I detect when the screen is going to switch to the next frame, and wait for this before setting the new screen address ?

thank you.
My retro games shop including Atari ST/Falcon/Firebee games ! -- Free Atari games/demos/tools -- Free Falcon demos/tools
Atari Mega STe 4MB + SD2SCSI 1GB + NOVA ET4000 + Pico PSU + Gotek HxC // Atari STe 2MB // Atari Falcon 030 14MB
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2216
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Screen Pointer Update glitch

Post by Cyprian »

use VBL to ether change screen address or inform your routine about a new VBL.
Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
User avatar
npomarede
Atari God
Atari God
Posts: 1361
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Screen Pointer Update glitch

Post by npomarede »

Hi
this is not a very known fact, but video address on STF is in fact reloaded at HBL 310 (3 HBL before next VBL starts at 50 Hz), not at start of VBL. So, if you set your new screen address as soon as the VBL starts, it's too late and this new address will in fact be used to display the next frame at VBL 'n+1', not the current frame at VBL 'n'.

So,depending on whether your program sets the new address before of after HBL 310, then it will be taken or not into account. If it's not taken into account, you will display the same screen a 2nd time and if you already start to draw on this screen then the partial result will be displayed.

As cyprian told, always set your next screen into VBL (to handle the rotation between your 3 addresses of triple buffering), but take into account that when doing so the new address will be used for the next displayed frame.

Nicolas
mikro
Hardware Guru
Hardware Guru
Posts: 2365
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Screen Pointer Update glitch

Post by mikro »

Orion_ wrote:But, because of this I don't wait for the next VBL, I just set the new screen address at any time.
Well, this is exactly the use case why one wants to use triple buffer, no need for further tricks. ;) So triple buffer -- good, writing screen address anytime -- bad.

Double buffer works like this:
logical screen pointer <-- here you write
physical screen pointer <-- this is shown
...
now you're done with writing, you call Vsync() and swap the pointers

Triple buffer works like this:
logical screen pointer no.1 <-- here you write
logical screen pointer no.2 <-- this is unused right now
physical screen pointer <-- this is shown
...
now you're done with writing, you do not call Vsync but just exchange logical pointer no.1 & no.2. So where do set your screen address you ask? In VBL. Of course, this assumes that your effect always takes more than one VBL. In practice it's actually quite easy because the exchange is actually a rotation:

lea screen_adr1,a0
move.l (a0),d0
move.l 4(a0),(a0)+
move.l 4(a0),(a0)+
move.l d0,(a0)

and the VBL routine looks like this:

move.l screen_adr1,d0
cmp.l .var,d0
beq.s .noset
move.l d0,.var

.set:
move.l d0,d1
lsr.w #8,d0
move.l d0,$ffff8200.w
move.b d1,$ffff820d.w

.noset:
...

screen_adr1: ds.l 1 ;screen address 1
screen_adr: ;WORK ADDRESS!
screen_adr2: ds.l 1 ;screen address 2
screen_adr3: ds.l 1 ;screen address 3

(courtesy of DHS demosystem)
User avatar
Orion_
Captain Atari
Captain Atari
Posts: 455
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

Re: Screen Pointer Update glitch

Post by Orion_ »

I tried this (I'm working on ST)
but as npomarede mentioned, and as I already noticed, when setting the new screen address in the VBL interrupts, the new screen address seems to be valid only for the next frame, and not the one that will be drawn at this VBL.
even setting the address in the VBL, I had flickering on one of my effects that was taking around 1.25 VBL to complete, I don't quite understand why, I solved it using 4 buffers swap instead of 3 .. (brute force way of solving things, but well ...)
My retro games shop including Atari ST/Falcon/Firebee games ! -- Free Atari games/demos/tools -- Free Falcon demos/tools
Atari Mega STe 4MB + SD2SCSI 1GB + NOVA ET4000 + Pico PSU + Gotek HxC // Atari STe 2MB // Atari Falcon 030 14MB
User avatar
npomarede
Atari God
Atari God
Posts: 1361
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Screen Pointer Update glitch

Post by npomarede »

Triple buffer should be enough, but if your effect sometimes takes 1.25 VBL or more, then you must also handle the fact that you should not "rotate" the 3 buffers until you really finished drawing a complete frame.
Which means that sometimes you must display the same buffer twice on screen ; else, sooner or later, you will end up writing in the buffer you're displaying at the same time.
leonard
Moderator
Moderator
Posts: 665
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: Screen Pointer Update glitch

Post by leonard »

And if your frame rate has huge amplitude, you could generalize the algorithm to <n screen buffering> as in famous European demo 3D screen. I think they use 8 screens if I remind well.
Leonard/OXYGENE.
orionfuzion
Atari User
Atari User
Posts: 37
Joined: Fri Nov 11, 2016 1:57 pm
Location: Paris, France
Contact:

Re: Screen Pointer Update glitch

Post by orionfuzion »

Hi guys,

I'm resurrecting this old thread because I would like to understand when the video base address is reloaded by the VIDEL on Falcon.

It is explained in this thread that the video base address is reloaded at HBL 310 on ST (3 HBL before the next VBL, at 50 Hz).
Therefore, if the video base address ($ff820[1,3,d]) is modified just after a VSYNC (after the VBL has started), the change will not be effective until the next VBL.

How does this work on Falcon? When is the video base address reloaded? Will I get the same behavior as on ST if I use double-buffering and I flip the screen right after a VSYNC on Falcon? (The assumption being that the VIDEL is configured in ST backwards compatible mode).

Sorry to ask such a lame question, but I cannot test by myself, as I don't have a Falcon machine :-)

-- Orion / Reps
Post Reply

Return to “Coding”