Posted By
seff
on 2023-06-01
00:09:23
 |  Terra Cognita and flickering enemies
I have always been amazed by Terra Cognita. It’s a dynamic shoot'em up game with fast-paced hardware scrolling and great SFX. But why do the enemies flicker? Have you ever been curious?
I disassembled the game and started studying its internals. The main game cycle gets invoked at raster line 192. The graphics uses the MCM character mode. The main sprites consist of the following characters:
@, a, b; c, d, e; f, g, h (ship)
r, s, t; u, v, w; x, y, z (enemy #1)
i, j, k; l, m, n; o, p, q (enemy #2)
^ (fire - it only has one horizontal position)
V, W, O (energy bar)
F, G (ship lives – in hires, I didn’t know you could mix MCM and hires characters together)
The sprites move 4 positions horizontally (MCM) and 8 positions vertically. Vertical hardware scrolling is used and then the character map gets copied one character line down. Now, the ship is redrawn first. The energy bar is software scrolled. The ship lives are software scrolled. Then the fire and enemies are being redrawn. And this is where the rubber hits the road: race conditions.
The code is not efficient (I assume because of memory constraints) and quite often, the enemies are being redrawn while the horizontal raster line (refresh) has already passed them. As a result, all too often there are no enemies, and/or they are redrawn only partially.
Can we fix it?
All the sprites could be pre-computed, pre-fetched and pre-processed. The heavy lifting work could be processed while the screen is being drawn and access to the video memory could be limited to raster line 192 and beyond. Possibly double-buffering techniques could be used.
What do you reckon? Any idea? I don't have much experience with programming software sprites and it is still on my long-term todo list...
Terra Cognita video #1
Terra Cognita video #2
|
|
Posted By
Luca
on 2023-06-01
02:09:22
 | Re: Terra Cognita and flickering enemies
Love Terra Cognita too, I second you.
At the moment, I'm away of any kind of real computer or emulator and can't test it. But reading your post, one thing comes in my mind clearly: if the main routine mainly inlcude the softsprites' drawing subroutine, and the former starts to calculate basically from the last row of the visible screen, occurring in any case in a sprite flickering at some point, then could be possible that this already represents the less annoying choice to display the sprites while a vertical scrolling occurs too, simply due to the laboured code needed.
I confirm what I said in brief: mine is a theoretical consideration, not even a real thing, hence: testers, ahoy! 
EDIT: mmmh... Watching your videos, it doesn't look like a flickering driven by scanline's misplacement, it looks like a flaw in the sprites' calculation, which consequently burden over it.
|
|
Posted By
seff
on 2023-06-01
04:01:56
| Re: Terra Cognita and flickering enemies
It's apparently more visible in Yape, in Monitor, with Step Over (Page Down).
There are 3 symptoms:
1) Both enemies disappear
2) One enemy disappears
3) One enemy is not fully drawn.
|
|
Posted By
Gaia
on 2023-06-01
16:55:44
| Re: Terra Cognita and flickering enemies
Have you tried playing around with the IRQ line? Perhaps bringing it a bit to a lower rasterline resolves the issue. Simply because the drawing logic comes only later in the routine.
On a slightly unrelated note, Skramble flickers as well, though there the situation is a bit more tricky because of the horizontal scroll in multicolor mode. It even skips a phase of drawing in one frame. Kikstart however sports a perfect multicolor scroll.
|
|
Posted By
seff
on 2023-06-02
09:03:20
| Re: Terra Cognita and flickering enemies
I tried to change the value at:
>205e
>2158
to #$b0, #$a0, #$90, #$80 respectively
and the enemies still flicker. Of course the lower third of the screen now starts to tear.
The main drawing subroutine is called at
$20db jsr $25ae
|
|
|
