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

Started by Axel, 17:33, 07 August 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

andycadley

It's almost certainly just a mock up screen, preview screenshots in magazines usually were. I'd imagine the colour changes were because greens were more useful across all the levels and they wanted the main Turrican character to be a consistent subset of the palette.

||C|-|E||

I played both Turrican I and II like crazy in the CPC back in the days, they were among my favourite games in the platform. I agree that the first one was a bit chonky, but the levels were huge and difficulty was really well adjusted for my clumsy hands, I even managed to finish them. Regarding Turrican 2, the only thing I never liked was the main character sprite. On one hand, I was not fond of helmet and, on the other, as you mentioned it was green. Maybe it was the best color choice for clarity, but it definitely was a big no for me.

TotO

Turrican and Turrican II on CPC always made me laugh.
Sometimes it may be better not to do the conversion.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

stevensixkiller

Quote from: TotO on 20:37, 12 August 22Turrican and Turrican II on CPC always made me laugh.
Sometimes it may be better not to do the conversion.
Maybe if you compare it to other versions. But when you only had a CPC back in the day, this game was awesome.

TotO

Quote from: stevensixkiller on 12:22, 13 August 22Maybe if you compare it to other versions. But when you only had a CPC back in the day, this game was awesome.
It was just ok for 1991. Many CPC games move and sound better and are more fun to play.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

ComSoft6128


Carnivius

Quote from: stevensixkiller on 12:22, 13 August 22
Quote from: TotO on 20:37, 12 August 22Turrican and Turrican II on CPC always made me laugh.
Sometimes it may be better not to do the conversion.
Maybe if you compare it to other versions. But when you only had a CPC back in the day, this game was awesome.



My uncle had both on C64 and I still enjoyed playing my Turrican II demo off the Amstrad Action covertape far more than that version.  I rarely touched the CPC once I got the Amiga and the game on there but these days I quite happily play the CPC and Amiga versions for different reasons. It's honestly one of my all time fave games on any 8 bit and great achievement on the 464.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

TotO

Quote from: ComSoft6128 on 12:48, 13 August 22:)  http://www.cpcgamereviews.com/t/index16.html :)
:) https://www.cpc-power.com/index.php?page=detail&onglet=test&num=2318 :)
Well... The game is slow, the sound is poor and that is enough to not let me enjoy to play it. Now, I agree there is a great content and nice graphics (with parallax) so it is close to be a great acheivement and I'm sure that many CPC users loved it. May be a patch to display faster and introduce music can change my mind.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Carnivius

I'm not sure I understand. Both games run well enough on CPC. The second game feeling faster than the first. And sound isn't great on either but does a passable job (better than many CPC games).  There's no in-game music on any of the 8 bit home computer versions except the flying levels on the C64 game (NONE on the actual platform levels for some reason).  They control well on CPC and are overall of a much higher standard than most CPC games in general.  What games do this sort of genre better on CPC?
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Axel

The lack of ingame-music is the main reason why I don't like the CPC-Version that much...and the C64-Version too.
Imagine the game  "Batman - The Movie" without that wonderful soundtrack composed by Matthew Cannon....just "lifeless".


Does ingame-music stress the CPU? Or is it just a question of memory?


ComSoft6128

#36
Interesting:
https://www.pressreader.com/uk/retro-gamer/20201126/283974654957190

&

https://www.pressreader.com/uk/retro-gamer/20201126/283987539859078/textview

Soo, as it was released for the 464 (without an enhanced 6128 version) maybe lack of memory was the problem?

chinnyhill10

Quote from: Nich on 22:02, 11 August 22I've taken a photo of the screenshot from my own collection of AA magazines, and the player sprite does indeed appear blue instead of green.

Just keep in mind that screenshots provided to magazines can be mock ups rather than functioning code. Most infamously Sinclair User reviewed Nemesis with mocked up development screenshots that were nothing like the game. That screen could just be a picture thrown together in DPaint or something and the colours got changed as the assets were moved across.
--
ChinnyVision - Reviews Of Classic Games Using Original Hardware
chinnyhill10 - YouTube

andycadley

Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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?

lmimmfn

#39
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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?
That's what I don't understand(didn't get a chance earlier to respond).
The CRTC is effectively stealing( not really stealing like bitter on the Amiga, but Z80 is clocked so that CRTC takes over for the display) a fixed number of cycles from the cpu(hence lower Z80 clockspeed of CPC vs Spectrum).

It's normally a 16k screen, I don't understand how modifying the character height reduces anything  but I may have understood the intention. I do understand of course that the smaller the screen the less cpu cycles are needed to update of course  :)
6128 for the win!!!

MaV


Quote from: andycadley on 21:37, 13 August 22Wouldn't that also make the screen 1/4 height? Or am I missing something?

Right, you have to do some additional CRTC trickery with exact timing, IIRC, to display a whole screen when you reduce the character lines to two.

Have a look what happens (the value equals the number of lines-1):
OUT &BC00,9:OUT &BD00,1:REM reduce character lines to 2
Reverse the effect:
OUT &BC00,9:OUT &BD00,7:REM restore character lines to 8

The CPC just displays the usual characters but reduced to two, when the pointer to the screen RAM reaches the end of the 16k at line 25 but the CRTC is not finished due to how other CRTC registers are set, it loops around to the beginning of the screen RAM and displays the same picture a second, third and fourth time.

Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

GUNHED

Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

eto

Quote from: GUNHED on 20:29, 14 August 22No, just use more character lines. 25 * 8 = 200 scanlines. 100 * 2 = 200 scanlines too.
can you share the right CRTC settings? I tried but I won't get a proper screen.

lmimmfn

Quote from: GUNHED on 20:29, 14 August 22
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
6128 for the win!!!

andycadley

Quote from: lmimmfn on 01:53, 15 August 22
Quote from: GUNHED on 20:29, 14 August 22
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
I assume it's because hardware scrolling the screen up by a character would only scroll it two pixels rather than eight, so you could theoretically get smoother scrolling.

I can't see how you can avoid the screen memory repeating though, unless you rupture the screen multiple times and spread the video memory out. Which would work but makes for a tricky memory map, not to mention some potentially awkward timing (maybe it can be pulled off in an ISR, I can't say I've ever tried).

lmimmfn

Quote from: andycadley on 09:27, 15 August 22
Quote from: lmimmfn on 01:53, 15 August 22
Quote from: GUNHED on 20:29, 14 August 22
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
I assume it's because hardware scrolling the screen up by a character would only scroll it two pixels rather than eight, so you could theoretically get smoother scrolling.

I can't see how you can avoid the screen memory repeating though, unless you rupture the screen multiple times and spread the video memory out. Which would work but makes for a tricky memory map, not to mention some potentially awkward timing (maybe it can be pulled off in an ISR, I can't say I've ever tried).
But the CRTC allows per pixel vertical scrolling and per byte(2 pixel mode 0, 4 pixel mode 1 and 8 pixel mode 2) out of the box. 
I still don't understand how reducing character height to 2 improves scrolling or reduces cpu overhead on screen updates vs a normal 8 pixel high character? I'm curious to understand this.
6128 for the win!!!

andycadley

Quote from: lmimmfn on 03:51, 16 August 22
Quote from: andycadley on 09:27, 15 August 22
Quote from: lmimmfn on 01:53, 15 August 22
Quote from: GUNHED on 20:29, 14 August 22
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
I assume it's because hardware scrolling the screen up by a character would only scroll it two pixels rather than eight, so you could theoretically get smoother scrolling.

I can't see how you can avoid the screen memory repeating though, unless you rupture the screen multiple times and spread the video memory out. Which would work but makes for a tricky memory map, not to mention some potentially awkward timing (maybe it can be pulled off in an ISR, I can't say I've ever tried).
But the CRTC allows per pixel vertical scrolling and per byte(2 pixel mode 0, 4 pixel mode 1 and 8 pixel mode 2) out of the box.
I still don't understand how reducing character height to 2 improves scrolling or reduces cpu overhead on screen updates vs a normal 8 pixel high character? I'm curious to understand this.
It doesn't.

The CRTC scrolling works in Mode 1 character sized blocks (16 mode 2 pixels wide or 4px Mode 0, and normally 8 px vertically in any mode). But there are tricks over and above this which can help.

So you can physically position the screen on the monitor with far more precision (approx 1 byte horizontal and by scanline vertically). By changing the position registers you can therefore fake smoother scrolling. It'll look flickery at the edges but you can compensate by either masking off the edges with the same colour ink as the border, stretching the screen so the edges are off monitor or use a rupture split to chop the display up vertically.

By changing the character height in the CRTC, however, you could increase the granularity of vertical scrolling (since moving the display up by "1 character row" will be less of a change). The downside is that the address generation logic in the gate array can't be tweaked to accommodate this, it is all based on the assumption of 8 line high characters and so the display will start to repeat.

The only way I can see to get around this is to rupture the display multiple times, each time moving the screen to another 16K block, such that you still use 16K of display memory only it's now arranged in 4K chunks spread across all 64K. You'd have to interleave all the game code and data with it and drawing to the screen would presumably be even more convoluted that with normal hardware scrolling, but in theory it makes sense.

GUNHED

Quote from: lmimmfn on 01:53, 15 August 22
Quote from: GUNHED on 20:29, 14 August 22
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2022.03.09)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

lmimmfn

Quote from: GUNHED on 02:54, 17 August 22
Quote from: lmimmfn on 01:53, 15 August 22
Quote from: GUNHED on 20:29, 14 August 22
Quote from: andycadley on 21:37, 13 August 22
Quote from: GUNHED on 21:23, 12 August 22
Quote from: lmimmfn on 03:18, 11 August 22
Quote from: GUNHED on 17:37, 10 August 22
Quote from: Axel on 14:28, 08 August 22What 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.
6128 for the win!!!

eto

Quote from: lmimmfn on 04:07, 17 August 22
Quote from: GUNHED on 02:54, 17 August 22It 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.
That's what I understood from Gunheds post: When you scroll the screen by one character, the CPU has to update that part of the screen, that is shifted out of one border and into the opposite border. Otherwise your screen would not scroll, but roll. With a character height of 8 lines, you have to update 8x 80bytes and with a character height of 2 lines, you have to update only 2x 80bytes. 

What I am still missing: What are the CRTC settings that allow to generate a 320x200 screen with a character height of 2 lines? If that exists, let's try it out.

Powered by SMFPacks Menu Editor Mod