I asked Claude to see if it could change the scrolling from the large horizontal jumps into something a bit better.
And it did. Horizontal scrolling now moves in mode 1 character blocks instead of mode 0 character blocks, which is much nicer.
This lead to a messy shimmer on Roland himself, which took some back-and-forth to fix.
The next thing to try was a speed-up.
This went through a number of iterations and ideas, but as you’ll see, it is a heck of a lot faster now.
Finally, the shimmering on the 4 sides of the screen when scrolling.
This happens due to the use of hardware scrolling, and I wanted to see if Claude could do something to minimise it.
It isn’t completely gone (even after several improvements), but it is much better.
There were some mistakes along the way, but with enough testing and iterating, it came up with a pretty good result!
Please note that I haven’t tested all gameplay aspects, but it seems to be working well. There are still a few minor graphical glitches, but the original game had much worse glitches due to the hardware scroll induced shimmering anyway.
I was trying to figure out how to add all the text I had written to the post, and I was able to paste it into “Project Notes & Prompts”.
It seemed odd that I wasn’t able to post something about the game into the topic.
Is it by design that posts about vibe-coded stuff are limited, regarding what can be posted?
Also, I’m curious, how come the Sultan’s Maze thread was closed? (I want to know if I did something wrong, and what sort of things I should be aware of in the future).
I wonder if it used my info to prevent the shimmering on the sides…
I asked chatgpt the other day how to do something with scrolling (curious if it could come up with something new from existing info but no), asked it where it found it’s info, and it was quoting me from the old cpcwiki forum. Well I did publish it there for people to use…
Ok, not the shimmering from R3 I was thinking about.
It is the usual hardware scroll, not using R3, and it’s not double buffering which is interesting. Ok looks like it may have unrolled the tile drawing into LDIs.
Regarding LDI usage, one of my early prompts was this:
i would like to look at patching the in-game code to improve the scrolling. and if that can be done, for a new .bin to be built than can slot back onto the dsk. at the moment the scrolling is very jumpy, moving in what appears to be 1 mode 0 character at a time. i would like it to move in jumps the size of mode 1 characters
and claude replied with:
It can be done, and the patched ROLANDC.BIN and ROLANDD.BIN are ready to drop onto the dsk under the same names. I have only run them in my own harness (a Z80 core with stubbed firmware calls), not on a CPC or a real emulator, so they need a run in yours.
How the game scrolls
The game is Mode 0, built from 4×8-byte tiles (one Mode 0 character), with a 20×23 tile window plus a 2-row status panel.
Scrolling is firmware hardware scroll (SCR SET OFFSET): ±4 bytes horizontally, ±80 vertically, then one new column or row of tiles is drawn.
Vertical steps are 8 scanlines, which is already Mode 1 character height, so I left vertical alone.
All drawing goes through one tile blitter at &2AF8, which is what made the patch small.
What the patch does
Each horizontal step is now two 2-byte steps. Game logic is untouched and still moves one tile per loop.
First half-step (hook at &A1DA, just after the tile buffer rebuild): shifts the offset by 2, draws half of the incoming column, and redraws the player and the status panel.
Second half-step (hook at &34EF, the original scroll point): shifts by the other 2, draws the full column, and restores the tiles under the player.
Faster blitter: I also replaced &2AF8 with an unrolled LDI version to pay for the extra drawing. This affects the whole game, not just scrolling.
Where it lives: 397 bytes at &A900 in the zero padding at the end of ROLANDC, and 118 bytes at &2A79 in the padding below the old blitter. File lengths and headers are unchanged.
And later, when trying to reduce the shimmering caused by the hardware scroll, claude had this to say:
What changed
Panel slide across the wrap: the run lengths are worked out once per move (up to three straight runs per scan line, split where the source or destination meets the end of its 2K), then each line is copied with LDIR/LDDR. When there is no wrap in the way it still uses the unrolled copy.
First half-step fallback removed: the half-state panel redraw is gone, since the slide no longer fails for the wrap.
Rope steps: the slide now works in the zone on vertical steps too.
I use it at work and the other day I was looking at the code that had been generated and it had used a quick look up method I wasn’t aware of before and so I read about it and learnt something new.
What is good about the method used in this version is that the horizontal scroll can be smoother than vertical because there is no diagonal scroll happening anywhere in the game.
Well, I’ve been kinda on the fence about AI usage but I have to admit it’s solved a lot of the ‘issues’ in Roland On The Ropes here.
Having had a play, I will say the really fast ‘gameplay’ speed - whilst impressive - kinda spoils the general gameplay. With years of playing the game, still semi regularly, it makes it far too hard to time jumping over the rats for just one obvious example. In later levels with multiple enemies like bats, etc it’s just going to be a nightmare frustration.
Is there any way to keep the improvements but just temper the speed down?
This is a nice improvement, and a good use of AI to do targeted small changes to improve existing codebases without having to spend all the time doing manual analysis and patches. I think this is suitably different from using generative AI to create games from scratch with little developer/graphics input.
What would be nice is transparent blitting of the ghost sprite when it goes through walls rather than the big blocky movement.
I don’t know what to say. You’ve transformed the whole game experience. I had this in my welcome pack when I first got the CPC. Quite liked it but the scrolling was a bit off putting but, now. It’s so good and smooth - Well done!
Do you think the sprite printing could be improved using AI? You can see there’s no transparency as all sprites have a Black background. Would be great if they could be improved.
I had initially created it in the incorrect sub-forum, and after you mentioned that I needed to create it in an appropriate AI-related sub-forum, I moved it to “Vibe-coded games”.
The thread then got closed, and only later did I realise that you may have meant I should recreate it in the appropriate forum.
So my mistake was to simply move it to Vibe-coded rather than recreating it in there.
)
