Asking advice for psuedo-3D graphics.

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Post Reply
User avatar
AiNaKa
Posts: 11
Joined: Wed Mar 13, 2019 4:13 pm
Location: Joliet, IL

Asking advice for psuedo-3D graphics.

Post by AiNaKa » Tue Oct 20, 2020 10:42 pm

I'm looking to make a game for the NES. I don't actually know how to program in 6502 yet, so in the meantime, I'm doing more pre-planning if anything of how I want the game to appear graphically, and making music in famitracker.

Short introduction aside, I drew this animated square pyramid by hand, and I was wondering if it would be possible to animate this on NES hardware:
(I'm sure it is, but I also want to find out the easiest way one would go about doing it.)
The max dimensions of the pyramid are 7x7 sprites
Webp.net-gifmaker (5).gif
Webp.net-gifmaker (5).gif (2.09 KiB) Viewed 4273 times
My first assumption would be that it would be easiest if I made it so that it was animated on the background layer. Though, doing some research I found that there's a limit of 32 background tiles updating simultaneously, though I couldn't verify it concretely. Also, not to mention the fact that the scene I wish to present this animation already would have 180 background tiles in the bank to load from, and the amount of tiles that animation takes would far overflow that. From what I've heard, there are 2 banks to load tiles from, one for the background, and one for the sprites, each having a maximum of 256. Unless it's possible to load background tiles and sprite tiles from the same bank, I'm not sure.

On the other hand, I also found that the animation isn't too taxing on the amount of tiles rendered on the sprite layer at once, total and per scanline. The sprite bank would be fairly empty, so it would be easy to fit all the tiles in there. How easily do sprites update? Is there a limit to how many tiles on the sprite layer can update at once? I heard that there's two methods of animating something, and that's either by making the sprite switch to a different graphic, or by replacing the tiles in the bank for a different graphic, updating the ones already on screen.

In short, is there a way of animating this in the background that could work too that I might not know about? And if the mthods I thought of would already work, which would be most efficient?

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Asking advice for psuedo-3D graphics.

Post by lidnariq » Tue Oct 20, 2020 11:10 pm

First a step back: there are multiple different ways to animate things. Not all are suitable here, but:

1- You can change the specific tiles in the nametable
2- You can change the specific tiles and locations in the sprite table ("OAM")
3- You can change the appearance of tiles in the pattern tables
3a- And the pattern tables are stored in RAM
3b- And the pattern tables can be swapped around with a mapper
4- Palette cycling

Examples of each of those (among many many many others):
#1 the enemy ships Galaxian when they're in formation
#2 almost everything, but e.g. how Mario is animated in SMB
#3a: Battletoads
#3b: Batman: Return of the Joker or SMB2
#4: [?] blocks in SMB
AiNaKa wrote:
Tue Oct 20, 2020 10:42 pm
I found that there's a limit of 32 background tiles updating simultaneously, though I couldn't verify it concretely.
Under normal operation, a "typical" NMI handler can send somewhere around 128 total bytes to the PPU. This can be four whole rows of a background tiles, or eight patterns, and each time you update a different location it eats some overhead.

(Example: the game Galaxian can upload 28 bytes, plus 16 two-byte pairs, each vblank.)

Greater efforts can increase that total bandwidth to around 300 bytes, but it starts getting very silly.
Unless it's possible to load background tiles and sprite tiles from the same bank, I'm not sure.
Yes, you can draw from the same "side" for both, but at any given moment you only have a library of 256 tiles.

(Unless you use 8x16 sprites)

User avatar
AiNaKa
Posts: 11
Joined: Wed Mar 13, 2019 4:13 pm
Location: Joliet, IL

Re: Asking advice for psuedo-3D graphics.

Post by AiNaKa » Wed Oct 21, 2020 12:15 am

lidnariq wrote:
Tue Oct 20, 2020 11:10 pm
First a step back: there are multiple different ways to animate things. Not all are suitable here, but:

1- You can change the specific tiles in the nametable
2- You can change the specific tiles and locations in the sprite table ("OAM")
3- You can change the appearance of tiles in the pattern tables
3a- And the pattern tables are stored in RAM
3b- And the pattern tables can be swapped around with a mapper
4- Palette cycling

Examples of each of those (among many many many others):
#1 the enemy ships Galaxian when they're in formation
#2 almost everything, but e.g. how Mario is animated in SMB
#3a: Battletoads
#3b: Batman: Return of the Joker or SMB2
#4: [?] blocks in SMB
AiNaKa wrote:
Tue Oct 20, 2020 10:42 pm
I found that there's a limit of 32 background tiles updating simultaneously, though I couldn't verify it concretely.
Under normal operation, a "typical" NMI handler can send somewhere around 128 total bytes to the PPU. This can be four whole rows of a background tiles, or eight patterns, and each time you update a different location it eats some overhead.

(Example: the game Galaxian can upload 28 bytes, plus 16 two-byte pairs, each vblank.)

Greater efforts can increase that total bandwidth to around 300 bytes, but it starts getting very silly.
Unless it's possible to load background tiles and sprite tiles from the same bank, I'm not sure.
Yes, you can draw from the same "side" for both, but at any given moment you only have a library of 256 tiles.

(Unless you use 8x16 sprites)
I'm not sure exactly how this tile loading works. Are tiles loaded into the RAM from the cartridges ROM to be read from? And there's a maximum of 256 loaded into it at a time, but any layer can read from it, right? So in this situation, there are more tiles in the animation than can be loaded into the current tileset, so the best solution would be to place the tiles on the screen and update the tiles themselves that are stored temporarily in the tileset? But that method wouldn't be very possible, right? Each sprite is 16 bytes and if I'm updating over 30 sprites at a time, that'd be over 400 bytes already, and you said only 128 bytes can be sent typically.

Also, I'm sorry if I don't understand semantics or I'm using them wrong, I feel like I've seen a lot of names for the same thing when trying to research this topic so I hardly have any idea what to call anything and I think that's the most confusing part.

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Asking advice for psuedo-3D graphics.

Post by lidnariq » Wed Oct 21, 2020 12:36 am

AiNaKa wrote:
Wed Oct 21, 2020 12:15 am
I'm not sure exactly how this tile loading works. Are tiles loaded into the RAM from the cartridges ROM to be read from? And there's a maximum of 256 loaded into it at a time, but any layer can read from it, right?
In the NES, it can vary. The pictures in the individual tiles can be copied from the game's "program" ROM to the game's "character" RAM, or it can instead start in "character" ROM and the game doesn't need to do anything to get access to it.

In almost all other consoles, the "character" RAM is inside the console instead, and the game must copy data from the only ROM into it.

Ignoring mappers, the NES provides access to 512 total tiles at a time. This is grouped into two halves. A specific control in the NES lets you choose which half is used for "background" picture tiles, and entirely independently also lets you choose which half is used for "sprite" picture tiles.
So in this situation, there are more tiles in the animation than can be loaded into the current tileset, so the best solution would be to place the tiles on the screen and update the tiles themselves that are stored temporarily in the tileset? But that method wouldn't be very possible, right? Each sprite is 16 bytes and if I'm updating over 30 sprites at a time, that'd be over 400 bytes already, and you said only 128 bytes can be sent typically.
Well, one thing that helps is that your animation has a single color. This helps a little: because of how the NES stores images you can upload half as many bytes.

Another possibility is that when you're using sprites, you don't need to use unique tiles to store all of the line at the same time; instead you can have a sprite tile that's "line at this angle" and draw multiple sprites of that tile to generate a longer line.

(Also: configuring sprite location/color/properties doesn't count against the "typical" 128 bytes. It's its own 256 byte table)

User avatar
AiNaKa
Posts: 11
Joined: Wed Mar 13, 2019 4:13 pm
Location: Joliet, IL

Re: Asking advice for psuedo-3D graphics.

Post by AiNaKa » Wed Oct 21, 2020 1:13 am

lidnariq wrote:
Wed Oct 21, 2020 12:36 am
In the NES, it can vary. The pictures in the individual tiles can be copied from the game's "program" ROM to the game's "character" RAM, or it can instead start in "character" ROM and the game doesn't need to do anything to get access to it.

In almost all other consoles, the "character" RAM is inside the console instead, and the game must copy data from the only ROM into it.

Ignoring mappers, the NES provides access to 512 total tiles at a time. This is grouped into two halves. A specific control in the NES lets you choose which half is used for "background" picture tiles, and entirely independently also lets you choose which half is used for "sprite" picture tiles.

Another possibility is that when you're using sprites, you don't need to use unique tiles to store all of the line at the same time; instead you can have a sprite tile that's "line at this angle" and draw multiple sprites of that tile to generate a longer line.

(Also: configuring sprite location/color/properties doesn't count against the "typical" 128 bytes. It's its own 256 byte table)
From what I can tell, making it so that I draw sprites for only lines would probably save on how many tiles are stored simultaneously (not entirely a concern of mine, it should be able to fit in the 256 sprite tile limit), but would likely also require me to render more sprites at once, a lot of which overlapping. And even it sent only half the amount of data, it would still exceed 256 bytes. Do you think perhaps I'm getting a little too carried away and I should probably rethink my plan?

User avatar
tokumaru
Posts: 12003
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Asking advice for psuedo-3D graphics.

Post by tokumaru » Wed Oct 21, 2020 1:22 am

If all you want to do is show this rotating pyramid, this can easily be done using the MMC3 mapper with CHR-ROM. It can instantly switch chunks of 64 or 128 tiles, so a 7x7 tile area is no problem at all. What else is supposed to be on the screen, besides the pyramid?

User avatar
AiNaKa
Posts: 11
Joined: Wed Mar 13, 2019 4:13 pm
Location: Joliet, IL

Re: Asking advice for psuedo-3D graphics.

Post by AiNaKa » Wed Oct 21, 2020 1:40 am

tokumaru wrote:
Wed Oct 21, 2020 1:22 am
If all you want to do is show this rotating pyramid, this can easily be done using the MMC3 mapper with CHR-ROM. It can instantly switch chunks of 64 or 128 tiles, so a 7x7 tile area is no problem at all. What else is supposed to be on the screen, besides the pyramid?
I want the game to be in a JRPG format. I intend to use this graphic in a boss battle, so not too much will be happening on screen during a battle. I know that as for now, the tiles required to render the universal GUI and also the characters (they're not animated), is 180 background tiles and 19 sprite tiles (to overlay onto the characters for more color.) I didn't know about this, and if I can set aside a 64 tile area to indipendently animate that solves a lot of logical problems. There's certainly room on the screen for that. That aside, is this feature at all limited to exclusively background or sprite tiles, or can I use either one? I think sprites would be preferable as I have a lot more empty room to load the tiles into.

User avatar
tokumaru
Posts: 12003
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Asking advice for psuedo-3D graphics.

Post by tokumaru » Wed Oct 21, 2020 2:47 am

AiNaKa wrote:
Wed Oct 21, 2020 1:40 am
I didn't know about this, and if I can set aside a 64 tile area to indipendently animate that solves a lot of logical problems.
This is not a feature of the system itself, but of a very common mapper called MMC3. It was used in a ton of games, including SMB 2 and 3.
That aside, is this feature at all limited to exclusively background or sprite tiles, or can I use either one?
It works for backgrounds and sprites, no problem. The main limitations regarding the MMC3 and pattern switching is that one of the pattern tables is broken into 4 slots of 64 tiles, while the other is broken into 2 slots of 128 tiles (you get to choose which is which) and that the maximum amount of CHR memory is 256KB (or 16,384 tiles).
I think sprites would be preferable as I have a lot more empty room to load the tiles into.
I see that you're planning on using sprites very generously, with large objects (e.g. 7x7-tile pyramid) and multi-layered characters, but keep in mind that the NES can only show 8 sprites per line, so if you ever have the pyramid and a character side by side, you'll either get dropped sprites or flickering (flickering isn't automatic, it's a consequence of the programmer deliberately shuffling the priorities of the sprites so different ones are dropped each frame).

User avatar
Bregalad
Posts: 8008
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Asking advice for psuedo-3D graphics.

Post by Bregalad » Wed Oct 21, 2020 1:54 pm

I did a demo doing something similar.

However it relies on displaying only wireframe graphics, and needs a large black zone above the wireframe graphics which is used regularly as forced-VBlank.

If you were to display a rotating pentacle in a battle scene, the simplest would be to have everything pre-rendered. If it's very large however using some kind of wireframe engine might be worth it; but then it makes more sense if you use it for more than a single attack in the entiere game.
Useless, lumbering half-wits don't scare us.

GabeDuncan777
Posts: 2
Joined: Mon Nov 02, 2020 8:34 am

Re: Asking advice for psuedo-3D graphics.

Post by GabeDuncan777 » Fri Nov 27, 2020 11:45 am

AiNaKa wrote:
Tue Oct 20, 2020 10:42 pm
I'm looking to make a game for the NES. I don't actually know how to program in 6502 yet, so in the meantime, I'm doing more pre-planning if anything of how I want the game to appear graphically, and making music in famitracker.

Short introduction aside, I drew this animated square pyramid by hand, and I was wondering if it would be possible to animate this on NES hardware:
(I'm sure it is, but I also want to find out the easiest way one would go about doing it.)
The max dimensions of the pyramid are 7x7 sprites
Webp.net-gifmaker (5).gif

My first assumption would be that it would be easiest if I made it so that it was animated on the background layer. Though, doing some research I found that there's a limit of 32 background tiles updating simultaneously, though I couldn't verify it concretely. Also, not to mention the fact that the scene I wish to present this animation already would have 180 background tiles in the bank to load from, and the amount of tiles that animation takes would far overflow that. From what I've heard, there are 2 banks to load tiles from, one for the background, and one for the sprites, each having a maximum of 256. Unless it's possible to load background tiles and sprite tiles from the same bank, I'm not sure.

On the other hand, I also found that the animation isn't too taxing on the amount of tiles rendered on the sprite layer at once, total and per scanline. The sprite bank would be fairly empty, so it would be easy to fit all the tiles in there. How easily do sprites update? Is there a limit to how many tiles on the sprite layer can update at once? I heard that there's two methods of animating something, and that's either by making the sprite switch to a different graphic, or by replacing the tiles in the bank for a different graphic, updating the ones already on screen.

In short, is there a way of animating this in the background that could work too that I might not know about? And if the methods I thought of would already work, which would be most efficient?
Can you make a 3DNES emulator where you can select your own game?
Mod- fixed quote

Post Reply