This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES Axelay Tech Demo

NES Axelay Tech Demo
by on (#236902)
Hello to everyone, did you see this video? How can this run on NES Hardware? I see a lot of objects, scale and scrolling. :shock:

https://www.youtube.com/watch?v=AA9zGxJij5g
Re: NES Axelay Tech Demo
by on (#236904)
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.
Re: NES Axelay Tech Demo
by on (#236905)
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).
Re: NES Axelay Tech Demo
by on (#236912)
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.
Re: NES Axelay Tech Demo
by on (#236916)
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
Re: NES Axelay Tech Demo
by on (#236919)
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.
Re: NES Axelay Tech Demo
by on (#236923)
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).
Re: NES Axelay Tech Demo
by on (#236925)
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.
Re: NES Axelay Tech Demo
by on (#236926)
32K CHR RAM is no more expensive than 8K, so long as your mapper can handle CHR banking.
Re: NES Axelay Tech Demo
by on (#236932)
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.
Re: NES Axelay Tech Demo
by on (#236935)
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.
Re: NES Axelay Tech Demo
by on (#236936)
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.
Re: NES Axelay Tech Demo
by on (#236939)
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.