Hello to everyone, did you see this video? How can this run on NES Hardware? I see a lot of objects, scale and scrolling.
https://www.youtube.com/watch?v=AA9zGxJij5g
It's a vertical shooter, so there isn't that much horizontal sprite overlap. The scaling it's just pre-rendered sprites for all possible distances. As for the background distortion, it's just manipulating the scroll several times per frame at specific scanlines, which's not hard at all, it just consumes a lot of CPU time, which could have a negative impact on a potential full game, since there wouldn't be much CPU time available to update all the game objects. It is a really cool effect, though.
For the background, this port of
Axelay is doing the same thing as the
special stage in Sonic 3D Blast: changing the vertical scroll on each scanline. It's conceptually not very different from hills in
Rad Racer and
Rad Racer II. But through the use of the $2006-$2005-$2005-$2006 sequence that was fully characterized by homebrewers after the end of the NES's original commercial era, the source image that is stretched can be bigger than was used in either
Rad Racer game. Likewise with Chris Covell's "Stretch" demo (ROM
here;
video).
All that said, the demo doesn't contain any graphical artifacts at all, it has collision of the ship with the asteroids (which move in sine wavy patterns), you can control the ship, you can shoot bullets, they destroy the asteroids (with particle effects) and there are sound effects for firing and destroying asteroids. When intergrating all that with animated CHR tables it looks even more impressive. So big kudos to
upsilandre for managing all that.
I think it is pretty usable for a real project, even if just a bonus stage.
my initial thought when seeing it on twitter is you can use the same effect in a more limited field (less cpu consuming) to have rolling storm clouds or flowing water/lava/slime in single screen boss rooms. Or a waterfall in a fisheye perspectived topdowner. Will keep fantasizing about it for the gothic platformer project but it is vertainly not within my capacity.
Also perfect for that mickey mouse moose chase / lion king gnu rampage
The
moose chase scene in Mickey Mania relies on mid-screen palette changes, which are not very doable on the NES, but a similar effect could probably be done with CHR bankswitching, like is the case in
Cosmic Epsilon, but with more detailed patterns. This is way more wasteful than doing it with palettes though, since you need to draw the entire floor for each horizontal pattern you want to use.
Yet After Burner for NES and the Iridion games for GBA did exactly that: the background is essentially a looping image sequence (not unlike a GIF).
I've been thinking about using banked chr-ram to simplify the parallax effects that rely on pixel shifted copies, which also means they take up less of the 256 tiles of space you can display at the same time. As a bonus you'd also be able to be able to use it for other effects such as timed GIF-style animations. It basically eats the profit margin/point of breaking even, though. You'd be betting on the game selling more copies than average.
32K CHR RAM is no more expensive than 8K, so long as your mapper can handle CHR banking.
The closest analogue from the commercial era was maybe
Recca's wobbly serpent stages, or maybe
Tetrastar?
A closer analogue to the perspective effect might be found in the 1978 arcade game
Sky Raider.
Surprised that this demo is using VRC's CPU cycle based "pseudo" scanline IRQ rather than MMC3... I thought this method resulted in compounding jitter errors for successive IRQ? Maybe I was mistaken about that behaviour of VRC.
VRC4/6/7 timer is a free-running /113.667 divider on M2. Once started, it doesn't accumulate error the way FME-7 and several other explicit CPU cycle counters do, though it isn't quite as useful for short periods on PAL NES. One advantage of VRC over MMC3 is you can reset it at any point in a scanline, and it'll always trigger at that horizontal position. This means no spin waiting for right point in the next scanline to squeeze off four writes. Instead, the IRQ can save A, squeeze off four writes, prepare for the next line, and return.
The VRC IRQ prescaler is cleared (synchronized) by writes to IRQ CONTROL, and that's not needed to change the delay to the next IRQ.
Oh, so using the bit terminology from
the wiki...
To do a stable repeating IRQ, you can write %001 to IRQ Control, then write to IRQ Acknowledge, and it will re-enable without interfering with the counter which has already been reloaded automatically?
Or you could even rewrite IRQ Latch at this time since you've got a huge 143 cycle margin to do anything before it clocks again?
:> I'd never deduced this was possible from the description on the wiki. I guess I've wrongly felt VRC IRQ was inferior to a scanline counter because of the jitter, but now it seems the opposite.