Minimizing expansion of CHR converted for real-time updates

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

Moderator: Moderators

Celius
Posts: 2158
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Re: Minimizing expansion of CHR converted for real-time upda

Post by Celius »

It's funny, because my biggest road block has been trying to complete my project using NROM specifications. I had very limited space left for data after creating the engine and allotting space for tile data (used by the entire game), and I still had some other game modes to program. I recently decided to up the ROM and CHR up to 64k each because I knew it was preventing my project from going anywhere. And now that I'm thinking about it, I may just jump to 128k PRG and use CHR RAM...

But honestly, I think the idea of the fast patterns is a good one. There are several components in my engine where data is stored as code, for the sake of speed, and reducing the complexity of the engine. How many tiles are we talking about? You might also consider a sort of "split" method. You don't have to choose between hardcoded only and updates from RAM only. You might consider having the most frequently updated tiles be hardcoded, and then have space for a few tile updates in RAM (not storing code in RAM, but just tile values).
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Minimizing expansion of CHR converted for real-time upda

Post by tokumaru »

Celius wrote:It's funny, because my biggest road block has been trying to complete my project using NROM specifications.
Sometimes we think that having less space to fill will help us finish projects faster, but when you find yourself struggling to save space you can be sure the whole idea backfired. You should definitely increase the storage space in this case.
How many tiles are we talking about?
I guessed around 512 tiles before, but I honestly have no idea. I can see the main character and level background animations using this technique.
You don't have to choose between hardcoded only and updates from RAM only. You might consider having the most frequently updated tiles be hardcoded, and then have space for a few tile updates in RAM (not storing code in RAM, but just tile values).
Definitely, I never considered using the fast graphics exclusively. My engine can update 6 tiles per update slot (there are 2 sots per VBlank) in normal mode (direct copy from ROM or RAM) and 8 tiles in quick mode.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Minimizing expansion of CHR converted for real-time upda

Post by infiniteneslives »

Glad I could help! Yeah, if you read a few posts back you can see I too got caught up on fancy ideas such as throwing a bunch of hardware at the problem. Back in the 80's there was significant savings to be had for halving the size of your rom. But now, rom/ram bits are dirt cheap. It's actually the packaging, assembly, and other near flat costs per chip that make up the better part of the memory cost. Back in the day it was all about die size, this may still be somewhat true with mask roms today though. That and we will never reach the volumes they did back then to realize large savings overall from a small savings per cart.

Not to mention if the desire is for a digital release, the only benefit to be had aside from enjoyment to be had while optimizing.

Don't get me wrong, there is still savings to be had for smaller roms and simpler mappers in production. But even if you save a few dollars on the hardware needed, you still have to actually complete it before that savings can be realized. Once things are mostly complete one can always go back and optimize things if there is a need/benefit to do so. Just look at Driar for example, something like ?128KB? MMC1 down to NROM ~year after it was released.
Celius wrote:I recently decided to up the ROM and CHR up to 64k each because I knew it was preventing my project from going anywhere. And now that I'm thinking about it, I may just jump to 128k PRG and use CHR RAM...
This doesn't apply if the desire is to build carts on donors or you consider old stock eproms new:
But if you're building a cart with new widely available parts, the cheapest rom size available is 128KB practically speaking. The NROM boards I produce actually use two 128KB flash roms trimmed down to 8/32KB each. So in reality if your mapper already supports 128KB, there is no cost difference between 64KB and 128KB. It ends up being a question if you want to waste/reserve half the chip or not...
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Celius
Posts: 2158
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Re: Minimizing expansion of CHR converted for real-time upda

Post by Celius »

I'll probably just end up going with 128kb PRG and using CHR RAM. I'm not even sure how this game will end up being distributed. I'm kind of dumb when it comes to hardware, but I'm assuming something with these specifications could easily be produced? I'm going to convert the project to MMC3 for now, but I'll treat banks as if they're 16kb and only switch out $8000-$BFFF, and I won't be using anything like the scanline counter. That way the project should be pretty easy to convert to another mapper, if needed.

And I guess part of the problem is that you feel your project has to meet certain standards if it has high enough specs. Like if you up the amount of CHR data, you think "should I really be reusing that one tile all over the place, when I have the ability to make more unique patterns now?" It can sometimes create more work once you realize you have more resources.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Minimizing expansion of CHR converted for real-time upda

Post by lidnariq »

infiniteneslives wrote:Just look at Driar for example, something like ?128KB? MMC1 down to NROM ~year after it was released.
Yeah, it was 128KiB SGROM originally.
The NROM boards I produce actually use two 128KB flash roms trimmed down to 8/32KB each.
I was going to hope that maybe that meant ROM+RAM would be better, except that the cheapest 5V ROMs are still cheaper (only by a dime or so) than any size of 5V RAM...

That's funny, that makes it look like the Color Dreams board is currently the cheapest board to manufacture.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Minimizing expansion of CHR converted for real-time upda

Post by infiniteneslives »

lidnariq wrote:I was going to hope that maybe that meant ROM+RAM would be better, except that the cheapest 5V ROMs are still cheaper (only by a dime or so) than any size of 5V RAM...
Yeah that's pretty accurate by my account as well.
That's funny, that makes it look like the Color Dreams board is currently the cheapest board to manufacture.
Cheapest non-NROM board, yes. And assuming that there isn't money to be saved from a 4bit '161 compared to a 8bit flipflop. If you can save money by going with a '161 then GNROM would be cheaper.

Colordreams certainly is the cheapest if you require all the memory on chip to be available for use. I've always considered CHR-RAM superior to CHR-ROM. But with 16x8KB banks of CHR-ROM, perhaps it's really not that limiting, and it leaves more space in a minimal 128KB PRG-ROM chip. Never thought of this either, but with Colordreams, the obvious choice for saves on flash would be putting them on a CHR-ROM bank. So with further consideration, unless you're really looking to take advantage of CHR-RAM for graphic effects, there are a lot of benefits to going with mapper #11. Additionally the expansion of up to 512KB PRG-ROM is trivial, so you're not limited to 128KB PRG.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Minimizing expansion of CHR converted for real-time upda

Post by Bregalad »

@Celius : It sounds like you should use UNROM then. Until you need to change mirroring or have SRAM, in which case you should use MMC1 (SGROM/SNROM). You even get the bonus of having the possibility to do single-screen mirroring, that MMC3 can't do. I see no reason to use MMC3 in your case.

Back on topic (well off-topic) I think it's fun to try to place as much stuff as possible in as little ROM as possible. It makes us face the same kind of problems that engineers had back in the day. The key is to profile the thing correctly, and work hard on optimizing the largest stuff. In my case the largest stuff is maps, which takes a hell of a space, even with RLE compression. So I'm going to apply a more advanced compression to save more space.
I have already made a fun compression scheme for my metasprites that allows trivial ones to be stored in few bytes while allowing for maximum flexibility (not gird aligned sprites, multiple colours, etc...) at the same time. I'm proud of it !

@Tokumaru, It's very smart to store the few animated graphics this way, and that's don't prevent you to apply a strong compression to other graphics, probably being overall more efficient that if all graphics were stored the plain way (uncompressed).
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Minimizing expansion of CHR converted for real-time upda

Post by tepples »

More stuff in less ROM helps when you're trying to include contributions from several different developers in one multicart. It's why the 2011 compo was limited to NROM and the 2014 compo is limited to 64K.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Minimizing expansion of CHR converted for real-time upda

Post by tokumaru »

tepples wrote:More stuff in less ROM helps when you're trying to include contributions from several different developers in one multicart.
Yeah, this is indeed a concern. I don't expect this particular project to end up in any multicarts though.
It's why the 2011 compo was limited to NROM and the 2014 compo is limited to 64K.
It is? Guess I didn't read the rules very carefully. I probably won't have time to develop anything for the compo anyway, but if I did it would definitely be within the 64KB limit.
Post Reply