Question about Download 2 special effects

[spenoza]

So, there's not a high-quality longplay of Download 2 up on YouTube, and I'm noticing it uses quite a lot of interesting background effects. I'm assuming it is mostly animated/dynamic tiles. Anyone have an idea what, from a programming perspective, is going on with some of this?

Putting it here instead of the PC Engine category in case there's something we can apply.

[Charles MacDonald]

Almost all these effects are done just by shoving data into VRAM as fast as possible, such as using a TIA instruction to transfer data from ROM (or RAM for CD games) to VRAM. The PCE can move a lot of data so a brute force approach like this is sufficient most of the time.

In terms of programming there are a lot of optimizations you can do. The big one is storing pre-scrolled copies of the graphics so you aren't wasting time doing costly rotations on the bitplane data every frame. You only need eight copies of your tileset which isn't too bad (or more, but it depends on how far your image can scroll before repeating).

When I developed the "canyon demo" with Fragmare, I had to push a lot of data around at 60 FPS. Some of the techniques that helped included:

- Storing pre-scrolled copies of data in VRAM (not ROM/RAM), and using VRAM to VRAM DMA (faster than CPU transfer) to copy the scrolled data to a 'work buffer', which was the set of tiles that was actually displayed on the screen. It wastes some VRAM but is incredibly fast, and that's important for games where your VBlank cycles are precious.

- Making the copies twice as tall so I could start a copy and have it 'wrap' without having to break it into two smaller copy operations. This was for vertical scrolling but the same concept applies horizontally. There are wait states from accessing the VDC and VCE, so accessing them as infrequently as possible really helps (another reason to use DMA over CPU transfers too)

- Similarly, arranging BAT tile numbers so data could be loaded sequentially in long bunches instead of having to do many small transfers.

- Switching to 512-pixel mode during VBlank, which runs the VDC twice as fast as 256-pixel mode and doubles the VRAM to VRAM DMA transfer rate.

- Packing graphics data into 2 bits so one set of tiles could store two different images, in half the space. This made a tremendous amount of time savings and was really instrumental to doing full-screen column scrolling. You can do similar things with four 1-bit tiles in a single 4-bit tile. When you have a good artist (I did!) the color limitations are not a big deal and the end result still looks vivid and has that 16-bit feel.

On this subject, I think the one game that is a tad exceptional is Ninja Gaiden which has terrible choppy crappy parallax scrolling, but it does it by updating the BAT frequently and not VRAM which is unique. Kind of the wrong way to go about it.. but it's sort of charming in its own weird way. So you can update the BAT, or the tile data in VRAM.

For the Bonk transparency demo I even used dynamic tiles for sprites, instead of the background. So these techniques can be applied in a lot of ways. But in the end it's always just transferring data to VRAM as fast as possible. Download 2 looks pretty cool BTW, I hadn't seen it before. Nice use of the hardware.

[Bonknuts]

Any particular part in the longplay video you want to ask questions on?

 Also, that ScHlAuChi guy *really* needs to lower the PSG volume in that emulator he's using (for CD games). Some of his videos are horrible because of it.

[Arkhan]

I love you CharlieMac

[spenoza]

I think he's using Magic Engine and FRAPS, and ME has totally messed up sound levels, IMO.

I see a lot of sprite effects in Download 2, but I'm referring specifically to 2 things. One is the level where you see scrolling columns through holes in the background. The other is an effect used in the original Download, also. When you enter the cyber levels and there are all those hsync scrolls at different speeds, when you move up and down they seem to adjust in height. The way it slows down when the screen fills up makes me think it's a little CPU intensive because good collision detection routines, on their own, shouldn't slow things down, and since the music is off the CD the only audio functions are sound effects.

[Arkhan]

Magic System card + PSG = fail.

It sounds awful.

[Bonknuts]

I saw some levels with see through areas with additional parallax layers and it's like Charles stated - dynamic tiles. I looked at the game a number of years back and don't remember if part of the cut out used sprites on the edges or not.

 As far as the scroll effect on the virtual levels (it's like that one level in Aldynes too), it's not exactly resource free. You do have the call over head of the hsync routine. And you do have the logic to build out the list too. But yeah, I wouldn't imagine it should slow down the game. I would hazard a guess that their over all code just wasn't tight enough to handle it. If you think about it, what is slow down? Your typical game usually waits for vblank (sets a var, then polls a that until it's clear), then when it passes - it proceeds to do game logic. But if the game logic fails just over the time mark, it'll completely miss the marker and won't register until the next frame. So technically, it could miss it by a simple/small 1000 cpu cycles (there are ~119436 cpu cycles in a frame for NTSC on the PCE/TG16).

[Charles MacDonald]

One is the level where you see scrolling columns through holes in the background.

This one looks quite nice, doesn't it?

When you do a VRAM animation that isn't square, there is some overhead of having extra tiles for the non-square areas where you mask out the animated part and insert the stationary part. It takes a fair amount of processing time and is seldom done.

But when you look at the video in 480p you can see they cheated. The circular part is all horizontal lines, nothing is really moving. It's not like they had to take their animation data, and then cut out a circular part and insert in the arch around it. So that part is "free". (assuming the video isn't omitting fine detail I can't see)

For the pillars they repeat vertically, so they don't need to animate those parts and just re-use the same smaller set of dynamic tiles. Plus the pillars appear every 'n' pixels apart, so they repeate the animated data horizontally as well as vertically. This means they just move a small part (consisting of a single pillar section and some green space to the right of it) to make all the pillars move.

The exceptions are the top and bottoms of the pillars which is just the same technique using different graphics. The "notch" where the foreground overlaps the background halfway up the pillar is the only time they have to composite anything with the animation data, but it's just a solid color (black) and the pattern is rectangular so they only have to cut out some bitplane data. You could almost do it as a palette technique given the lower color count and no modification of the animation data would be needed.

This is a good example of how to have dynamic tiles bordered by non-square shapes without going to all the trouble that it looks like.

when you move up and down they seem to adjust in height. The way it slows down when the screen fills up makes me think it's a little CPU intensive because good collision detection routines, on their own

Yeah this one is weird. Most games have very smooth vertical scrolling for that kind of effect, but it seems weird here. Throw in the slowdown and I almost wonder if it is a dynamic tile effect for the vertical movement (not the horizontal). All the tiles repeat so they'd just have to update VRAM for a vertical 'slice' of the background. Doing it this way would definitely lead to slowdown.

But either way they still didn't quite do it right. If you used pure scrolling they could have had smoother movement, and if it was a VRAM effect it could have been less choppy. Other games have done this better IMO, and given the other cool things in Download 2 I'm surprised this did not come off as effectively.