VBI and software sprites.

[Tezz]

Hi all,

 

I have a thought on some of the software sprite routines I have been working on ... although maybe it is not possible.

 

The major difficulty in writing games on the A8 is of course colours. We have all discussed many times the use of DLIs, PM overlays/multiplexing etc. etc. some solutions are too taxing to use in gameplay. With the software sprite routine, vbi page filpping with double buffering is used I was wondering that maybe a backdrop with it's own pallette could be alternated between the software sprites updating with (their own pallete) during the vbi. I guess there would be a noticable flicker or glimmer but a least I can use an extended pallette. The programs I'm working on all use a narrow playfield and not all of the scanlines are used for the game area. There is no scrolling or anything much else for the code (CPU) to process during the game play, apart from the simple 2-3 channel music.

 

There has been similar ideas used on routines before like the flickering mode used in gemdrop. I've never looked at it running on the hardware but this didn't look good at all in AtariWin though.

 

Is it a possibility or would I be wasting my time attempting this?

[Shawn Jefferson]

There has been similar ideas used on routines before like the flickering mode used in gemdrop. I've never looked at it running on the hardware but this didn't look good at all in AtariWin though.

 

It looks much better on real hardware. You are going to have some visible flickering no matter how you approach page flipping for more colors. The SIFE mode does a pretty good job of minimizing the flicker though.

[Tezz]

Thanks for that, sounds worth persuing just to see the results I guess.

I suppose that in reality page flipping would need to be twice the speed of the VBI period to appear as a static display. although, I remember a demo by Magnus I think 89/90 where the planet from Mirax force (i think) had been ripped and a hi res sinus scroller was overlayed on the top of it. Can't remember the name of it but on the real hardware there was just the tinyest of flicker almost none. I will have to find that and see it in emulation.

[Heaven/TQA]

i am not a fan of interlacing in games... but maybe with clever using of mode/colours...

[Sheddy]

In my experience, for the best results with interlace using emulators, set your monitor refresh speed to the same as the Atari, ie 60Hz for an NTSC Atari. Also make sure the vertical sync option is turned on in the emulator.

 

When interlacing if you can also interleave the scan-lines and/or dither the pixels horizontally the results are much easier on the eye. Without breaking up the image in some way, large areas of colour appear to flicker worse otherwise (Unfortunately I haven't enough cycles left over to use these techniques effectively on my game)

 

Keeping the luminances similar on overlapping areas also helps minimise flicker.

 

For some really neat examples of interlacing check out any HIP/TIP pics, or there are some example pictures given with the Lepix program (see recent thread on the 8-bit forum). You can pause an emulator to see what it's doing on the different interlaced screens.

[Tezz]

Thanks Chris, You're right, I've not attempted to set the sync rate of the monitor manually to the same hz rate. It didn't actualy occur to me! I assumed that the emulation was cycle exact or something and was limited in it's display or real emulation of these types of acurate display interrupts.

 

I'm not too sure if the correct term for what I am doing is interlacing like in the clever TIP and HIP modes. Really I was just thinking of a fast flip between the background and software sprites during each alternate VBI. I've looked at a few demos seemingly displaying the technique one of which displays sections of the loading picture from Draconus bouncing around the screen with alternate pallettes. It flickers terribly though in AtariWin. I'll have to look at this running with the hz rate set correctly and also with the real hardware which I will hook up later on.

 

Maybe there are examples of this code around some place? I know it's been attempted a lot. Maybe I will waste time trying to re-invent the wheel.

[Sheddy]

Thanks Chris, You're right, I've not attempted to set the sync rate of the monitor manually to the same hz rate. It didn't actualy occur to me! I assumed that the emulation was cycle exact or something and was limited in it's display or real emulation of these types of acurate display interrupts.  

 

Yeah, seems strange to start with, but we shouldn't blame the emulator. It's happily doing the right thing at 50Hz for a PAL atari or 60 Hz for an NTSC one. However your PC video card and monitor is probably set up nice for that ultra smooth game of Doom3, and running at 85Hz+ !

[Sheddy]

I'm not too sure if the correct term for what I am doing is interlacing like in the clever TIP and HIP modes. Really I was just thinking of a fast flip between the background and software sprites during each alternate VBI. I've looked at a few demos seemingly displaying the technique one of which displays sections of the loading picture from Draconus bouncing around the screen with alternate pallettes. It flickers terribly though in AtariWin. I'll have to look at this running with the hz rate set correctly and also with the real hardware which I will hook up later on.

 

Maybe there are examples of this code around some place? I know it's been attempted a lot. Maybe I will waste time trying to re-invent the wheel.

 

What you're wanting to do is still called interlacing

A TV only displays a complete picture every 30th of a second (NTSC- a 25th for PAL). The 1st 60th of a second it only displays the odd scan lines, then the next 60th it displays the even scan lines - these two fields "interlace" each other to give a complete frame every 30th of a second.

 

The code to swap between two different screens is not too mind bending when you get down to it:

 

One way is to have 2 display lists that point to the two different screens. But instead of having the jump at the end of each display list pointing back to itself, point it to the other display list! Make either of the display lists active, and they will happily swap between each other every VBI without you having to get involved at all!

 

That is a simplistic example because it doesn't deal with any palette swapping, double buffering, or cope well if your code drops a frame ocassionally, but it just shows how neat display lists are!

 

So you can do pretty much the same thing yourself in the VBI.

One of the easiest ways to alternate between things is to do an EOR

EG

 

lda whichdlist

eor #1

sta whichdlist

beq dlist2

dlist1

...code to set dlist1 and palette colours

jmp out

dlist2

...code to set dlist2 and palette colours

out

 

the whichdlist variable alternates between 0 and 1 every time eor #1 is done.

 

That's all probably too simplistic for what you're wanting, but it's a start

[Tezz]

Thanks again Chris that's a really helpful explanation. I'll get to coding to see if/what can be acheived.

[Heaven/TQA]

or next step could be

lda #<dlist

sta dlistv

lda #>dlist

sta dlistv+1

...

vbl lda dlist+1

eor #1

sta dlist+1

...

 

f.e. dlist1 stored at $9000

dlist2 stored at $9100

 

is more clever imho...

 

 

but for software sprites i would go for double buffering or triple buffering...