The screen split in Deathchase

[Axelay]

Hi
As a follow on to my register 3 scroll example, I was wondering about using a split to maintain a display area.  As I am hopeless with splits, I've tried to do one based on the split from Executioners' Deathchase conversion, and just alter the dimensions to something more like I would want.  It does seem to work, but on my 6128 it seems like the range the v-hold is 'good' in is narrower, which probably indicates the split isn't right.  I was wondering if anyone who knows what they are doing with splits would mind having a look at the code I've attached?  You can run it straight from the Winape assembler.

Thanks
Paul

[Grim]

The problem is that the splitscreen produces 320 scanlines in a frame (48.83Hz refresh-rate) instead of 312 (for a 50Hz refresh-rate) because the 2nd screen (at the bottom of the frame) is one char too long.

You can fix this here:

Code Select Expand


  .int4
  ld (intno),a
  ld bc,#bc07
  out (c),c
  ld bc,#bdff
  out (c),c
  ld bc,#bc04
  out (c),c
  ld bc,#bd12 ;<= CHANGE HERE - 13 is 1 chr too much
  out (c),c


[Executioner]

As a follow on to my register 3 scroll example, I was wondering about using a split to maintain a display area.

You can do a screen split mixed with a R3 scroll, but the split itself should always be performed in such a way that R3 is not changed between the scroll and the screen split. Changing R3 once per frame appears to provide near exact positioning, but more than once per frame will probably cause the PLL some headaches.

[Axelay]

The problem is that the splitscreen produces 320 scanlines in a frame (48.83Hz refresh-rate) instead of 312 (for a 50Hz refresh-rate) because the 2nd screen (at the bottom of the frame) is one char too long.

Thanks!

You can do a screen split mixed with a R3 scroll, but the split itself should always be performed in such a way that R3 is not changed between the scroll and the screen split. Changing R3 once per frame appears to provide near exact positioning, but more than once per frame will probably cause the PLL some headaches.

I guess I am leaning away from using R3 as it looks like the left/right movement occurs with static components on my 6128 and I'm not that pleased with it.  So I'd be looking at using this for another byte scrolling shooter that has a larger display area, so it can perhaps have a gradius style upgrade system.  Or maybe a platform scrolling game, but that would be tricky to work out since I cant byte scroll with frame offsets and R3 would result in left/right movement of the display area...

On the R3 change not occurring between the splits - I'm only speculating, but isn't that what Super Cauldron would be doing?  I cant imagine any other way for it to have a stable display area on my 6128 while using R3 in the play area, when other examples of R3 use exhibit the left/right movement. It has a couple of character lines worth of gap between the two screens, so I wonder if that's there for stability purposes?

[Executioner]

I guess I am leaning away from using R3 as it looks like the left/right movement occurs with static components on my 6128 and I'm not that pleased with it.

I'm not sure what you mean by static components.

I cant imagine any other way for it to have a stable display area on my 6128 while using R3 in the play area, when other examples of R3 use exhibit the left/right movement. It has a couple of character lines worth of gap between the two screens, so I wonder if that's there for stability purposes?

Yes, most likely Super Cauldron does do that, and if done correctly, it shouldn't look too bad, but I wouldn't recommend it when there are other methods which work better (eg. The sample horizontal scroll I did with the fixed status line(s)). btw, does Super Cauldron work with a modulator then?

[Axelay]

I'm not sure what you mean by static components.

The display line, and also (and more annoying) the player sprite itself when it isnt moving around.  Though I suppose it could be argued that the player shouldnt spend much time in a shooter in the one place.

Yes, most likely Super Cauldron does do that, and if done correctly, it shouldn't look too bad, but I wouldn't recommend it when there are other methods which work better (eg. The sample horizontal scroll I did with the fixed status line(s)). btw, does Super Cauldron work with a modulator then?

I dont have a modulator, so I dont know anything other than what I read in a magazine once a long time ago (that when ghosts and goblins scrolled the picture went black & white).  So I can only pressume it wouldnt work.

[Executioner]

I dont have a modulator, so I dont know anything other than what I read in a magazine once a long time ago (that when ghosts and goblins scrolled the picture went black & white).  So I can only pressume it wouldnt work.

Hmm... I've yet to confirm this is not just G&G. Does anyone here have a modulator that they can try the following with:

out &bc00,3:out &bd00,&85

The screen should shift right slightly, and presumably lose the chroma output on a modulator and hence go black and white!

[Axelay]

You can do a screen split mixed with a R3 scroll, but the split itself should always be performed in such a way that R3 is not changed between the scroll and the screen split. Changing R3 once per frame appears to provide near exact positioning, but more than once per frame will probably cause the PLL some headaches.

I've finally got around to trying to combine the register 3 scroll with the split.  I've attached two different examples of it.  The version called "Example1" is doing it how I believe you are recommending it be done - changing R3 just after the last screen.  "Example2" on the other hand, does it twice per frame, between the screens and then after the second one, pretty much as you say it shouldnt be done!

Anyway, I've tried them both on my real 6128 & 464, and I find the method in example 1 hasn't really helped 'stabilise' the score line at all, there's still the obvious left/right quaking from my earlier R3 scroll example in the other thread.  But example 2 actually gives a much better result.  Not 100% stationary, but the quaking on the score line is reduced to such an extent that it is barely noticeable, if I dont look closely at the score panel section it doesn't draw my eye to it as example 1 does.

So I'm wondering what specifically are the problems, or potential problems, with doing the R3 change between the screen split and twice per frame?  As it stands it appears to give a much better result on my CPCs!

[Xifos]

Hi !

Axelay, if Prehistorik 2 really used R3 for horizontal scrolling, you should not hesitate and go for a game with your "one pixel mode 0 horizontal hardware scrolling" !
I know that the R3 trick for hardware scrolling is not always appreciated (not liked very much) because it's a "little dirty" way to move the screen, but for me it does not matter.
It's true that i don't have a real cpc anymore, and i tried your demo on Winape. 
But it's really impressive !
Et avec une rupture !
rupture : french for split screen 

[Axelay]

Thanks     The rupture code is by Executioner though, from the Death Chase conversion.  Seems just begging to be used in a horizontally scrolling game of some sort one day though!

[Executioner]

So I'm wondering what specifically are the problems, or potential problems, with doing the R3 change between the screen split and twice per frame?  As it stands it appears to give a much better result on my CPCs!

The problem is simply that the monitor has to settle into the new horizontal sync position after you've changed it. The CTM644  has a PLL which adjusts itself to the change in sync position. It can take a few scan lines to do this (usually about 1 scan line per MODE 1 pixel shifted), but it varies greatly depending on how many times it gets changed and to what extent. Since you're only changing it by 4 pixels it should only take a few scan lines to change. It probably varies mostly on the second change. The best bet is to simply test it on as many monitors/modulators as you can get your hands on and see which turns out best.

I have some code which does a similar split with a MODE 0 byte scroll, but I had the fixed display at the top. Using the once-per frame method, it seemed to be very smooth on my real CP6128 with a CTM644.

You can run the PlusTest HSYNC test (2) on different systems (it works on non-Plus systems too for test 2) to experiment with the R3 value by pressing Z or X.

[Axelay]

You can run the PlusTest HSYNC test (2) on different systems (it works on non-Plus systems too for test 2) to experiment with the R3 value by pressing Z or X.

Thanks for the explanation.  I'll give PlusTest a go, I've only been working on one of my two CTMs at them moment, and I have a scart lead I can try with a commodore monitor for what that's worth.

I also got myself an MP-1 to test out a little while ago.  I tried that out string test you gave in a previous post (setting R3 to &85) and the colour was lost.  It remained lost using a value of &86 as well.  It seemed that only setting it to &8e returned the colour, but I will try it out more thoroughly with that PlusTest program at some point.  But I'm not overly concerned if R3 scrolling only works on CTMs and not modulators or other types of screen.  As long as it works well on 'original hardware', that's fine by me.