Alp wrote:I gave CHR-RAM a proper read-up, and wow! You can dynamically load tile data into a tilebank? I wasn't aware of that!
The beauty of CHR-RAM is that, like any regular RAM, it can be freely modified. The only constraint is that you can't touch it while the image is rendering (the same way you can't touch other parts of VRAM), so during gameplay you're limited to changing the amount of tiles possible during VBlank, which aren't that many. At 16 bytes per tile, you can realistically update only 4 to 8 tiles during VBlank each frame while still having time left for other updates, such as sprites, name tables, palettes, and so on. During screen transitions, when you can disable rendering and keep the screen blank for a few frames, you have enough time to set up your pattern tables however you want.
BTW, most other game consoles (Game Boy, Master System, Genesis, SNEs, etc.) are always like that, with tiles stored in RAM as opposed to ROM, only this RAM is *inside* the console. For some reason (most likely to make the console cheaper), Nintendo chose to put this memory outside the Famicom. This made it possible for carts to use either ROM or RAM for tiles, allowing developers to use what suited their games better.
No. I won't need fancy raster effects. Reading a compiled list, they do seem helpful, in some cases. But not something I would need. At least, not for anything at the moment.
Then the best thing to do is stick to simple discrete mappers, like UxROM or BNROM, which provide simple PRG-ROM bankswitching and CHR-RAM.
