Gradius NES vs Arcade

[Aggro Sky]

A couple friends of mine collaborated on a video where they did a pretty in depth analysis on the differences between Gradius arcade and the NES port. Figured I would drop it here for your viewing pleasure:

https://www.youtube.com/watch?v=JEfG0rer3CA

[Sumez]

Very good video!

One minor point - there seems to be a misconception going around that classic NES games getting rid of all background elements before introducing large bosses is done to prevent slowdown.

While I guess you could say that's still the end goal, the NES only have one layer of background, and a fully drawn background isn't any slower than a black one. The reason why these kinds of bosses are fought on a single color background, is that the game actually uses the background layer to display the boss graphic instead of taking from the NES's sprite limit, and employing scrolling to make it move around.

[copy-paster]

Haven't watched the video, but are they use the 'Nemesis' arcade instead of 'Gradius' ?

[SMC]

Looks like it.
AFAIK the US Nemesis is the only one with the mercy capsules after death. EU Nemesis is pretty much the same as Gradius.

[MintyTheCat]

Very good video!

One minor point - there seems to be a misconception going around that classic NES games getting rid of all background elements before introducing large bosses is done to prevent slowdown.

While I guess you could say that's still the end goal, the NES only have one layer of background, and a fully drawn background isn't any slower than a black one. The reason why these kinds of bosses are fought on a single color background, is that the game actually uses the background layer to display the boss graphic instead of taking from the NES's sprite limit, and employing scrolling to make it move around.

Yes, that is true, but if you think of it in terms of tiles and memory then you need to have less tiles in memory if the background is one tile so that may well be a reason.
You could imagine that when the boss appears it will occupy many blocks in memory.

[neorocker]

Yes, that is true, but if you think of it in terms of tiles and memory then you need to have less tiles in memory if the background is one tile so that may well be a reason.
You could imagine that when the boss appears it will occupy many blocks in memory.

that's correct on a technical level, but not the reason it was ever done. if you keep a background there and introduce a background-based boss on it then the entire background will have to move around with the boss, which looks silly, and the boss will have to have a ton of special tile variants to match up with the background in question if it's going to move. it's not a memory thing. there are NES games that unload *tons* of different tiles to fill the screen with sprites and extremely varied backgrounds, and that's not the issue here. it's strictly that there is one layer available and big "sprites" like these had to get tossed onto it.

[Sumez]

Well, yeah, unless you're being really creative and somehow manage to make the rest of the background out of the tiles that make up the boss graphic
But even if you did that, you would scroll the background along with the boss when it moves. I think the best the NES can do in this regards is horizontal scrolling of only a chunk of the a background layer. Even that is probably still a complicated thing to do, though - I'm not too well versed in NES hardware.

edit: Neorocker probably said it better than I did

[BrianC]

There's also a hack that makes the FC Gradius more like the arcade version and even adds vertical scrolling to certain stages.

[Aggro Sky]

There's also a hack that makes the FC Gradius more like the arcade version and even adds vertical scrolling to certain stages.

THAT is interesting!

[MintyTheCat]

Yes, that is true, but if you think of it in terms of tiles and memory then you need to have less tiles in memory if the background is one tile so that may well be a reason.
You could imagine that when the boss appears it will occupy many blocks in memory.

that's correct on a technical level, but not the reason it was ever done. if you keep a background there and introduce a background-based boss on it then the entire background will have to move around with the boss, which looks silly, and the boss will have to have a ton of special tile variants to match up with the background in question if it's going to move. it's not a memory thing. there are NES games that unload *tons* of different tiles to fill the screen with sprites and extremely varied backgrounds, and that's not the issue here. it's strictly that there is one layer available and big "sprites" like these had to get tossed onto it.

Does the FC/NES have an implicit tile priority like say the Megadrive's VDP so that the last written is 'on top' of the earlier tiles? I would think if it has no priority due to the hardware then it would be up to the programmer to write the tiles in order.

I am not too familiar with the NES/FC on a technical level so you'll have to bear with me here.

[Sumez]

Does the FC/NES have an implicit tile priority like say the Megadrive's VDP so that the last written is 'on top' of the earlier tiles? I would think if it has no priority due to the hardware then it would be up to the programmer to write the tiles in order.

I'm pretty sure sprite drawing priority is just determined by their location in the sprite memory (OAM). For backgrounds, there's only one layer, as already stated, and it's always behind the sprites.

[trap15]

it's always behind the sprites.

I believe the BG tiles actually have a flag for whether they're above or below sprites. Otherwise how could Link go "under" the room doors in Legend of Zelda?

Does the FC/NES have an implicit tile priority like say the Megadrive's VDP so that the last written is 'on top' of the earlier tiles?

I have literally no idea what you mean by this, as I've never seen any hardware behave like this. Partly due to how complicated and RAM-heavy such functionality would be, as well as how not-useful it'd be.

[BIL]

Arcane dark magick like this is why pseudo-parallaxed FC stuff like Bucky O'Hare, Ninja Gaiden III and especially Metal Storm blow my little mind.

Animated GIF 1.8mb~

Spoiler

[Sumez]

it's always behind the sprites.

I believe the BG tiles actually have a flag for whether they're above or below sprites. Otherwise how could Link go "under" the room doors in Legend of Zelda?

Right, didn't think about that. Well, it's the sprite that has a flag for drawing it below the background, rather. It's not a separate sprite layer though, which is what I meant A sprite set to display below the background can still be drawn "in front of" one that's in front of the background, which will result in a masking effect. Very useful.

I think that particular effect (Link entering doors) is actually achieved by placing 8 transparent "dummy" sprites on the same row, forcing the scanline sprite limit to kick in. Only reason I'd know that though is that it's one of the commonly referred examples of that effect.

Arcane dark magick like this

Or as it was called at the time, "MMC"

[trap15]

Arcane dark magick like this

Or as it was called at the time, "MMC"

Ostensibly it is the MMC allowing it, but the real magic is that those mappers are using CHR-RAM instead of CHR-ROM. The tiles being in RAM instead of ROM means they can modify the tiles themselves in real-time, allowing for such wild trickery. Only some of the movement is done with normal BG scrolling, the parallax part is done with tight code modifying the tiles on the fly. Truly arcane magic.

[MintyTheCat]

Does the FC/NES have an implicit tile priority like say the Megadrive's VDP so that the last written is 'on top' of the earlier tiles?

I have literally no idea what you mean by this, as I've never seen any hardware behave like this. Partly due to how complicated and RAM-heavy such functionality would be, as well as how not-useful it'd be.

Think of the VDP on some machines as regarding the 'last tile written' as being the higher 'priority' (disregard any plane rules here for now) so if you were to place tile 1,2,3..N at the same location the last tile written would be the only visible tile on the screen at that location - the others would be 'hidden'. If any tiles have their priority bit set then they would 'win' and not matter what order they were written the tile with the priority set would be the only one visible at that location. Does that make sense to you now?

It is useful in that the developer decides to put the most important sprites onto the screen last - such as the player's sprite and any bullets and that sort of thing. It also helps when multiplexing sprites.
Most of my homebrew activities have been on the Megadrive and as such I am most familiar with the MD's VDP.

[Sumez]

You have to remember you aren't using external software or libraries here, you are writing directly to the RAM, and in the case of sprites, the OAM section of the PPU memory. It's a set list of 64 sprites, so the only "order" is the order they are always stored in the OAM. Sprites stored in the lower indexes will be displayed on top of later indexes. I think this order also dictates what sprites are visible when the limit of 8 sprites on a scanline is reached, but I could be wrong here. (I believe that's why flickering occurs, games cycling sprites around the OAM, to avoid certain sprites being invisible 100% of the time)

The priority bit only works in regards to the background tiles. Individual sprites still overlap based on the OAM order, even if it doesn't make sense from a physical perspective (which is why you can achieve the "masking" effect I mentioned)

As far as I can tell from some quick googling, the MegaDrive VDP works in exactly the same way?

[trap15]

if you were to place tile 1,2,3..N at the same location the last tile written would be the only visible tile on the screen at that location - the others would be 'hidden'.

If you're talking about backgrounds, that's an extremely obtuse and confusing way to describe "they're at the same RAM address so writing a new one replaces the old one". If you're talking about sprites, you're just wrong unless the higher sprite has no transparent pixels (which still isn't even internally represented as "hidden", it's just drawing over it).

It is useful in that the developer decides to put the most important sprites onto the screen last - such as the player's sprite and any bullets and that sort of thing. It also helps when multiplexing sprites.

Some VDPs draw sprites in a way where the first object has highest priority, and some draw them where the last object does.

I think this order also dictates what sprites are visible when the limit of 8 sprites on a scanline is reached, but I could be wrong here. (I believe that's why flickering occurs, games cycling sprites around the OAM, to avoid certain sprites being invisible 100% of the time)

Correct. These VDPs are not particularly intelligent, they just iterate through the object RAM and draw as they see them (in cases where OBJ0 has highest priority, a 'filled' pixel will never be overwritten; when the last object is highest priority, all pixels are written every time). So if you want to surpass the per-line limit you have to show it a different order (and this is why sprites on old consoles would commonly appear to alpha blend against each other; the OBJ RAM cycling causes priorities to change as well).

[MintyTheCat]

if you were to place tile 1,2,3..N at the same location the last tile written would be the only visible tile on the screen at that location - the others would be 'hidden'.

If you're talking about backgrounds, that's an extremely obtuse and confusing way to describe "they're at the same RAM address so writing a new one replaces the old one". If you're talking about sprites, you're just wrong unless the higher sprite has no transparent pixels (which still isn't even internally represented as "hidden", it's just drawing over it).

This is not confusing. They do not need to be at the same RAM address - rather the tile-map entry per update on a scanline or using more than one plane with a priority bit set for one tile - by the rules one plane would have a higher priority.

You can find out how the MD does it here:

http://md.squee.co/VDP

Here's the NES/FC's PPU here:

http://wiki.nesdev.com/w/index.php/PPU

It is useful in that the developer decides to put the most important sprites onto the screen last - such as the player's sprite and any bullets and that sort of thing. It also helps when multiplexing sprites.

Some VDPs draw sprites in a way where the first object has highest priority, and some draw them where the last object does.

I think you are missing the important point here: the order once known: priority on first written or priority on last written once known yields the same functionality - it allows the developer to produce effects and to state how they want to have the hardware act. One way or the other way is not important here, Trap, what matters more over is that it is possible through the action of the hardware and understanding on the developer's part.

[Sumez]

I still have absolutely no idea what you're talking about You're not calling a function here, you're just writing directly to your RAM. Why does the order in which you write it matter? How could it, even?

Unless of course you're writing to the same address, as trap15 said, which obviously overrites what was already there (rather than making anything overlap the other), which has absolutely nothing to do with the PPU or VDP, but is just... well, how things logically work.

Remember, you don't immediately draw a sprite when you're writing it to the OAM, you're sending the information to the PPU during vblank, and it will then draw them one scanline at a time. Some hardware lets you write to the sprite memory while drawing the screen, allowing for more visible sprites than the system actually allows, but the NES definitely doesn't do that, and I don't think the MegaDrive does either?

[MintyTheCat]

I still have absolutely no idea what you're talking about You're not calling a function here, you're just writing directly to your RAM. Why does the order in which you write it matter? How could it, even?

Some hardware lets you write to the sprite memory while drawing the screen, allowing for more visible sprites than the system actually allows, but the NES definitely doesn't do that, and I don't think the MegaDrive does either?

Yes, the MD hardware does behave like that but you will only realise this if you have worked with the real hardware and not exclusively with Emulators.
As scary as it is, I stop the MD's 68K from executing but the VDP continues functioning so you will see the H/V-Counter spin up and down whilst the program running on the 68K does nothing and stays like that until I ask it to continue. Again, you will not see this happen on an Emulator but you will see this on real hardware.

I think you chaps may have spent more time developing using Emulators than using the real hardware. I actually use both but the timing critical code I have to test using Logic-Analysers and UMDK.

By all means give it a go with the real hardware.
Try writing tiles to VRAM, then setting the tile-map entries before a vertical-sync and then try the same action after a v-sync and note the differences each time.
Try altering when you set priorities too and see how well the machine's VDP 'keeps up' with your changes.

The important thing to remember at all times is that: Emulators lie to you I have not found any Emulator that has correct colours and has accurate timing. Emus are useful for some things though but you cannot throw the real hardware out when you are working on things.

We are talking about a few things here:

1. order that we write tiles to VRAM.
2. when we write time-map entries.
3. when we write to the sprite table.
4. priorities set for tiles and the rules given to VDPs that have planes.
5. timing and how it relates to what the machine does and what we see on the screen.

It is actually good that these things are being discussed as most of the time very little technical discussion occurs on this forum, cheers

[Despatche]

If emulators having to lie bothers you so much, why aren't people like you trying to write better emulators and fix the problems that require lying about? This hardware isn't going to last forever, and a lot of the optical disc-based hardware is already starting to die.

[trap15]

Emulators aren't lying, he's off his meds.

[Sumez]

Emulators can cause lots of false positives, though I'm not sure how this plays a role in the subject (which again is pretty far removed from Gradius at this point).
Also, emulators like FCEUX and Nestopia are created exactly with the purpose of actually acting completely like the real hardware (and even then there's probably stuff like hsync timing fluctuation that can be misleading if you're doing some crazy rendering tricks), and there is really no reason to ever use anything else.

That said I've been reading a lot into NES hardware since the discussion started, and it seems you CAN actually write to the OAM memory using a register on the PPU, similar to writing to the nametables and palettes. So yeah, if you use that, then technically, the first sprite that you write will be the topmost displayed one (even if that's still a misleading way to think of it). It's just that no one should ever do that, especially not for all 64 sprites. You'd use the DMA that copies all 256 bytes of a page in your RAM directly to the OAM. I can't think of a single reason to use the write register, it's a complete waste of vblank time.