About hardware scrolling with CRTC Reg 3

[Rhino]

What do you think about this technique in games?

From what I've read and tested, it is an effective way to do the horizontal scroll smoother. But I think it is only stable on CPC monitors. So users with another type of display can have a terrible game experience if the method fails.
Nevertheless, some classic games use this technique like Ghosts 'n' Goblins, Super Cauldron or Prehistorik 2, and also new games as Edge Grinder.
Is a technique accepted by the CPC community?

In a way, this reminds me the problem of using a bad video-timing, where CPC monitors may tolerate it, but some others not. And, if a game decides to use reg 3, assuming that will only work on CPC monitors, could then also use a custom video-timming (but 100% compatible with CPC monitors) without this being an added incompatibility problem?

[TotO]

For me, it's ok because:
- The CPC was sold with his CTM monitor
- R3 scroll works on CRT TV
- It's OK on emulators too

In fact, display problems only occur on LCD TV/Projectors linked to old systems. (not only the CPC)
Most of them no more have SCART input and HDMI converters cause new problems... Should we have to stop CPC productions?

No. I don't see why a "today limitation" have to stop peoples to do great things related to a vintage computer.

[Rhino]

For me, it's ok because:
- The CPC was sold with his CTM monitor
- R3 scroll works on CRT TV
- It's OK on emulators too

In fact, display problems only occur on LCD TV/Projectors linked to old systems. (not only the CPC)
Most of them no more have SCART input and HDMI converters cause new problems... Should we have to stop CPC productions?

No. I don't see why a "today limitation" have to stop peoples to do great things related to a vintage computer.

I agree. But, in practice, a major problem remains for users with modern TVs. And the question is, are they many users?

[TotO]

In this case, I suggest you to open a Poll here.

[Phi2x]

.

[Axelay]

I dont think I can really add much to the rationale already given by TotO, but I have experimented with R3 for a while.  One of the purposes of the Edge Grinder project was to get a small but functioning slow horizontal scrolling game out there using it, and see what the reaction was to try and get an answer to this very question.  Between both that and Relentless, there were only a handful of comments about it not working on peoples displays.  The thing I dont know is if that means not many people are using flat panels, not many people are trying them on real hardware, or the games simply have not appealed enough to many people to try on their real set ups.


So to me the uncertainty remains as to whether it's a technique I want to use in a 'big' game project or not.  I do recall there has been a few people in the past comment to the effect that the technique should be avoided because of the incompatibility with modern displays, but I wonder that if the question is about achieving compatibility with every set up out there, could that not also be an argument for making every CPC game 64K compatible?  Not quite the same circumstance I guess...

[SyX]

As TotO has said, it works in CMTs, CRTs, emulators and even ralferoo has made possible to use it in LCD TVs in his CPC FPGA implementation... i think it would possible for him to develop a board to attach the CPC to an HDMI TV and support all the CRT tricks, i'm a big fan of his CPC FPGA, jejeje.

And I'm using R3 too, because as Axelay has shown "CPC can do smooth and fast games", and we need more of those

[Rhino]

Also, it's funny that's you that come up with this question, because you're known for having generated the most fucked up frame signal, that made all CPC emulators go wrong

Anyway, I'm with TotO on this one: as long as the game or demo works fine on a real CPC and CTM monitor, I think it's OK.

Hehe, yes, I think mode R only works fine on CPC monitors and CRT TVs. But it's not the same thing to see a screen distorted for a few seconds, that completely ruin a game.

So to me the uncertainty remains as to whether it's a technique I want to use in a 'big' game project or not.  I do recall there has been a few people in the past comment to the effect that the technique should be avoided because of the incompatibility with modern displays, but I wonder that if the question is about achieving compatibility with every set up out there, could that not also be an argument for making every CPC game 64K compatible?  Not quite the same circumstance I guess...

And by extension, we can also apply the same reasoning to other CRTC tricks tolerated by the real hardware.

For example, the following is an excerpt from the thread "Wide and high-performance : 128-bytes line mode".

There is a way to make the display 64 (MODE 1) characters wide and do overscan with 128 byte wide display, but you need to tweak the horizontal total register by 1 in order to achieve it. ie. R0=64 rather than R0=63. This way you can set R1 to 64 and the CRTC should be able to increment the base address properly.

Problem with R0=64 is you'll get a 312*65µs frame so your frame timings will be not correct , some displays will not accept that.

That all depends on what you're designing the game/demo for. If it's to run on real hardware (CTM, GT) or a decent emulator, R0=64 is fine. I believe it should probably work with most VGA/SCART/S-Video/RF modulators also, but it would be worth testing.

If someone makes a game with reg 3, he could also apply the Executioner trick because he is already designing a game for certain conditions. This approach (develop for real hardware only) opens the door to use many tricks which have usually been taboo, or examples of bad programming practice for a part of the CPC community. This has its advantages and disadvantages, and I think the own answers in this thread can give a general idea of what is accepted by the community.

[arnoldemu]

Use it. I do. I have looked at super cauldron and it has different versions that can be selected. I am analysing them to find out the difference. I did see a difference in the way r3 is used. I will compare them more and give a detailed report. Perhaps elmar found something and to try and make it compatible he tried some varied methods.

[Rhino]

Btw, I've done some tests on my hardware and these are the results:

* Edge Grinder on my CTM644, Reg3 is ok.
* Edge Grinder on my CM14, Reg3 is ok.
* Edge Grinder on my Led 22" TV "Selectline" via Scart cable, Reg3 does not work.

Something I've noticed on both CTM644 as CM14, is that if you stop your ship, it seems 100% stopped without any vibration, however, the scoreboard on the bottom have a low horizontal vibration (about one mode 2 pixel or less). This is interesting, because if the scoreboard vibration is done due the Reg3 displacement is not exactly 1/2 char, it should also happen on the stopped ship.

And about Executioner suggestion:

* Reg0 = 64 on my CTM644 is ok.
* Reg0 = 64 on my CM14 is ok but not 100% stable, a small distortion sweeps the screen from bottom to top slowly, it is not something that catches a lot of attention, but it is noticeable.
* Reg0 = 64 on my Led 22" TV "Selectline" via Scart cable is ok.

[Axelay]

Something I've noticed on both CTM644 as CM14, is that if you stop your ship, it seems 100% stopped without any vibration, however, the scoreboard on the bottom have a low horizontal vibration (about one mode 2 pixel or less). This is interesting, because if the scoreboard vibration is done due the Reg3 displacement is not exactly 1/2 char, it should also happen on the stopped ship.

Oh, I forgot to mention before, there's the other reason I haven't decided on a 'big' game with R3 yet - I'm still not sure I'm completely doing it right.  From discussions in the past I have understood that on some CTMs the half character shift with altering R3 will not be exact so you may get that vibration on static elements.  On my CTM I see it on both the panel and the player ship when that's not moving, though only when I'm looking for it.  In Relentless I moved the score to the top of the screen and it became stable on my CTM.  Either luck with timing somewhere, or perhaps because R3 being a constant value during the first part of the frame helps.


But I have looked at Super Cauldron on my CTM too, and that panel is rock solid even below the play area.  I have on my to-do list to see if it's simply down to the fact that Super Cauldron will be changing R3 every screen refresh where Edge Grinder only does so every 4 screen refreshes, but if it's not that, then there's something I need to do better.

[ralferoo]

BTW, I've previously described what's actually happening here: Best 14" CRT for the CPC OR is my CPC 464 scart lead knackered? and CPC2013 prototype (previously CPCFPGA)

however, the scoreboard on the bottom have a low horizontal vibration (about one mode 2 pixel or less). This is interesting, because if the scoreboard vibration is done due the Reg3 displacement is not exactly 1/2 char, it should also happen on the stopped ship.

This is expected. The PLL corrects itself at a rate proportional to the error, so it takes a few lines to correct itself even for a small change of HSYNC position. You need to leave a reasonable period between the screen sections for this to be correct. When I was working on sugarlumps, an earlier version had an almost italic font due to not leaving enough gap between the main screen and the scrolltext!

* Reg0 = 64 on my Led 22" TV "Selectline" via Scart cable is ok.

It might look OK on your TV, but this video signal is very out of spec, as by changing the horizontal timings (64us->65us), you're also changing the vertical timings (50.08Hz -> 49.31Hz). Expect this not to work at all on other people's TVs, possibly causing occasional screen jumps. On a real CTM, you might also need to adjust the vertical hold as what would work for a normal picture might not work for this (although there will be a point where both with sync OK, but it's bad form to expect the user to need to change this).

[Rhino]

It might look OK on your TV, but this video signal is very out of spec, as by changing the horizontal timings (64us->65us), you're also changing the vertical timings (50.08Hz -> 49.31Hz).

Yes, but programming the CRTC for 307 scanlines instead of 312, it is possible to get a vertical timings of 50Hz.

[arnoldemu]

Yes, but programming the CRTC for 307 scanlines instead of 312, it is possible to get a vertical timings of 50Hz.

True, but that is not PAL like so televisions may still not like it.

[TotO]

TVs are more responsive to the frequency than the resolution.
If lines are missing, you should see a bottom black strip to fill the rest of the screen.
It was the "problem" of 60Hz games displayed on 50Hz consoles, like SMS and MD.
So few missing lines should be not visible, because over-scanned. (best if the display can be centered)

[Optimus]

Didn't know Ghost and Goblins is using this technique. I thought I ran this game on my TV but not sure. But I remember most of Axelay's game doing badly on my TV unfortunately.
I think I would avoid using it if it's so bad. Not sure if there are other proper ways to do good scrolling on CPC.

Good to know that it will still work on original CRT TV (I have a small one, also to play properly pistol based console games) I should try there too.

[arnoldemu]

I have updated the wiki with the technical details of the 4 different versions that can be selected of Super Cauldron.

They relate to if r3 scrolling is active or not and the vertical/horizontal sync positions.

EDIT:

The 3 modes of Prehistorik 2 are very similar to the modes in Super Cauldron.

So Elmar has provided the user a way to choose methods that are more compatible with their configuration.

[AMSDOS]

There's an article which I think originally came from AA, but was published in the Australian magazine The Amstrad User (Issue 26 - pages 56 - 58) which talks about the issue relating to Ghosts and Goblins and a Solution (posted in BASIC) was published:

Code Select Expand


10 DATA &CD,&0B,&BC,&23,&23,&C3,&05,&BC
20 DATA &CD,&0B,&BC,&2B,&2B,&C3,&05,&BC
30 oldmem=HIMEM:MEMORY (oldmem-16)
40 FOR a=HIMEM+1 TO oldmem
50 READ b:POKE a,b
60 NEXT a
70 scleft=HIMEM+1:scright=HIMEM+9
80 FOR a=1 TO 50
90 CALL &BD19
100 CALL scleft:OUT &BC00,3:OUT &BD00,5
110 CALL &BD19
120 OUT &BC00,3:OUT &BD00,&BE
130 NEXT a
140 MEMORY oldmem


This solution may not be a solution and there maybe better ways to code which keep the Firmware out of their programs, but it might be something worth trying on your TV sets to see if the effect is working.

[arnoldemu]

There's an article which I think originally came from AA, but was published in the Australian magazine The
Amstrad User (Issue 26 - pages 56 - 58) which talks about the issue relating to Ghosts and Goblins and a Solution (posted in BASIC) was published:

Code Select Expand


10 DATA &CD,&0B,&BC,&23,&23,&C3,&05,&BC
20 DATA &CD,&0B,&BC,&2B,&2B,&C3,&05,&BC
30 oldmem=HIMEM:MEMORY (oldmem-16)
40 FOR a=HIMEM+1 TO oldmem
50 READ b:POKE a,b
60 NEXT a
70 scleft=HIMEM+1:scright=HIMEM+9
80 FOR a=1 TO 50
90 CALL &BD19
100 CALL scleft:OUT &BC00,3:OUT &BD00,5
110 CALL &BD19
120 OUT &BC00,3:OUT &BD00,&BE
130 NEXT a
140 MEMORY oldmem


This solution may not be a solution and there maybe better ways to code which keep the Firmware out of their programs, but it might be something worth trying on your TV sets to see if the effect is working.

it switches r3 between 5 and &be. Normally we normally use 5/6.

EDIT: One of the versions of Super Cauldron/Prehistorik 2 that you can choose also does this.
EDIT: For those where R3 doesn't work, please try this and confirm if it works for you.

[AMSDOS]

it switches r3 between 5 and &be.

Yes it's a bit of an oddity, the example I posted is primarily moving the screen using the Firmware, but making it appear smooth, the program prior to that (in the article I described) is pretty much the same without the call scleft in line 100, it's not meant to simulate the scroll effect of Ghost And Goblins, but simulate the colourless effect of the game when a Modulator was being used, though without the "call scleft" in line 100, the effect seems to be nothing more than a shutter of the screen.

[arnoldemu]

it's showing off a more stable scroll it appears, and Ghosts and Goblins could be modified to work with it if effective.

Ghosts and Goblins also does the R3 scrolling without correction.

e.g. The value it sets is for the whole screen, it doesn't reset it back to a stable position at the end of the frame. It may work better doing this.

[Axelay]

There's an article which I think originally came from AA, but was published in the Australian magazine The Amstrad User (Issue 26 - pages 56 - 58) which talks about the issue relating to Ghosts and Goblins and a Solution (posted in BASIC) was published:

Ah thanks, I was wondering what issue that was, but couldnt seem to track it down.  I felt sure it was an issue of TAU where I first read about R3 scrolling, and I'm sure it was now because I have always thought of the style of scrolling used in Ghosts'n'Goblins as 'burst' scrolling just as they referred to it in the article.


But as far as a 'solution' goes, the way I read the article I think they're only saying that it's a solution to the problem of the 'standard' CRTC base address offset change type scroll being far too fast for most purposes.

[Axelay]

Didn't know Ghost and Goblins is using this technique. I thought I ran this game on my TV but not sure. But I remember most of Axelay's game doing badly on my TV unfortunately.
I think I would avoid using it if it's so bad. Not sure if there are other proper ways to do good scrolling on CPC.

Most?!  I've only used it in two games! 


As for an alternative method for a 1 pixel mode 0 scroll, well there is the 4 screens approach.  That chews a lot of memory and creates it's own problems though.  About the only way I have thought of to try and make it practical so far would be to use it in a game where you could split the play area into a bit of a simple parallax effect where there's one static background part, and one part that scrolls using 4 screens, just so between the two screens you can get a decent sized play area but dont need to use all the base RAM on screens.

[SyX]

As for an alternative method for a 1 pixel mode 0 scroll, well there is the 4 screens approach.  That chews a lot of memory and creates it's own problems though.  About the only way I have thought of to try and make it practical so far would be to use it in a game where you could split the play area into a bit of a simple parallax effect where there's one static background part, and one part that scrolls using 4 screens, just so between the two screens you can get a decent sized play area but dont need to use all the base RAM on screens.

Yes, exactly, i'm working in that idea for my shoot'em up, a few of my inspirations are:


www.youtube.com/watch?v=7Jo4ZEnLgyc

www.youtube.com/watch?v=RreKfQDCgro

[arnoldemu]

Back to R3. It seems then more testing is needed to find the best method.
I will write some more example code to do that.

I am planning to use R3 in the beat em up game I'm writing.

Back to the comment about Ghosts n Goblins. It does use R3, but again it has the push scroll, where when you approach the side of the screen it scrolls.

I still believe many cpc games get this wrong, they did get enough tweaking to make it right.
Push scroll is not bad in itself, it's down to the implementation.

Worst I think is games where you jump up, it push scrolls up rapidly, then you fall almost straight away and it push scrolls back the other way. Jumping up and down is then a horrible jumping jerking scrolling hell which is really not good. If it was much smoother there would not be a problem and the fun of the game would be transformed to even better.

Yeah the scroll on Prehistorik 2 on the CPC could be better. One day I hope to have a piece of demo code that shows how a nice scroll can be done using the same scrolling methods.

"Chucking in" a scroll is never a good thing it can need frequent tweaks to make the gameplay work well with it.