Contra returns to the Amstrad CPC 6128 with continuous scrolling

Games! Vibe-coded games
1

Code & Logic Involvement

Full Vibe-Code (AI generated almost all game code)

Assets & Pipeline Involvement

Build tools / Asset conversion scripts

Project Notes & Prompts

Claude

Gryzor (Ocean / Konami, 1987) is the Amstrad CPC adaptation of Contra. The game looks great, but the background never truly scrolled; instead, it advanced in half-screen jumps, pausing briefly each time.

CONTRA 6128 is a reworked version of the original game for the Amstrad CPC 6128, featuring smooth, continuous background scrolling.

What has changed

Continuous scrolling in the jungle and final level: the background follows the player instead of jumping by half-screen increments.
Smooth waterfall ascent: the original’s one-third-screen jump is replaced by an animated upward movement.
No more pausing at screen transitions.
Clean display: each frame is prepared off-screen and then displayed instantly.
New title screen and title: CONTRA.

What remains the same

The graphics, enemies, rules, and game pacing are identical to the original.
The fixed-screen levels (base corridors) are exactly the same as in the 1987 game.
The original music from the 128KB version is included: press ESC at the title screen to switch between sound effects and music.

5 Likes
2

Wow, Gryzor is such a landmark in the CPC world. Having an AI modifying it with only prompting is a huge demonstration of its progress.

No more pausing at screen transitions.

There were big steps, obviously, but there never was a real “pause” IMHO: the gameplay remained “smooth” to me (in the sense of no wait). Sure the big step on each screen change meant you had to somehow know in advance where you’ll land, but still there’s overlap and that’s the kind of limitation we accepted at that time, especially given the whole game was kind of flawless besides.

Impressive feat by Claude Fable. Thanks M. Louvet for trying this and reporting to the whole world!

2 Likes
3

Holy cow that is impressive!

4

What happened to that old tech demo of Gryzor that appeared many moons ago?

5

Do you mean Gryzor Reloaded?

6

Hm, I think so?

7

What’s new in version 1.1

This update fixes gameplay issues found while playing version 1.0, and adds a jump button.

Gameplay fixes

  • Enemies show up on time. In version 1.0, some enemies appeared too late with the new smooth scrolling, especially the turrets built into the scenery and the bonus pods you have to destroy. Every enemy now appears at the exact moment its part of the scenery scrolls into view, at the same place as in the original game.
  • The flying weapon capsule is back. The capsule that flies in from behind early in the first stage, carrying the spread gun, was removed by the scrolling before it could reach the screen. It now crosses the screen as it did in 1987.
  • The base entrance opens again. At the end of the first stage, the destroyed door is now properly replaced by the hole, instead of the closed door reappearing.
  • No more missing enemies. The game only has room for seven enemies at a time. In the last stage, version 1.0 could lose one of them when that room was full; an enemy now waits for a free spot instead of being dropped.

New

  • Jump on the second button. The second fire button of the joystick now makes the player jump, even while firing. Pushing up still jumps as before, and up + fire still aims upwards.
  • Version number shown at the bottom left of the title screen.
1 Like
8

the what now? :smiley:

9

Yeaa… that scrolling is NOT smooth, quite the opposite in fact. It’s terrible scrolling.

And when the screen is full of sprites and bullets (especially when you’ve shot your spread weapon) the frame rate absolutely tanks. Unlike the original version where the FPS was locked in.

Nice try though.

2 Likes
10

I’m sure they’ll get it right in the next version, hehe :laughing:

11

I think instead that scrolling is good, the game is more playable.

Well done !

12

The more interesting part of this is how quickly they’ve been able to extract and abstract much of the logic of the game as well as the assets. Making it scroll on a CPC was probably always too big an ask (there’s a reason the original doesn’t) but being able to get to this point so quickly means it might be more possible to target the Plus hardware, which is more than capable, without huge reimplementation effort.

1 Like
13

The sprite of the hero seems to be shaking when the scrolling occurs. This would give me a headache.
Maybe a pushscroll would be better, like in Ghosts’n’Goblins? Not sure.

14

On CPC it would be frame rate that limits it (if software, fastest I’ve investigated is ocean’s method as used in batman, 2 pixels horizontally, 2 lines vertically), and that takes around 2 frames to draw the tiles. Sprites and gameplay then add to the cpu time for an update. Shinobi scroll is similar but not as fast, Extreme is good but also not as fast and other games are either often slower and/or choose to reduce the area to try and maintain some fps.

Software scrolls all seem to do byte by byte and some like Golden Axe even do char based scroll.

Ocean’s one often covers more screen too. The panel size is also the size it is to limit how much time to draw the tiles and fit it within 2 frames :wink:

I’m not going to explain how ocean do it here because AI doesn’t know how it’s done and I’m not giving it away and it’s clever human code (but with the way they do it they can’t have a panel in a different mode than the main game area…). Here I mean Ocean’s own team not one they got a third party to do.

With software you can draw sprites over the tiles and don’t need to worry about restoring the background behind like you need to do with hardware scroll.

Looks like this version of Gryzor is using hardware scrolling but at that rate it’s far too fast for the sprite movement which is pixel by pixel so it is always going to wobble or if you don’t want it to wobble like that do as Ghosts and Goblins does and as you approach the side scroll a large section on to minimise how often the screen jumps.

Classic answer from AI is move pixel by pixel like this and let it wobble and it says it is acceptable and not noticeable just as we have here… on MSX1 and continuous scroll like in Salamander yeah it is ok because the sprites work well with it but not like this.

With software scroll it could also jump a little too because often it is byte by byte horizontally. You could make a pixel by pixel software scroll but very few games do that and I am sure it’ll not be fast. (Actually I’ve not tried yet, one to add to my list of things I’ve tried).

With horizontal hardware scroll, crtc register R3 gives you same rate as software (but now you got flicker on the sides), and that is still not smooth enough when sprites move pixel by pixel, you can do pixel by pixel with hardware and with double buffering (to avoid flicker) but you need to reduce the screen size down to fit all the screens into main memory - unless you make it only for plus.

So Gryzor they chose the best at the time to get a reasonable fps, pixel by pixel movement and a fun game.

(Yes I’ve tried lots of different ways with scrolling including software and hardware. If movement of the character is at hardware scrolling rate (including r3) then you don’t get jumps and scroll can be continuous and not like Ghosts and Goblins but as soon as you slow the character down slower than hardware scroll rate you then need to compromise like G&G does).

5 Likes
15

This got me thinking, if people want we could do a closed category, inaccessible by bots, to serve for such discussions.

16

My goodness, @Arnoldemu really knows his stuff, I’m impressed, you learn something new every day :distorted_face::distorted_face::distorted_face::distorted_face: