Double buffering query

[IndyUK]

Hi Folks,

I need some clarification please.

I'm testing double buffering using the two typical start addresses (&C000 & &4000). I've got all this setup and I can toggle between the two screens fine. However, I'm a bit puzzled about whether the switching between one and the other is actually working as I expect. Correct me if I'm wrong but, my thinking is that when I switch from one screen to the other (btw I'm using firmware to do this) that the switch should be instant. At first glance it seems this is the case and it's flickering between very quickly. But, upon closer inspection I don't think it is happening the way I think it should be.

As a test, I put a breakpoint at my loop end and noticed that the screen switching was not happening until at least 20-25 loop iterations. My two screens are very simple to distinguish - one is Red background and the other Blue. I set this up at the very beginning of the program. To me it seems the toggle is happening so fast the actual hardware isn't reacting quick enough and it's only around 20us later that things catch-up and the screen finally swaps.

If I add a Call &BD19 then it behaves as expected, which suggest that it might be a hardware issue. Does anyone have any thoughts on this?

Thanks

[McArti0]

the switch should be instant.

no. switch is only on start draw screen by CRTC chip. Register 12,13 is used exacly then.

[IndyUK]

switch is only on start draw screen by CRTC chip

If this is the case, does this mean that the program execution will continue even though the switch has yet to happen?

[andycadley]

Yes, your program won't wait for the CRTC to reload it's internal settings (that happens at frame flyback, which is precisely what CALL &BD19 is waiting for).

[McArti0]

You write &10 or &30 to register R12 in CRTC , only.

[abalore]

Hello,

you need to synchronize the switching with the vertical blanking interval, if not, you simply switch in random times and you get both screens mixed.

Calling &BD19 is a way to do it, but very inefficient. You better take a look at this page: https://www.cpcwiki.eu/index.php/Synchronising_with_the_CRTC_and_display

[IndyUK]

Yes, your program won't wait for the CRTC to reload it's internal settings (that happens at frame flyback, which is precisely what CALL &BD19 is waiting for).

Now that explains why my clearing of the back buffer was leaving sprite trails behind. The video update and buffer flip were not in sync. The amount of time I spent trying to work this out is a bit soul destroying. Shame this wasn't mentioned in the firmware manual anywhere. Thanks for clarifying though.

You better take a look at this page: https://www.cpcwiki.eu/index.php/Synchronising_with_the_CRTC_and_display

I will look into this. If this method gives a better frame rate than calling &BD19, then I may use it.


To be honest, I'm on a experimental journey of wanting to experience what it was like to develop games before the advance techniques were discovered i.e. use the firmware 100% and see what could be acheived if some thought was put in. To be fair, the programmers back then wouldn't have had the luxury of time so maybe games using the firmware ended up poor quality for that reason.

Thank you both for your help.

[lmimmfn]

Hello,

you need to synchronize the switching with the vertical blanking interval, if not, you simply switch in random times and you get both screens mixed.

Calling &BD19 is a way to do it, but very inefficient. You better take a look at this page: https://www.cpcwiki.eu/index.php/Synchronising_with_the_CRTC_and_display

I'm curious, I realise from the link, code etc. and solution that it needs to wait for vsync, but why is &bd19 inefficient?

[andycadley]

There's lots of overhead when calling firmware routines, because it has to maintain ROM state etc. For a very short routine like checking for flyback, there's probably more overhead than useful code execution.

[McArti0]

10 EVERY 2,3 GOSUB 100
15 EVERY 2,2 GOSUB 200
20 REM MAIN LOOP
30 GOTO 20
100 OUT&BC00,12:OUT&BD00,&20
110 RETURN
200 OUT&BC00,12:OUT&BD00,&30
210 RETURN

This code is efficient ...

[IndyUK]

Hi Folks,

Just wanted to update you on my journey. I've picked up quite a bit of knowledge about double buffering and so wanted to share a quick video of what I managed to put together thanks to you all.

I think it's roughly running at 25fps (~38us per frame) but I'd say could be playable if made into a game. There's no sound so don't know how much overhead that would add to the fps. The code needs tidying up as there's a few duplicate blocks but, this is just a bit of learning so not really an issue.

Anyway, hope you all like it.

[arnolde]

That looks nice, congrats.
Don't worry too much about the music. If you use one of Targhan's players, f.i. AKG, you need only about 30 scanlines per frame, but there are even faster ones, too (with less functionality and effects, though)

[IndyUK]

That looks nice, congrats.

Thanks. Took me a while to suss out how to keep tabs on what starting address was the back buffer and making sure that my sprite erasing kept track of which.

It's all using very basic assembly, nothing advance and just firmware calls where needed. As I said in my original post, I wanted to experience what it would have been like to develop for the CPC464 back in 83/84 when there was no (advance) knowledge of the CRTC or, C compilers, although I did have to cheat a little just to keep a decent frame rate. As I said in my update post, there is definitely some areas that I can still improve on and tidy up the duplicate code. I'm going to see how many more sprites I can get on the sceen and I'll also take a quick look at the AKG sound player. Would be nice to add a few sfx. I assume AKG isn't just a music creator and can help create sfx?

Thanks

[arnolde]

I assume AKG isn't just a music creator and can help create sfx?

There is an extra sfx player that interacts nicely with the music player. You can create both music and sfx with the brilliant Arkos Tracker 2 (but on the PC I'm afraid, so not like in 83/84).
Everything is very nicely documented on the website. 

[IndyUK]

Hi Folks,

Another updated video on my journey

Randomised the aliens a bit to give it a more game like look. Increased the on-screen objects to see how well it coped. Surprisingly not bad, FPS has taken a hit but still playable. Here's what roughly the code is handling;

- 1x player sprite 8x16
- 12x alien sprites 8x8
- 8x stars
- anything between 8-10 alien bullets on-screen, each 3x3
- anything between 6-8 player bullets on-screen, each 3x3

Remember this is all firmware still (kind of).

It seems that I no longer need to wait for vsync as the frame render has gone beyond 20,000us so not longer need to wait around. Going to see what more I can squeeze out of my code. I'm going to try out frame skipping as in principle that should get some speed back, although have no idea how easy to implement with a double-buffering. My initial attempt was not good, had lots of screen flicker.

Anyway, let me know what you guys think of this so far.

[Axelay]

If you are going to hardware double buffer, you will need to wait until vsync (since you are using firmware) to ensure you do not start writing your 'next' frame to the currently visible screen.  I would suspect if you are not waiting for vsync in that video, it could be why some of the sprites appear to flicker or 'jiggle' up and down occasionally.  The code could be erasing or repositioning sprites before the current frame has completed displaying on the monitor.  Using firmware, new settings for the screen base address on the crtc will not take effect until vsync occurs.