English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 14 September 2019, 01:10   #1
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,251
flickering when writing to video memory during VBL

Hi,

For my Oric remakes project (C + assembly, and NO SDL DAMNIT!), I'm using VBL interrupt to refresh my screen.

It's working properly, fast and all (thanks to an optimized asm routine) but there's some flickering.

I'm directly poking into screen rastport planes.

How can I fix it ? is double buffering the only way?
jotd is offline  
Old 14 September 2019, 08:59   #2
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,483
Quote:
Originally Posted by jotd View Post
Hi,

For my Oric remakes project (C + assembly, and NO SDL DAMNIT!), I'm using VBL interrupt to refresh my screen.

It's working properly, fast and all (thanks to an optimized asm routine) but there's some flickering.

I'm directly poking into screen rastport planes.

How can I fix it ? is double buffering the only way?
The proper way is to double buffer.

Or, do all the updates early enough that they don’t interfere with the display.
mcgeezer is offline  
Old 14 September 2019, 10:30   #3
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,597
There are three ways to do that :
1. Frame flipping (aka double buffer).
2. Using a back-buffer (blit somewhere in fastmem, then copy back very fast).
3. Be fast enough so the beam doesn't catch up with your update.
meynaf is online now  
Old 14 September 2019, 13:10   #4
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,251
thanks for this information. Frame flipping looks cool. I'm using an intuition screen so I guess that I'll have to forget it...

I'm not targetting stock A500 or A1200 ATM. With a fast enough CPU the flickering isn't visible, yes. But it's WinUAE. With "A500/A1200 speed", the screen flashes like crazy (but at least refresh is fast enough)

My screen refresh first clears the screen, then performs "OR" with pre-computed patterns to fill it up (Oric display has 6 bits per pixel so I need to use OR). If I don't clear the screen, I have to AND with pre-computed tables too. Well, maybe 1 read to register + 1 OR and 1 AND is better than clearing first then just using OR.
jotd is offline  
Old 14 September 2019, 13:53   #5
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,597
Quote:
Originally Posted by jotd View Post
thanks for this information. Frame flipping looks cool. I'm using an intuition screen so I guess that I'll have to forget it...
Frame flipping is possible under OS. But it's quite tricky.


Quote:
Originally Posted by jotd View Post
My screen refresh first clears the screen, then performs "OR" with pre-computed patterns to fill it up (Oric display has 6 bits per pixel so I need to use OR). If I don't clear the screen, I have to AND with pre-computed tables too. Well, maybe 1 read to register + 1 OR and 1 AND is better than clearing first then just using OR.
I know how Oric display works. It's not at all straightforward to convert.
The best solution would be to completely rewrite the graphic routines so that original screen format is no longer used.

Alternatively, you may want to prepare 48 pixels in registers, then write them at once to avoid reading chipmem. But it may need just too much space.

However as you don't target vanilla machines, i guess there is some fastmem available ?
If so, you may end up faster by preparing the screen in fastmem, then copying it to chip.
meynaf is online now  
Old 14 September 2019, 17:05   #6
Rotareneg
Registered User

 
Join Date: Sep 2017
Location: Kansas, USA
Posts: 99
Quote:
Originally Posted by meynaf View Post
Frame flipping is possible under OS. But it's quite tricky.
Doesn't seem so bad: http://amigadev.elowar.com/read/ADCD.../node0346.html
Rotareneg is offline  
Old 15 September 2019, 10:13   #7
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,597
Apparently the current method is to clear the whole screen, then render it, right ?

Another idea could be to clear one line, then do it, clear next line, do it, etc.
If the overall process is faster than the beam, there would be no glitches anymore.
Else, glitches should still be a lot smaller than whole screen flickering.
meynaf is online now  
Old 27 September 2019, 13:58   #8
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,771
If there's a way to set the top line of display higher than 0 using the OS, then you could double-buffer by creating a bitmap twice as high as the screen, and toggle "startY" between 0 and 256, drawing into the high part while showing the low.

Note that if rendering a frame can take more than 1 vblank, you should render outside the vblank and increase some frame counter, and in the vblank only swap if the counter has increased. Interrupts should in general just interrupt the OS briefly, not run mainline code. Interrupting for too long (let's say for more than 5ms or 25%, which is a lot) may prevent necessary tasks from running, which sort of ruins the idea of multitasking.

Last edited by Photon; 30 September 2019 at 14:44.
Photon is offline  
Old 27 September 2019, 19:34   #9
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,483
Quote:
Originally Posted by meynaf View Post
There are three ways to do that :
1. Frame flipping (aka double buffer).
2. Using a back-buffer (blit somewhere in fastmem, then copy back very fast).
3. Be fast enough so the beam doesn't catch up with your update.
For option 2 i thought the blitter couldn’t access fastram?

Unless i mis-interpreted this.
mcgeezer is offline  
Old 27 September 2019, 21:17   #10
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,597
Quote:
Originally Posted by mcgeezer View Post
For option 2 i thought the blitter couldn’t access fastram?

Unless i mis-interpreted this.
Who told about the blitter ? It's of course about copying from fast to chip with the cpu.
meynaf is online now  
Old 27 September 2019, 22:17   #11
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,251
Meynaf I know you know the Oric. I'm using pre-computed shifted tables already. At least it avoids shifting, but there are still 3 planes to alter.

I'm doing some ORing so if I do that in fastmem, it will be faster/as fast to perform the ORs there, then in the end copy the data to chipmem

Instead of clearing a whole line, I'm writing a LONG instead of a WORD, with LSW set to 0. So one write to set data and clear the next cells, ready for more ORing.

I'm trying to implement a "draw only changes" option currently. I'm targetting 68020 with fastmem. Ideally I'd like that to run on A1200/020 nofast, maybe it'll work with "draw only changes". And will also depend on the game.
jotd is offline  
Old 27 September 2019, 23:40   #12
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,483
Quote:
Originally Posted by meynaf View Post
there are three ways to do that :
1. Frame flipping (aka double buffer).
2. Using a back-buffer (blit somewhere in fastmem, then copy back very fast).
3. Be fast enough so the beam doesn't catch up with your update.
Quote:
Originally Posted by meynaf View Post
who told about the blitter ? It's of course about copying from fast to chip with the cpu.
you did!
mcgeezer is offline  
Old 28 September 2019, 10:28   #13
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,597
Quote:
Originally Posted by mcgeezer View Post
you did!
Nope, I did not. I wrote "blit", which means bit-block transfer and is an operation that can be done with cpu as well. I did not write "blitter".
meynaf is online now  
Old 28 September 2019, 10:49   #14
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,483
Quote:
Originally Posted by meynaf View Post
Nope, I did not. I wrote "blit", which means bit-block transfer and is an operation that can be done with cpu as well. I did not write "blitter".
No. Blit here in Amiga terms implies (at least for me) Block Image Transfer using the Blitter.
But we are splitting hairs here and its fine, you just meant copy the data.
mcgeezer is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Memory watch point on blitter writing to memory? mcgeezer support.WinUAE 12 26 June 2019 23:12
$120+S&H for video toaster, time-base-corrector TBC, memory and modem OceanPark2 MarketPlace 0 12 July 2007 22:36
A4000 memory and video output polbit support.Hardware 11 19 February 2007 16:00
Chip memory, VGA output, IPF writing Hideki support.Hardware 10 09 January 2007 16:18
Linking VBL interrups under the system Photon Coders. General 1 09 March 2006 17:51

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09892 seconds with 15 queries