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).
Minimizing expansion of CHR converted for real-time updates
Moderator: Moderators
Re: Minimizing expansion of CHR converted for real-time upda
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.Celius wrote:It's funny, because my biggest road block has been trying to complete my project using NROM specifications.
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.How many tiles are we talking about?
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.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).
- 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
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.
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...
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.
This doesn't apply if the desire is to build carts on donors or you consider old stock eproms new: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...
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
-
- 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
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.
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.
Re: Minimizing expansion of CHR converted for real-time upda
Yeah, it was 128KiB SGROM originally.infiniteneslives wrote:Just look at Driar for example, something like ?128KB? MMC1 down to NROM ~year after it was released.
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...The NROM boards I produce actually use two 128KB flash roms trimmed down to 8/32KB each.
That's funny, that makes it look like the Color Dreams board is currently the cheapest board to manufacture.
- 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
Yeah that's pretty accurate by my account as well.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...
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.That's funny, that makes it look like the Color Dreams board is currently the cheapest board to manufacture.
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
Re: Minimizing expansion of CHR converted for real-time upda
@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).
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).
Re: Minimizing expansion of CHR converted for real-time upda
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.
Re: Minimizing expansion of CHR converted for real-time upda
Yeah, this is indeed a concern. I don't expect this particular project to end up in any multicarts though.tepples wrote:More stuff in less ROM helps when you're trying to include contributions from several different developers in one multicart.
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.It's why the 2011 compo was limited to NROM and the 2014 compo is limited to 64K.