CHR swap in finer than 1k chunks?
Moderator: Moderators
CHR swap in finer than 1k chunks?
Is there a mapper that allows CHR swap in finer than 1k chunks? Preferably swapping in 256b chunks, but 512 would be of good help already.
context: https://twitter.com/bitinkstudios/statu ... 9259276291
That would allow each player and enemy on the screen to have its own chr strip, making the animation and visuals a lot more interesting than what can be achieved with 1k chunks.
context: https://twitter.com/bitinkstudios/statu ... 9259276291
That would allow each player and enemy on the screen to have its own chr strip, making the animation and visuals a lot more interesting than what can be achieved with 1k chunks.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: CHR swap in finer than 1k chunks?
perhaps CHR RAM is an option.
Does anyone remember how many bytes you can change (ppu writes) per frame in PAL ? I was thinking 500. (rough math says closer to 600 bytes, maybe, but I don't think you could optimize that many bytes, so it would have to be a slow loop)
Does anyone remember how many bytes you can change (ppu writes) per frame in PAL ? I was thinking 500. (rough math says closer to 600 bytes, maybe, but I don't think you could optimize that many bytes, so it would have to be a slow loop)
Last edited by dougeff on Thu May 20, 2021 8:45 am, edited 1 time in total.
nesdoug.com -- blog/tutorial on programming for the NES
Re: CHR swap in finer than 1k chunks?
According to this page only 10 8x8 tiles per frame can be updated using CHR-RAM (NTSC). I'm using 8x16 mode.
https://cppchriscpp.github.io/nes-start ... r_ram.html
So I guess it wouldn't fix the problem. Maybe downgrading the fps to 30 would allow for enough tiles to be updated, but I'm not sure that's a good tradeoff, even if considering an optimized combination of 1k bank switching CHR-ROM (for player sprites) and CHR-RAM (for enemies).
https://cppchriscpp.github.io/nes-start ... r_ram.html
So I guess it wouldn't fix the problem. Maybe downgrading the fps to 30 would allow for enough tiles to be updated, but I'm not sure that's a good tradeoff, even if considering an optimized combination of 1k bank switching CHR-ROM (for player sprites) and CHR-RAM (for enemies).
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: CHR swap in finer than 1k chunks?
Technically, the MMC5 can do background CHR bankswitching in 16-byte chunks, but that doesn't really count because it's just selecting a new 4KB CHR ROM bank for each individual tile (and effectively expanding the PPU's 8-bit tile numbers to 14-bit), and that sort of setup isn't really feasible with sprites since there's no way for the mapper to know which sprite is being fetched.
The usual way of handling this would be to ensure that all of the graphics for a single enemy are in the same bank, have a single bank cover multiple different enemy types if possible, and design the game such that you never have more types of enemies than can be represented with the banks you have available.
For example, if the player always takes up one 1KB bank and you can fit 2 enemies into each 1KB bank, then you can have up to 3 different pairs of enemy types at any given moment, but not 6 arbitrary types unless you duplicate some of your banks.
The usual way of handling this would be to ensure that all of the graphics for a single enemy are in the same bank, have a single bank cover multiple different enemy types if possible, and design the game such that you never have more types of enemies than can be represented with the banks you have available.
For example, if the player always takes up one 1KB bank and you can fit 2 enemies into each 1KB bank, then you can have up to 3 different pairs of enemy types at any given moment, but not 6 arbitrary types unless you duplicate some of your banks.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: CHR swap in finer than 1k chunks?
Yeah, exactly. But the game in question has big, well animated sprites, hence the need for a finer CHR swap. I actually can't believe there has never been a nintendo mapper that did finer CHR swaps.Quietust wrote: ↑Thu May 20, 2021 8:49 amThe usual way of handling this would be to ensure that all of the graphics for a single enemy are in the same bank, have a single bank cover multiple different enemy types if possible, and design the game such that you never have more types of enemies than can be represented with the banks you have available.
For example, if the player always takes up one 1KB bank and you can fit 2 enemies into each 1KB bank, then you can have up to 3 different pairs of enemy types at any given moment, but not 6 arbitrary types unless you duplicate some of your banks.
This is one of the several enemies in the game: https://www.spriters-resource.com/arcad ... et/154341/ I wouldn't use all of the frames for the enemies, nor the full size of the sprites, but cutting all of those frames to fit into a single 1k chr section seems like too much of a loss, considering that with a mapper configuration all or most of the frames could be kept. It means a huge difference in the game's visual quality.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: CHR swap in finer than 1k chunks?
One problem with smaller CHR banks is that you need more bits to address them, and you need more of them mapped at once to fill the pattern tables, and that adds up to significantly more state bits to keep track of, and the mapper interface also becomes more complex because a single 8-bit write isn't enough to specify a bank anymore. For this reason, I don't think it's too surprising that Nintendo never made such a mapper.
However, even though the MMC5 still uses 1KB banks, you can have 8 sprite banks active at once if you use 8x16 sprites, allowing you to have 8 independently animated sprites at once, which may be enough for what you want.
However, even though the MMC5 still uses 1KB banks, you can have 8 sprite banks active at once if you use 8x16 sprites, allowing you to have 8 independently animated sprites at once, which may be enough for what you want.
Re: CHR swap in finer than 1k chunks?
If there's no existing mapper, that's not a huge problem. Planning to sell a few hundred copies? Ask the board makers for a customized mmc3/whatever, adding CHR granularity is a small change that won't double the board cost. Sharing a rom? Then you only need to modify an emulator.
edit: I have no idea what the link in OP says, the desktop twitter site is far too slow and they killed the no-js mobile version ages ago.
edit: I have no idea what the link in OP says, the desktop twitter site is far too slow and they killed the no-js mobile version ages ago.
Re: CHR swap in finer than 1k chunks?
Just in case you're not familiar with how the MMC5 does things: it takes advantage of the fact that 8x16 sprites can fetch patterns from both pattern tables, and that background patterns and sprite patterns are fetched at different times, so in 8x16 mode it gives you 8 x 1KB banks just for sprites, while the background tiles are handled separately.
This will allow you to have 4 players and 4 enemies all animated independently like you wanted. The only problem is that there'll be nowhere to map other sprites, such as items and visual effects. You might be able to spread those across the player banks, pairing specific characters with specific support sprites, and replicate those sprites in every bank of the character they're paired with.
Since this is a Simpsons game, I think it's safe to assume you're not gonna be selling it, right?
This will allow you to have 4 players and 4 enemies all animated independently like you wanted. The only problem is that there'll be nowhere to map other sprites, such as items and visual effects. You might be able to spread those across the player banks, pairing specific characters with specific support sprites, and replicate those sprites in every bank of the character they're paired with.
Since this is a Simpsons game, I think it's safe to assume you're not gonna be selling it, right?
Re: CHR swap in finer than 1k chunks?
My $2 : It's possible to replicate that behaviour on any mapper with CHR-ROM bankswitch : Just switch the banks before the sprite fetches and re-switch them for the background rendering, every scanline. This requires either an IRQ on each line or full CPU monopolization for the lines with this feature enabled. Many emulators won't emulate the behaviour accurately.tokumaru wrote: ↑Thu May 20, 2021 10:23 am Just in case you're not familiar with how the MMC5 does things: it takes advantage of the fact that 8x16 sprites can fetch patterns from both pattern tables, and that background patterns and sprite patterns are fetched at different times, so in 8x16 mode it gives you 8 x 1KB banks just for sprites, while the background tiles are handled separately.
Useless, lumbering half-wits don't scare us.
Re: CHR swap in finer than 1k chunks?
Creating a new mapper is a viable option. The problem for me is I know I wouldn't be able to do it by myself in a reasonable amount of time. But it's something that other homebrewers could reuse, so there's that value. The new MXM-0 mapper may be able to this already though.calima wrote: ↑Thu May 20, 2021 10:04 am If there's no existing mapper, that's not a huge problem. Planning to sell a few hundred copies? Ask the board makers for a customized mmc3/whatever, adding CHR granularity is a small change that won't double the board cost. Sharing a rom? Then you only need to modify an emulator.
edit: yep, it allows for 512b chr banking. "CHR Bankswitching - 16-bit bank numbers w/ 4k/2k/1k/0.5k windows RAM/ROM"
I completely forgot that the MMC5 allows 8K CHR to be used exclusively by sprites every frame! Genius That settles it for now then, I'm going (to try to go) MMC5.
Right, this is a proof of concept and a deep study for me into making a complex thing. The fact that it is a popular project motivates me.
That's a very interesting idea! Has it ever been implemented?. My second question is wouldn't that consume too much of the CPU's time?Bregalad wrote: ↑Thu May 20, 2021 10:56 amMy $2 : It's possible to replicate that behaviour on any mapper with CHR-ROM bankswitch : Just switch the banks before the sprite fetches and re-switch them for the background rendering, every scanline. This requires either an IRQ on each line or full CPU monopolization for the lines with this feature enabled. Many emulators won't emulate the behaviour accurately.
Last edited by nesrocks on Thu May 20, 2021 11:20 am, edited 1 time in total.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: CHR swap in finer than 1k chunks?
It is pretty much proportional to how tall the area where the effect is enabled would be. If you want this for the whole screen it would eat basically the whole CPU time.
Useless, lumbering half-wits don't scare us.
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
Re: CHR swap in finer than 1k chunks?
i seriously wished that "use both background and sprites side for sprites thing, existed for regular 8x8 sprites too. (the megaman games only were designed with 8x8 in mind) that would of opened up sooo many more possibilities and "what enemies can be paired together" not be a miserable headache to me in so many cases - mmc5 mapper
Re: CHR swap in finer than 1k chunks?
Doing that would've required changes to the PPU, since sprite tile numbers are only 8 bits wide and you need to tell them which pattern table to use (via register $2000.3). Yes, I suppose they could've expanded the on-die DRAM to fill in more of the unused "flags" bits, but that probably would've made the PPU significantly more expensive to manufacture (since it'd have a larger die size).kuja killer wrote: ↑Thu May 20, 2021 11:30 am i seriously wished that "use both background and sprites side for sprites thing, existed for regular 8x8 sprites too. (the megaman games only were designed with 8x8 in mind) that would of opened up sooo many more possibilities and "what enemies can be paired together" not be a miserable headache to me in so many cases - mmc5 mapper
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: CHR swap in finer than 1k chunks?
The number of Chr banks can be doubled, which means that the Chr graphics data has double redundancy.
This method is similar to the 4K bank of NSF mapper, because the hardware does not support 4KB bank and fills double with redundant data.
The best way is to modify the software to achieve hardware compatibility, rather than to increase the cost of hardware. After all, it costs to develop a new mapper chip, and flash has enough dencity, which can be met in most cases
This method is similar to the 4K bank of NSF mapper, because the hardware does not support 4KB bank and fills double with redundant data.
The best way is to modify the software to achieve hardware compatibility, rather than to increase the cost of hardware. After all, it costs to develop a new mapper chip, and flash has enough dencity, which can be met in most cases