Not too good with 8K CHR RAM, though, as there are only two banks, so HUD will either take space from background tileset or sprite tileset.

Pretty easy/free to have >8KB of CHR-RAM with a homebrew.

In theory yes, just use larger SRAM chip, which is normally 32K these days, with any CHR-ROM mapper. However, practically - is there any emulator that supports CHR-RAM bankswitching, to be able to develop software for this hardware configuration?

Not too good with 8K CHR RAM, though, as there are only two banks, so HUD will either take space from background tileset or sprite tileset.

Pretty easy/free to have >8KB of CHR-RAM with a homebrew.

In theory yes, just use larger SRAM chip

That can work for a status bar. But for using more tiles within a scene, you'll need either separation of tiles into horizontal bands (to allow for mid-screen changes) or ExGrafix.

Quote:

However, practically - is there any emulator that supports CHR-RAM bankswitching, to be able to develop software for this hardware configuration?

Any emulator that supports Videomation or Oeka Kids supports large CHR RAM. Any emulator that supports Pinbot or High Speed supports splitting the address space between CHR ROM and CHR RAM. And I'm less than a week from releasing a multi-mapper test ROM that looks for (among other things) NES 2.0 support with 32K CHR RAM.

Been a while since I worked on this (jeez, over 2 years D:) and felt the urge to get some NES action going today so I updated this and added quite a few things. I am at 221 chars atm. Hope I'll find more time this year to work on this project more and be a bit more active on here in general

Also I wanted to ask, I am basically playing pretty loose when it comes to meta tiles. There are not many, because I use a lot of the dirt tiles (and actually some others as well) in multiple spots to break things up a bit, not really making stricts 16x16s and sticking to those.

Also, the chars can have 256, and then another 256 for sprites, right?

Also, the chars can have 256, and then another 256 for sprites, right?

Yes.

If you're doing CHR RAM, you can have more than 256 background tiles if some tiles are used only at the start of a level and others are used only at the end. There just has to be a 264-pixel (33-tile) gap between one tile and another tile that reuses its tile number.

If you're worried about metatile bloat, you can have the game randomly pepper tiles in specific positions with alternate versions as the engine draws the map to video memory.

I was wondering about the swapping of tiles during the level. For example the part between the mountain sky and the demon statue is wider than 256 pixels. So that would work to optimise out the unused sky stuff for example.

I just wanna chug along doing gfx for this until I have a lot more time, and then get someone to help get it done. thefox actually already did some test stuff back in 2013. And I know some really good Japanese chip musicians, too. But yeah, time.

Edit: Kasumi, how do you get to that number. ProMotion tells me I have 341 unique 16x16 tiles.

Don't necessarily assume your programmer will want to handle mid level tile switching, though. What Tepples described precludes using CHR ROM which has benefits that may better suit the game, for instance. (Similar things can be done with CHR ROM, but there are more conditions than the single tile swap that can be done with CHR RAM)

I got the 183 tile count with Pyxel Edit by forgetting I had it set to hex. $183 = 387. They still don't match, but if it's not counting two 16x16 regions that are the same except for their palettes, that would probably explain it. (Different palettes should matter for metastructures.)

Pre knowledge: If the player is not looking at a solid color screen (like during gameplay), most graphical things can only be updated during a very, very small period of time before the frame starts being rendered. This limited bandwith is the source of most NES graphical trouble. Updating tiles for scrolling or the HUD must be done in this time, updating sprite positions must be done during this time, palette updates etc.

CHR RAM allows you to freely change tiles, but if you want to update tiles this must be done during that tiny period of time. So if you're scrolling and want to update a lot of tiles, you might run out of time. You lose the ability to do midscreen scanline swaps of tiles. You can dynamically edit tiles at run time. Solstice uses this to hide the characters behind an isometric background by changing the pixels of the tiles that make up the characters transparent as they move behind the background.

CHR ROM totally lets you do midscreen scanline swaps of tiles, and you can swap all of them even while the game is drawing. This is because when swapping tiles on CHR ROM, you're not using the ports you can't talk to while the game is rendering. Instead you're talking to the mapper. Smash TV uses WAY more than 256 tiles for its title screen, and that can't be done with CHR RAM at all. You can also do significantly more background animation (including animating all 256 tiles on screen), and it's basically free. To do the same in CHR RAM is literally impossible. You can only update as many tiles as is safe with all of the other stuff that must be shared in the tiny time talking to the graphical ports is allowed. (How many is okay depends on a bunch of stuff like what sorts of scrolling you plan to do, since that also needs those ports. Also how fast the code that does those things is. Very fast code tends to take up lots of space, so there's enough in play that it's hard to throw out a number)

CHR RAM allows you to freely change tiles, but if you want to update tiles this must be done during that tiny period of time. So if you're scrolling and want to update a lot of tiles, you might run out of time.

Haunted: Halloween '85 does this dynamic tile replacement thing, and its engine allows replacing up to eight tiles in CHR RAM per frame.

With CHR ROM, you can get a similar effect by using a basic set of 128 tiles throughout a level and different sets of 128 tiles for different parts of a level.

Quote:

Smash TV uses WAY more than 256 tiles for its title screen, and that can't be done with CHR RAM at all.

Videomation and Oeka Kids use WAY more than 256 tiles for the painting screen, and that can be done with a CHR RAM larger than 8K. My current project uses a 62256 (32Kx8 SRAM) as its CHR RAM.

As for CHR-ROM vs. CHR-RAM, ROM that's switchable in small chunks (1KB or 2KB) allows you to easily achieve that "late NES game" feel, since you can instantaneously swap large amounts of tiles at any time, but without HAVING TO change the whole thing, which means you can animate only a few background elements or some sprites without the need for prohibitive amounts of CHR-ROM.

A competent programmer can achieve similar effects using CHR-RAM, but managing the PPU bandwidth becomes a much more complex task, and very large pattern changes are simply impossible from one frame to the next, such changes must happen across several frames.

If you need a lot of pattern changes during gameplay, CHR-ROM will make things easier, but there currently aren't many people selling recreated versions of mappers with fine CHR bankswitching for making cartridges (the MMC3 would be the most logical choice), while CHR-RAM cartridges can often be built from common, cheap electronic parts, so that's one reason for going that route.

I'd always take bank switching over CHR-RAM for such a change, honestly. The biggest problem is that you need to switch multiple tiles at once (mappers don't have that much granurality usually) but you can usually figure something out regarding this.

Also: palette changes mid-level can be just as useful. Maybe even moreso, in fact.

Jurassic Park is one example of a game that does mid-level tileset switching. When the first level starts, the tileset for the park gate is switched in. After the player moves far enough down or to the right, another tileset is switched in. This can be seen in FCEUX PPU viewer (set "display on scanline" to 32, otherwise it will display all black because the game switches to an all-black tileset at the top and bottom of screen to display black borders). Jurassic Park uses CHR-ROM.

As for the 256 metatile limit, it's true that having that limitation makes programming easier, code slightly faster and less space is used for the level data, but I feel like it's probably not the end of the world to bump up the limitation to 512 metatiles (by having two sets of 256 metatiles, and an extra bit in the level data for each metatile to select between the two sets). I plan to try to implement this in my engine at some point. Nice thing is, that if a level ends up using only 256 metatiles, you could point both the upper and lower metatile pointers to the same data, and the "9th bit" pointer to any garbage data, and it would work, wasting no space. Only the code would run slightly slower.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum