I have always thought, that "Turrican" for the CPC wasn't that bad. Really nice graphics, reasonable speed, but maybe a bit too jerky and no music during the game.
With today's knowledge, could a CPC-Version of "Turrican" get any better?
Turrican was never my cup of tea, but I always thought it was pretty good on the CPC.
Quote from: Axel on 15:33, 07 August 22With today's knowledge, could a CPC-Version of "Turrican" get any better?
Yes :P
Quote from: Gryzor on 15:43, 07 August 22Turrican was never my cup of tea, but I always thought it was pretty good on the CPC.
I really quite enjoy Turrican on the CPC but the small view always bothered me.
I always preferred the CPC versions over the more celebrated C64 versions. Just had a more satisfying chunky feel and bolder colours which I found more appealing. And it always surprised me that the C64 versions didn't actually have much in-game music either. In fact in-game music only seems to play on the 'gimmick' levels. Such as the floating about level on the first game or the spaceship level on the second.
But yes of course the CPC versions could be made better today with the all the coding knowledge and tricks that have been shared over the years. A larger game window for one. I never did understand why the Turrican sprite was green on the CPC version of Turrican II though. Especially when it has all those blues it could use instead. :P
Quote from: Axel on 15:33, 07 August 22I have always thought, that "Turrican" for the CPC wasn't that bad. Really nice graphics, reasonable speed, but maybe a bit too jerky and no music during the game.
With today's knowledge, could a CPC-Version of "Turrican" get any better?
Absolutely, but the time may not even be the point. Back the day it was a commercial game, so they had death lines and all that.
Today it could be done way better, especially using 6128plus features - just pinch the Amiga ;-)
Muzzy is recreating the Amiga version of Tirrican 2(as far as I know in C), if releases the source code(not sure if he has but I think he has) it's the best place to start!!! - https://eab.abime.net/showthread.php?t=106735
A wise man would say, "why make the actual game when you can create a hypothetical 3 seconds video of it"
Quote from: lmimmfn on 01:33, 08 August 22Muzzy is recreating the Amiga version of Tirrican 2(as far as I know in C), if releases the source code(not sure if he has but I think he has) it's the best place to start!!! - https://eab.abime.net/showthread.php?t=106735
The Turrican 3 source code was released around 8/10 years ago, and nobody to improve it, based on the Mega Turrican assets in AGA. May be the next step for him.
What tricks could you try to enlarge the game window with the same or better framerate?
It is not a matter of 'tricks'. To make any game on the CPC, you should use an engine that is build to take advantage of the CPC and design the game from scratch. Using engines made for Spectrum will always end up giving a 'yeah, ok, but' result, no matter how hard the effort to 'hack' or 'patch'. Both Turricans on the CPC are spectrum ports, no matter how polished to hide it.
There's probably a lot that could be done. Rewriting the engine to be CPC specific, rather than a rework of the Speccy code would help. As would going for 128K only, I'd expect.
Dealing with the viewport size might be tricky, although I think it would honestly play a lot better if you didn't have to be quite so close to the edge before it started scrolling.
Quote from: andycadley on 17:08, 08 August 22Dealing with the viewport size might be tricky, although I think it would honestly play a lot better if you didn't have to be quite so close to the edge before it started scrolling.
Yeah it's kinda like that even on the Amiga and C64 versions though they have a larger window so a lil bit more heads up to anything coming on screen. The CPC version's game window is 112 wide pixels (equal to 224 square pixels) while the C64 has is 152 wide pixel (equal to 304) and the Amiga is 304 square pixels but yeah I'd rather even though versions had a smaller box around the player before the screen scrolls.
Turrican can be greatly improved by doing a cartridge version (for all CPC including 464). That would allow compiled sprites= more performance= bigger screen. And full in-game soundtrack.
Considering 64ko and tape context, Turrican 1&2 on CPC are masterpieces. I played them with pleasure.
Considering floppy release, Turrican 1&2 could be improved using 128ko. Or a 64ko cartridge release. Turrican 1 title screen could be improved. The 2nd one was really better to my opinion.
The Turrican 2 sprite was blue at the beginning, several years ago i post here Amstrad Action preview of Toki GX4000 and Turrican 2 and the sprite shown at this time was far better.
Quote from: kawickboy on 10:35, 10 August 22The Turrican 2 sprite was blue at the beginning, several years ago i post here Amstrad Action preview of Toki GX4000 and Turrican 2 and the sprite shown at this time was far better.
Ok cool I found the tiny screenshot in Amstrad Action 67. But the best example I could find was very blurry but yeah I could see the player sprite was blue/white rather than the greens of the finished game. Can anyone provide a higher quality shot perhaps from the real magazine itself? I'm just curious to see it. :)
(https://imgur.com/aXTxEif.jpg)
I have it somewhere in a moving crate.
Quote from: rexbeng on 07:54, 08 August 22A wise man would say, "why make the actual game when you can create a hypothetical 3 seconds video of it"
Jup, they call it '8 Bit Cinema' - lots of funny youtube vids there.
Quote from: Axel on 12: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 ;-)
Quote from: Carnivius on 13:41, 10 August 22Quote from: kawickboy on 10:35, 10 August 22The Turrican 2 sprite was blue at the beginning, several years ago i post here Amstrad Action preview of Toki GX4000 and Turrican 2 and the sprite shown at this time was far better.
Ok cool I found the tiny screenshot in Amstrad Action 67. But the best example I could find was very blurry but yeah I could see the player sprite was blue/white rather than the greens of the finished game. Can anyone provide a higher quality shot perhaps from the real magazine itself? I'm just curious to see it. :)
(https://imgur.com/aXTxEif.jpg)
I thought I had it in my little stash of magazines, but I don't, sadly.
Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: Devlin on 23:14, 10 August 22I thought I had it in my little stash of magazines, but I don't, sadly.
Thanks for looking though. :)
I ended up doing a couple very quick mock ups where I recoloured (and did very minor tweaks) to the Turrican sprite to see how it might have looked. I think the blue/grey colours give him a bit more depth. I left the green one in there for comparison. Also did a quick palette swap of one of the enemies in that first shot too.
(https://i.imgur.com/N0zwXyi.png)
(https://i.imgur.com/sjQ5LOj.png)
Quote from: Axel on 12:28, 08 August 22What tricks could you try to enlarge the game window with the same or better framerate?
I believe Turrican redraws the screen each frame - as it was derived from the Spectrum port.
Assuming this is true, then using hardware scrolling - however chunky as the existing game scroll is chunky nothing is lost - and a raster split for the scoreboard, might give a lot more clock cycles to do other work, and allow a larger screen. Smoother vertical scrolling can be achieved with the smaller character height as mentioned above, and there's the R9 trick perhaps for horizontal scrolling smoothness but might not work on this engine.
Quote from: Carnivius on 13:41, 10 August 22Ok cool I found the tiny screenshot in Amstrad Action 67. But the best example I could find was very blurry but yeah I could see the player sprite was blue/white rather than the greens of the finished game. Can anyone provide a higher quality shot perhaps from the real magazine itself? I'm just curious to see it. :)
I'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.
Quote from: Nich on 20: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.
Thank you! Hm, it's more different than I thought. Smaller shoulder pads. Red elbow pads. Slightly different helmet.
Also it's from before they added the fonts and also the code that makes the bridge segments dip as the player walks over them. Cool. I like stuff like this. Seeing earlier work in progress shots of some of my fave games. :) Thanks again for taking a photo of it. :)
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.
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.
Turrican and Turrican II on CPC always made me laugh.
Sometimes it may be better not to do the conversion.
Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: TotO on 18: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.
Quote from: stevensixkiller on 10: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.
:) http://www.cpcgamereviews.com/t/index16.html :)
:) https://www.cpc-power.com/index.php?page=detail&onglet=test&num=2318 :)
Quote from: stevensixkiller on 10:22, 13 August 22Quote from: TotO on 18: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.
Quote from: ComSoft6128 on 10: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.
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?
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?
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?
Quote from: Nich on 20: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.
Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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?
Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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 :)
Quote from: andycadley on 19: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.
Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: GUNHED on 18: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.
Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: lmimmfn on 23:53, 14 August 22Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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).
Quote from: andycadley on 07:27, 15 August 22Quote from: lmimmfn on 23:53, 14 August 22Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: lmimmfn on 01:51, 16 August 22Quote from: andycadley on 07:27, 15 August 22Quote from: lmimmfn on 23:53, 14 August 22Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: lmimmfn on 23:53, 14 August 22Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: GUNHED on 00:54, 17 August 22Quote from: lmimmfn on 23:53, 14 August 22Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Quote from: lmimmfn on 02:07, 17 August 22Quote from: GUNHED on 00: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.
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.
Quote from: lmimmfn on 02:07, 17 August 22Quote from: GUNHED on 00:54, 17 August 22Quote from: lmimmfn on 23:53, 14 August 22Quote from: GUNHED on 18:29, 14 August 22Quote from: andycadley on 19:37, 13 August 22Quote from: GUNHED on 19:23, 12 August 22Quote from: lmimmfn on 01:18, 11 August 22Quote from: GUNHED on 15:37, 10 August 22Quote from: Axel on 12: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.
Not characters - scanlines!
Quote from: abalore on 11:25, 17 August 22With 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.
Quote from: GUNHED on 21:46, 17 August 22Quite 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.
Quote from: GUNHED on 21:46, 17 August 22Quote from: abalore on 11:25, 17 August 22With 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?
Quote from: GUNHED on 21:46, 17 August 22One 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.
Quote from: abalore on 23:29, 17 August 22Quote from: GUNHED on 21:46, 17 August 22One 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.
Quote from: lmimmfn on 01:10, 18 August 22I 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)
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?
Quote from: Axel on 14:17, 19 August 22Would 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).
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.
Quote from: eto on 22:28, 17 August 22Quote from: GUNHED on 21:46, 17 August 22Quite 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.
Quote from: GUNHED on 12:41, 23 August 22Quote from: eto on 22:28, 17 August 22Quote from: GUNHED on 21:46, 17 August 22Quite 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?
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.