Briley Witch RPG Diary – 27/12/2017

I’m still working on my C64 RPG, still having loads of fun with it. It’s funny as I’ve been adding a lot of cutscenes into the game, but they are strangely enjoyable to code…

Day 2 sequence is mostly done, just a few tweaks needed, so I’ve been busy working on the Day 3 activities, a re-visit to see old witch Branwen, a visit to the blacksmith, plus a bit of potion mixing.

Good thing is when I can hook into the game code I’ve already written. Example: I coded the potion mixing a while ago, for Briley’s caluldron, brewing mint tea, plus using an old pot to mix a remove curse potion for Calibor. That’s the part of the game I’m coding now. All this takes place on Day 3 of the game, and it’s now working in game! I’ve coded the sequence where Calibor drinks the remove curse potion… Well, the reaction needs to be special! Ill be adding more effects, but for now, expect to see cartoon-style popping eyeballs!

Calibor drinks a potion…

Scrolling Problems:

I noticed a while back that my scroll routine had a horrible colour glitch, especially on the Baxter’s map. I’d put off fixing it due to wanting to advance the game some more…

Well, after a long soak in the bathtub this evening, I realised the problem. Checked the code, and I was right! Turned out to be due to the background object processing taking… er… a while.

You see, the game flow was:

• Main Loop start.
• Wait for Vertical Blank.
• Update scroll position and set hardware smooth scroll.
• Process all background objects, sort, and set hardware sprites.
• If needed, scroll the background character screen.
• If needed, flip screens, then scroll the colour RAM.
• Perform any non-time critical functions (scanning keyboard, moving player, checking triggers, checking doorways and portals).
• Jump to start of Main Loop.

With the background object processing taking longer than I had anticipated, it had pushed the colour RAM update well onto the screen time, thus causing some horrible colour tearing.

Didn’t take long to work out a solution once I’d thought about it. I had to split the code into time-critical sections, and non-critical.

New game flow:

• Main Loop start
• Update internal scroll position (not HW smooth scroll… yet).
• Process all background objects and sort sprites.
• Wait for Vertical Blank.
• Set hardware sprites.
• Set HW smooth scroll.
• If needed, scroll the background character screen.
• If needed, flip screens, then scroll the colour RAM.
• Perform any non-time critical functions (scanning keyboard, moving player, checking triggers, checking doorways and portals).
• Jump to start of Main Loop.

The result of the new game flow: everything is buttery smooth, and there’s not a glitch in sight!

The background scroll isn’t really time-critical as it’s just an update to the back buffer, so I might move that; I use double-buffering on my scroll routine with incremental updates over several frames. Advantage of this is when the colour RAM does need to be scrolled, I just need to flip the two screen buffers and use the available CPU time for the colour RAM scroll. Since this is started during the Vertical Blank period, it completes well ahead of the video beam painting the screen.

So I am real happy right now, hence this blog post. Feels so good to fix a major problem!

But, my remaining code RAM is now just under 6K, so I’ll have to keep an eye on that. Not too stressed at this point. The game is currently using ~16K of code, and I’ve reserved space for 22K. It’ll all fit… I know it will! My cutscene system is helping a lot with RAM usage, allowing me to offload a lot of code/data onto my cart file system; means I just need a hook in the game code RAM to load and trigger a cutscene.

I still need to detail my cutscene system at some point. Oh, another blog post for another time…

Right, back to coding the game…

Advertisement