flickering when writing to video memory during VBL

[jotd]

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?

[mcgeezer]

Originally Posted by jotd

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.

[meynaf]

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.

[jotd]

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.

[meynaf]

Originally Posted by jotd

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.

Originally Posted by jotd

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.

[Rotareneg]

Originally Posted by meynaf

Frame flipping is possible under OS. But it's quite tricky.

Doesn't seem so bad: http://amigadev.elowar.com/read/ADCD.../node0346.html

[meynaf]

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.

[Photon]

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.

[mcgeezer]

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by mcgeezer

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.

[jotd]

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.

[mcgeezer]

Originally Posted by meynaf

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.

Originally Posted by meynaf

who told about the blitter ? It's of course about copying from fast to chip with the cpu.

you did!

[meynaf]

Originally Posted by mcgeezer

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".

[mcgeezer]

Originally Posted by meynaf

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.