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?
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.
Quote from: TotO on 10:18, 21 June 14
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?
In this case, I suggest you to open a Poll here.
.
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...
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 (http://ralferoo.blogspot.com.br/2014/01/emulating-deformed-hsync-pulses.html) FPGA (http://ralferoo.blogspot.com.br/2014/01/so-previous-post-was-bit-light-on.html) 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 :)
Quote from: phi2x on 12:31, 21 June 14Also, 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.
Quote from: Axelay on 13:09, 21 June 14So 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 (http://www.cpcwiki.eu/forum/programming/wide-and-high-performance-128-bytes-line-mode/)".
Quote
Quote from: Executioner on 02:23, 16 October 13
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.
Quote from: fano on 09:45, 16 October 13Problem 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.
Quote from: Executioner on 10:17, 16 October 13
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.
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.
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.
Quote from: Rhino on 14:06, 23 June 14
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.
BTW, I've previously described what's actually happening here: Best 14" CRT for the CPC OR is my CPC 464 scart lead knackered? (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/best-14%27-crt-for-the-cpc-or-is-my-cpc-464-scart-lead-knackered/msg79233/#msg79233) and CPC2013 prototype (previously CPCFPGA) (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/cpc2013-prototype-%28previously-cpcfpga%29/msg73143/#msg73143)
Quote from: Rhino on 14:06, 23 June 14
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!
Quote
* 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).
Quote from: ralferoo on 16:58, 23 June 14It 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.
Quote from: Rhino on 21:36, 23 June 14
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.
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)
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.
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.
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:
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.
Quote from: AMSDOS on 00:00, 25 June 14
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:
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.
Quote from: arnoldemu on 09:33, 25 June 14
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.
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.
Quote from: AMSDOS on 00:00, 25 June 14
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.
Quote from: Optimus on 10:46, 24 June 14
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.
Quote from: Axelay on 14:32, 25 June 14As 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 (http://www.youtube.com/watch?v=7Jo4ZEnLgyc#)
www.youtube.com/watch?v=RreKfQDCgro (http://www.youtube.com/watch?v=RreKfQDCgro#)
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.
I wasn't aware Ghost 'n Goblins was using multiple scrolls, or are you suggesting the R3 has a different function in Ghost 'n Goblins, or is the program I posted demonstrating the technique found in G 'n' G?
Quote from: AMSDOS on 10:57, 27 June 14
I wasn't aware Ghost 'n Goblins was using multiple scrolls, or are you suggesting the R3 has a different function in Ghost 'n Goblins, or is the program I posted demonstrating the technique found in G 'n' G?
The program demonstrates the method used in Ghosts n Goblins (using R3 to make it smoother), but it uses a continuous scroll compared to a push scroll as in Ghosts n Goblins.
Ah yes. What it needs is an example which behaves more like G 'n G.
I don't recall seeing any BASIC program with data using this method, though it should be possible to make something which behaves more like G 'n G.
I've put together some examples with the idea of having a fixed person onscreen with the scenery above it that moves when Space is pressed, this is what I came up with after a bit of optimisation:
10 DIM map%(20):MODE 1:INK 1,26:INK 3,19:BORDER 0
20 GOSUB 2010:GOSUB 3010
30 FOR x=1 TO 10
40 LOCATE x+10,10:PEN 1
50 IF map%(x)=1 THEN PRINT CHR$(143)
60 NEXT x
70 PEN 2:LOCATE 15,12:PRINT CHR$(250)
80 place%=10
90 WHILE INKEY(18)=-1
100 IF INKEY(47)<>-1 THEN place%=place%+1:GOSUB 1010
110 WEND
120 MODE 2:CALL &BC02:PEN 1:END
1000 REM Space has been Pressed, Time to Move Scenery
1010 IF place%=21 THEN place%=1
1020 PEN 1:LOCATE 15,12:PRINT" "
1030 CALL &BD19:CALL &100
1040 OUT &BC00,3:OUT &BD00,5
1050 CALL &BD19
1060 OUT &BC00,3:OUT &BD00,&BE
1070 LOCATE 10,10:PRINT" "
1080 PEN 2:LOCATE 15,12:PRINT CHR$(250);
1090 PEN 1:LOCATE 20,10:IF map%(place%)=1 THEN PRINT CHR$(143)
1100 RETURN
2000 REM Scenery Data
2010 FOR n%=1 TO 20:READ map%(n%):NEXT n%
2020 RETURN
2030 DATA 1,1,1,0,0,1,1,0,1,1,1,0,1,1,0,1,0,1,1,1
3000 REM M/C to Firmware Scroll
3010 FOR addr=&100 TO &108
3020 READ a$:POKE addr,VAL("&"+a$)
3030 NEXT addr:RETURN
3040 DATA cd,0b,bc,23,23,cd,05,bc,c9
So when Space is held down, the man on the screen blinks a lot, I'm assuming due to the use of BASIC PRINT & LOCATE. I've improved this by deleting where the man is on screen (bit like Ghost 'n Goblins) and redraw after the Scrolling is done.
I've made some variations which leads up to this program which can be found on the attached disk image, I used the Position version to make sure the Data from the small array was being displayed correctly.
Quote from: Rhino on 21:36, 23 June 14
Yes, but programming the CRTC for 307 scanlines instead of 312, it is possible to get a vertical timings of 50Hz.
There's two things at play here...
You're right in saying that 307 scanlines with 65us lines is about 50Hz, it's actually slightly further out than the standard CPC display (19955us compared to 19968us). As you point out, this isn't going to cause a problem with vertical timing, because just as there's a horizontal PLL at 15.625kHz (or 64us), there's also a vertical PLL at 50Hz (312.5*64us). So, any slight vertical timing errors will become corrected over time (in fact, it's essential because the TV's vertical sync is very unlikely to be close to the camera's vertical sync initially as despite them running at 50Hz, they're not actually driven by the mains frequency.
However, the point is that running the horizontal clock at 65us is likely to cause your signal to not be correctly recognised by some LCD TVs. It should always work fine on an analogue CRT where the only concern is the PLL, but there's no guarantee if you're sending out such an out-of-spec signal to a digital system which expects you to send a correct signal.