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

Moving Tiles Vertically?

Moving Tiles Vertically?
by on (#90382)
You know how in Super Mario Bros. 3 the first fortress had that ceiling that moved up and down? Well would the NES be able to move individual sections of tiles up and down independently of each other like this? Let's say for example the game in question has pillars that smash down at different times to kill the player in one hit and they're made up of background tiles. Is this possible on the NES?

by on (#90386)
If body of the pillar could be has a texture that is only 1 pixel tall, i.e. it could be stretched vertically easily, you can just update tiles of the bottom end of the pillar. You would need one set of tiles for the bottom end if the pillar is moves by a character per step, or few sets if you want it to make more smooth.

Here is example of a pillar that is moves one char per step, it uses just six tiles:

Image
Image

by on (#90387)
Possible, yes, but much harder to achieve than the first effect you mentioned.

To move the entire ceiling, a simple scroll split can be used, but in order to move individual sections up and down you have to edit the nametables and actually draw the pillars in the positions you need them.

To minimize the amount of tiles that need to be updated, most (all?) games that have done this used pillars without any vertical detail, so that only the top/bottom end had to be updated.

Here's an example of the effect: http://youtu.be/dWHPNnrTmKs?t=8m42s

by on (#90388)
Image

I was wanting to put something like this in my game that only has two frames of animation to appear like it's spinning and it kills the player on contact. I wanted a section where there are multiple saws like this and they move up and down independently of each other in a smooth slow process. They would of course be tiles rather than sprites because I know that would kill the NES instead of the player and make sprite flicker out the behind.

I would be willing to compromise if my expectations are unreasonable, such as make the thing move tile by tile (8x8 pixels I mean) really fast and then stop to take a break before it slams down again to appear it's moving smoothly albeit quickly.

If it helps to know, I'm not making my game in an NES rom, rather I'm making it an EXE and trying to keep the limitations of the NES in the game as accurately as possible but information on the hardware capabilities of the NES is scattered all over the place. I've even went so far as to put sprite flicker and slow down in my game if too many sprites are on the screen at once.

Would it be possible with that first technique Shiru mentioned?

by on (#90389)
This graphics would only move by attribute grid, i.e. 16 pixels, because it uses more than 4 colors.

The reason why you need to not have vertical detail is that it allows to update only end of the pillar, instead of all the tiles of a pillar - there is a rather tight limitation how many bytes (tiles) in a nametable is possible to update per frame.

by on (#90390)
That saw would be pretty tough to implement on the NES... You'd have to redraw the entire saw every frame, which means a lot tiles have to be changed. 1 or 2 saws would be doable, but more than that is pretty unrealistic for the NES.

by on (#90392)
I saw more than three distinct colors in the saw blade. The NES grays are approximately #666666, #b2b2b2, and #ffffff.

The nametable is a grid of 32x30 tiles. There is enough video memory bandwidth to change 128 tiles in one frame, or 160 in a few special cases, in addition to uploading the sprite display list to OAM. This count includes the scroll seam, the horizontal or vertical strip of tiles changed on the nametable whenever the camera moves. If you shrink your buzz saw to 64x64 pixels, or about 1/4 of the width of the screen, that's 64 changed tiles. Another option is to make it a flat, reciprocating blade that moves to the left and right by a couple pixels as two frames of animation; that would cut your updates down to about 24 tiles.

If you move things using two different sets of colors in units of 8x8 pixels, there will be "attribute clash", or an artifact on the seam between two differently colored areas. These artifacts can be seen in boss battles in Cabal if I remember correctly. I'd turn the shaft gray to avoid this, but if you insist on it being green, you can cover up the seam with a sprite, as is seen in the title screen of Tetris 2 and several places in Bucky O'Hare.

Do you have a screenshot so that we can make other recommendations on NES authenticity or possibly even an actual port to the NES once the PC game is done?

by on (#90393)
I don't have a screenshot yet, I just started working on the stage this is to take place in.

OK well I shrunk the saw blade down to 64x64 and changed the color of the shaft to the same grays and I didn't realize it had too many colors even though I knew there could only be three colors and the background color, so I got rid of one of the grays. This will take place on a black background of course.

by on (#90399)
If there was a routine dedicated to the sole purpose of drawing blades, and the blades were 64x64 pixels, you could probably update 3 of them in a single frame, and still have time left for updating the sprites.

If you update each blade every other frame, (i.e. at 30Hz) you could animate 5 blades (the most that would be visible in a single screen) and still update a column of tiles and attributes for scrolling left and right.

The blades will still have to move 8 pixels at a time, unless you dedicate more tiles for the intermediary steps of animation.

by on (#90401)
Well while I'm asking about NES capabilities, I might as well ask this too. Does anyone know what capabilities the Mega Man NES games have that an NES game without an expansion chip doesn't have? I'm trying to make a game along those lines. I could've swore the NES Mega Man games use an expansion chip of some kind.

by on (#90404)
Basically, only 10.5% of the NES/FC library doesn't have any sort of expansion chip.

So yeah all Mega Man games uses expansion chip (mappers), but they use common mappers which just allows more ROM. Mega Man 3-6 uses the MMC3 which has a scanline counter which makes raster effects easier.
Nothing all that special if you ask me.

by on (#90407)
That's true in one sense. So let me try to formalize this concept of "nothing all that special". The MMC1 and the discrete logic mappers aren't really "expansion chips" in the same sense as the coprocessors in Super NES carts. The discrete mappers and MMC1 just allow accessing more memory, not performing effects that would be impractical without such a chip such as multiple raster splits. When I hear "expansion chips" on the NES, I mostly think of IRQs, fine grained CHR ROM bankswitching, Famicom expansion sound, and other more advanced features. According to the table you linked, MMC3 (#4) and MMC5 (#5) together make up only 25%, while MMC1 and the most common discrete logic mappers make up over 60%.

by on (#90409)
I don't know much about the SNES but I think all of it's expansion chips are kind of microcontrollers runs programs.
In that case, I don't think any NES cart have this, even the Powerpak has no microcontroller but an FPGA which is not the same.

by on (#90410)
There are expansion chips on the NES in terms of the sound, as part of a mapper. They are not microcontrollers, but they certainly add something that the system itself can't do.

by on (#90415)
Bregalad wrote:
[Super NES] expansion chips are kind of microcontrollers runs programs.
In that case, I don't think any NES cart have this

Nothing sold to the public during the NES's commercial era has this, but both the Wide Boy and the RetroVision have a Game Boy CPU and PPU rendering to CHR RAM.

by on (#90416)
Shiru wrote:
This graphics would only move by attribute grid, i.e. 16 pixels, because it uses more than 4 colors.


You could overlay sprites over the green part in the middle, then be able to move it in units of 8 pixels.

by on (#90417)
In the definition of the problem there are few such objects on the screen, and the green part is 2 sprites wide - so objects at a scanline could take 6-8 sprites, i.e. chances of flicker are great. I would guess that such flicker of part of an object is not much better than flicker of the whole object.

Well, it is possible to combine both tiles with attributes and sprites to cover bottom end of the green part in cases when it is goes mid-attribure. This would reduce chances of flicker if the objects are desynced in a special way.

by on (#90422)
I kinda think the blade picture from OP is just for reference; not expecting it to actually be that size/detail.

You could do a lot of the animation work with bank switching, especially on something like MMC3 with its 1k banks. You could have four versions of the blade, each 2 pixels apart vertically, and every second version the blades are animated to a different position. Then you only have to update the background tiles for a blade every fourth frame and you get smoother motion.

If the blade is 4x4 tiles, you could fit four ongoing animations in a 1k page that you have four versions of that you switch each frame. 2 of them on the page are moving down, and two moving up. If you're really careful with timing you can have four blades running at once and only have to update the background tiles for one of them per frame.

Perhaps just do the green shafts with sprites? since they're vertical they don't eat -too- much of that 8-sprites per line limit.

by on (#90426)
rainwarrior wrote:
I kinda think the blade picture from OP is just for reference; not expecting it to actually be that size/detail.

I think that's the actual sprite he wants to use.

Quote:
If the blade is 4x4 tiles

The blade was originally 96x96 pixels, and he already agreed to reduce them to 64x64. That already needs an entire 1KB chunk of CHR for each blade, and that's without even considering that you actually need 8x9 tiles for the smooth movement. At that size, this animation is not feasible with CHR bankswitching.

by on (#90428)
What if the circular interior of the blade, perhaps even the teeth, is done with palette cycling. An 8x8 blade then would not require any tile updates to visualize rotation. The vertical displacement could be done as described with 1, 2, 4, or 8 unique 1KB CHR-ROM banks, depending on how smooth the displacement is wanted. I think the drama of a rapid descent could be achieved with a 4-pixel drop (so 2 CHR-ROM banks). Then you could make a "ratchet" sound to accompany a slow ascent with the same 4-pixel steps as was used in the descent...but slower! After typing this all up I kinda want to tryit!

by on (#90430)
cpow wrote:
The vertical displacement could be done as described with 1, 2, 4, or 8 unique 1KB CHR-ROM banks, depending on how smooth the displacement is wanted.

The problem with this approach is that he said there will be a number of saws working at once, moving independently from each other, meaning they can't share the same patterns if you use this kind of smooth displacement. Each saw would need it's own CHR chunk, which is not really possible for 3 or 4 saws (there will be no patterns left for anything else).

However, if they all move at the same speed, and there is no pause when they reach the top or the bottom of the area they cover, they could all share the same patterns, even if each one is at a different height and has a different range.

by on (#90431)
Well, if you have 4 pixels of padding on either side you don't need the 9th row of tiles. For a larger blade you can literally cut the corners as well, so there's another few tiles you don't need.

Anyhow, this is all kinda moot, as the OP isn't actually trying to implement it on an NES anyway. It's probably doable with a some care, as we've been mentioning, but I can't think of any game with large background blocks moving smoothly and independantly, even if it is possible.

Castlevania III's gears (which are a combination of bankswitching and sprites for the gear-teeth, if I recall) come to mind, but they don't move around. If you're going for a typical NES look for this sort of thing, look at Castlevania's vertical crushing spikes:
http://www.youtube.com/watch?v=5LvfHnD9IjI#t=1m50s

For non-independent motion with a vertical scrolling split, Super Mario 3 or Mega Man 4 are pretty good examples:
http://www.youtube.com/watch?v=QRk-gnLMPQk#t=1m55s

If you're trying to make something that looks authentic, I'd stick to things that were actually done, but if you don't, probably only a few people would notice anyway.

It might be fun to try and actually implement it for NES though.

by on (#90432)
Combining everything that has been said so far with a few limitaitons you can do 5 blades at 60Hz.

If you are willing to drop you saw blade size fit in 7x8, If you could offset your sawblade movements always have different ypositions modulo 8

You could use 8 1k banks for single pixel offsets within 8 pixels.
Each frame of animation of the blades would be another 8 banks.
Each of the 4 most onscreen blades would use different 1k banks character sets and you would only update the nametables when crossing an 8 pixel boundary. Since the blades have the offset y modulo 8, only one blade nametable needs to be update per frame which would be a 72 character update. For the most offscreen blade, you could use sprites, which would be at most 4 sprites wide, by 4 sprites high (8x16 sprites.)

Of course you'd want to use mmc3 scanline interupts to change the character sets before and after the blade section in order to have more tile variety.

Fewer blades onscreen at a time is probably the easier way to go though.

by on (#90435)
I'll try a few of the ideas tossed out here and see which one works best. I'm leaning towards a scrolling split but I'll have to actually see how it looks in practice to know if that's what I want in the end.

by on (#90437)
rainwarrior wrote:
It's probably doable with a some care, as we've been mentioning

Agreed. It's not something I'd have fun implementing though!

Anyway, even when Nintendo themselves want to simulate the look and feel of the NES (with Mega Man 9 and 10) they end up breaking several rules. The fades are completely smooth, too many colors/palettes, too many unique tiles, extremely large objects that are not part of the background, and so on.

I guess that if it's not really for the NES, there's no reason to be so strict about these little details. I bet that more than 90% of the people that will play your game will not be able to spot the things that are not actually doable on the NES.

by on (#90442)
Just a quick correction. Megaman 9 and 10 were made by capcom. Nintendo had little to do with it.

by on (#90443)
Yeah I know 90% of people probably won't notice and I know Mega Man 9/10 would've required like 50 PPUs to work on the NES but I'm trying to keep as strictly to the NES limitations as possible as a sort of challenge to myself, partly for fun. I am trying really hard to keep in mind stuff like the game can only use four palettes each for sprites and tiles, each with three colors and a transparency color but sometimes I goof, like with the saw up there.

However I'm not being insanely strict with things like keeping only so many unique groups of 4X4 tiles in my editing and having so many unique tiles because this would be too meticulous for me to care to do.

Speaking of fades, I can make fades that only use the NES palette that I loaded into the game, however, if I want to use hardware acceleration mode which is Direct 3D 8, it doesn't support 256 color mode so then the fades become smooth and in true colors, since for the fading I basically made a huge black sprite that covers the whole screen and uses alpha values. So I guess you can see how this is a real dilemma for me. :X I'm gonna try to experiment with pixel shaders to see if I can still get the NES style fades that only use the palette.

by on (#90444)
Just change alpha value in the fade from 1 to 0 in four large steps, it will be much more NES-like than a smooth fade.

by on (#90456)
DirectX does have a palette texture format, but I'm not sure if it's widely supported. Alternatively you could write a pixel shader with four colour constants that are blended via the RGBA values in a texture.