Could "Turrican" be made better today for the CPC?

[abalore]

With 8 pixel character height you can easily do 1 pixel scrolling, the CRTC has a specific register for that. And you don't have to update all the 8 pixel row per frame, you can do it in 8 steps, so the Z80 usage is the minimal required. I don't see how a 2 pixel character height would work without having to change the display start address in each block and without having to make a painful sprite drawing routine.

[GUNHED]

What tricks could you try to enlarge the game window with the same or better framerate?

- Use screen 64 byte in width (32 x 32 characters in MODE 1, but here MODE 0 would probably look more nice)
- Use CRTC characters only 4 scanlines high, or even better only 2 (instead of 8 like usually), this will make the scrolling more smooth, also gives extra time, because less V-RAM needs to be moved.
- instead of having sprites as data, use something like CoData (I use that for Filmemacher). Basically a program which draws the sprite or graphic element on screen. That's more quick compared to copy data.
- Use more RAM, this enables to unroll routines which contain loops. Also a speed up.

And finally: Do a complete rewrite instead of patching / enhancing / bettenering / etc. of an existing program. Alcon 2020 may serve as a well example for that ;-)

Excuse my ignorance but on
"Use CRTC characters only 4 scanlines high, or even better only 2 (instead of 8 like usually), this will make the scrolling more smooth, also gives extra time, because less V-RAM needs to be moved."
How does that make scrolling smooth? The CRTC has a fixed number of cycles to read the ram separately to the Z80, so how does reducing the character scanlines improve performance if its still a full screen(32x32)?
The CRTC is still working outside of the Z80 for screen refresh so I don't understand the comment.

The regular character line height is 8 scan lines. So you need to transfer data for 8 scanlines every frame in case you want to scroll up or down.
In case you use only 2 scanlines, then you only need to transfer 1/4 of the data. In addition scrolling is more smooth and slower.

Wouldn't that also make the screen 1/4 height? Or am I missing something?

No, just use more character lines. 25 * 8 = 200 scanlines. 100 * 2 = 200 scanlines too.

But why is that different, its the same amount of screen update from the CPU and the CRTC is updating a full screen, where is the saving coming from? Not trying to be argumentative, I just don't understand.

It only matters what the Z80 does. The less you shift the screen, the less RAM the Z80 needs to change. The CRTC does it's work independent, like all other chips too.

That's my point really, Z80 has to update the screen and outside of the Z80 processing time the screen is updated via the CRTC.
Which brings me to the point that 2 pixel character screen setup has no advantage over 8 pixel characters  Smooth vertical 1 pixel scrolling is completely independent of vertical char size or 1 byte horizontal scrolling.

Not characters - scanlines!

[GUNHED]

With 8 pixel character height you can easily do 1 pixel scrolling, the CRTC has a specific register for that. And you don't have to update all the 8 pixel row per frame, you can do it in 8 steps, so the Z80 usage is the minimal required. I don't see how a 2 pixel character height would work without having to change the display start address in each block and without having to make a painful sprite drawing routine.

Quite in contrast, drawing sprites with 2 scanlines / character height is more easy.

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

[eto]

Quite in contrast, drawing sprites with 2 scanlines / character height is more easy.

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

If you would share the CRTC register values you have in mind, we could give it a try. I tried in the emulator, but did not succeed to get a stable screen. 

[gurneyh]

With 8 pixel character height you can easily do 1 pixel scrolling, the CRTC has a specific register for that. And you don't have to update all the 8 pixel row per frame, you can do it in 8 steps, so the Z80 usage is the minimal required. I don't see how a 2 pixel character height would work without having to change the display start address in each block and without having to make a painful sprite drawing routine.

Quite in contrast, drawing sprites with 2 scanlines / character height is more easy.

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

Mission genocide, Alcon, etc

I thought the vertical pixel scroll on the cpc was the easiest.
Really, I don't see any games using 2 line characters. An example according to you, who modifies the R9 for the game area?

[abalore]

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

It was very easy to do it in Alcon 2020, and it works perfectly in all CRTs. In fact, there is no reason to have any problem in any monitor since the scanline count never change and so the vertical frequency is perfectly stable.

And about being easier to draw sprites with 2 scanline character height, well, it's just not true. If you want to draw a 16 pixel sprite, in 8 scanlines you just need to make one line adjustment and in 2 scanlines you have to do 8.

[lmimmfn]

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

It was very easy to do it in Alcon 2020, and it works perfectly in all CRTs. In fact, there is no reason to have any problem in any monitor since the scanline count never change and so the vertical frequency is perfectly stable.

And about being easier to draw sprites with 2 scanline character height, well, it's just not true. If you want to draw a 16 pixel sprite, in 8 scanlines you just need to make one line adjustment and in 2 scanlines you have to do 8.

I agree, 8 character 1 pixel vertical scrolling is simple and straight forward but needs some tricks to hide the 1 line draw update which is solvable with a 1 line mode 2 rupture where both colours are black or whatever the border is.

Still not understanding this 2 pixel vertical character size advantage/angle.

[abalore]

I agree, 8 character 1 pixel vertical scrolling is simple and straight forward but needs some tricks to hide the 1 line draw update which is solvable with a 1 line mode 2 rupture where both colours are black or whatever the border is.

Still not understanding this 2 pixel vertical character size advantage/angle.

Yes, you can use the mode 2 / ink change trick (like Red Sunset) or just delete the lines (like Alcon)

[Axel]

Would it be possible to use a trick to fool the computer into thinking that the video RAM is only half as large in order to save CPU cycles?

[andycadley]

Would it be possible to use a trick to fool the computer into thinking that the video RAM is only half as large in order to save CPU cycles?

Well you can make the screen half the height, but I assume that's not what you mean? There's no particularly useful way of getting the screen to e.g. duplicate lines in a usable way that doesn't end up consuming a fair bit of CPU as well (maybe with a Plus you could play around with the SSCR and do it, but you'd still be dedicating a lot of CPU time to fudging the display).

[Axel]

I thought of a trick that would trick the hardware so that the CPC processed graphics like the Spectrum for example. If my information is correct, the large video RAM is a slowing factor. If you could fool the hardware into thinking it was only 8kbytes in size, it would fill up faster.

[GUNHED]

Quite in contrast, drawing sprites with 2 scanlines / character height is more easy.

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

If you would share the CRTC register values you have in mind, we could give it a try. I tried in the emulator, but did not succeed to get a stable screen.

Emulator problem. Use real hardware please. For CRTC values look at unofficial Amstrad ressources and the CRTC documentation floating around here. 
Using WinCPC just alter CRTC values: Of course you need the double number or character lines if you take half the scan lines per character line. The total number of scan lines must always (nearly) be the same. It was written here many times.

[andycadley]

Quite in contrast, drawing sprites with 2 scanlines / character height is more easy.

One pixel scroll in Y is a pain using 8 scanlines. It may work well on flat screen, but give it a try on CRT original monitors.

If you would share the CRTC register values you have in mind, we could give it a try. I tried in the emulator, but did not succeed to get a stable screen.

Emulator problem. Use real hardware please. For CRTC values look at unofficial Amstrad ressources and the CRTC documentation floating around here.
Using WinCPC just alter CRTC values: Of course you need the double number or character lines if you take half the scan lines per character line. The total number of scan lines must always (nearly) be the same. It was written here many times.

You can't just add character lines without the screen memory repeating though. So it's not as simple as "just add extra lines". Unless you know something the rest of us are missing?

[GUNHED]

Again, please see unofficial amstrad ressource of CRTC docs form Logon system.
Sometimes I think people just want to misunderstand what I say. Bye for this thread.