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

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:What you describe is the clairvoyant algorithm, which can't run in real time but is optimal when run offline: "When a [value] needs to be swapped in, the [compiler] swaps out the [value] whose next use will occur farthest in the future."
Yeah, that's exactly it!
I wonder to what extent you can save bytes by planning out which values can be calculated with ASL/LSR/ROL/ROR (and thus kept in A) or with DEX/INX/DEY/INY (and thus kept in X or Y).
That's a pretty good idea! The difficult part would be deciding whether to use the accumulator or an index register to load a new value, since you'd have to predict what kind of modifications that value would go through in the future.
Bregalad wrote:Then give the main character's animation update higher priority.
But then the background animations might feel laggy.
Does the player change frame every frame ? No, very unlikely, even if you have very detailed graphics frames of animation will last at least 4 hardware frames.
Certainly not every frame, but some effects (quick attacks, visual deformations, etc.) would need new graphics every other frame.
Unless you use re-writable patterns for all enemies/whathever, but that would not be a good idea on the NES anyway.
In addition to the main character, I have to animate waterfalls, flowers, power ups, and other background objects. These will probably animate at a steady rate of 15 frames per second, and since there could easily be 4 of these animated items in a level it would be tough if everything had to share 1 slot. Still, I don't have the RAM to hold patterns, so for me this isn't an option anyway.
tepples wrote:As I understand the problem that tokumaru stated, we're trying to minimize cycles first and then break ties by minimizing bytes.
My rule is that the "compressed" code can't take longer to execute than the raw LDA STA chain. I'm considering making the encoder count how many cycles it saves by not loading values that were already in one of the registers and use those cycles for extra compression (such as using subroutines for longer repeated patterns). JRS + RTS takes 12 cycles, so only after avoiding 6 load operations I would be able to call a subroutine once (obviously, any savings inside the subroutine will be counted as many times as the routine is called).
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 »

So what about running with 32Kb of VRAM? There is no added cost because 32Kb is usually cheaper than 8Kb. There weren't any NES boards with this config, but it's simple enough to just use SRAM instead of ROM. Then you could bankswitch for your animations, and still not have tiles stored in ROM.

In regards to the super mapper wouldn't dual ported memory end up being a better and easier route?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
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 »

How 32 KiB CHR RAM would work depends on what CHR bank size you were thinking of. 1 KiB? 2? 4? 8?

As for dual ported memory, what part number were you thinking of?
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

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

Post by Shiru »

A very common usage for the VRAM update is the main character graphics, as there is only one copy of the main character on the screen. VRAM bankswitch won't help with this, as 8 frames would be not enough for main character animation, but may in fact make things more complicated if other sprite animation is needed along with the main character animation.
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 »

infiniteneslives wrote:So what about running with 32Kb of VRAM? There is no added cost because 32Kb is usually cheaper than 8Kb. There weren't any NES boards with this config, but it's simple enough to just use SRAM instead of ROM. Then you could bankswitch for your animations, and still not have tiles stored in ROM.
The extra memory may not add to the cost, but but a mapper that can bankswitch CHR certainly will. The mapper I'm using is just 1 discrete logic chip, and I don't plan on changing that.

I'm familiar with these other solutions some of you have been suggesting, and they are not what I'm looking for, I'm just trying to slightly improve the one I'm already using (and if I can't improve it, I'll not feel bad about using it as it is). I know this scheme is crazy and most of you would rather use any of the more conventional ways of handling CHR animations, but I think that the advantages of the technique I'm using outweigh the disadvantages in this case.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

tokumaru wrote:The extra memory may not add to the cost, but a mapper that can bankswitch CHR certainly will. The mapper I'm using is just 1 discrete logic chip, and I don't plan on changing that.
With just one IC, I'm guessing you're using a 74'161. I don't know how suppliers work in Brazil, but at least in the US, Mouser is selling 74'377s for 20c/1 and 74'161s for 25c/1, so it is likely that you could add CHR banking if you wanted at no incremental cost.
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 »

You could still have 32Kb VRAM with a single chip discrete mapper, but you'd be limited to 8Kb bank sizes. Super GNROM style I guess.

Tepples: we're kinda straying from the topic but... I was thinking mmc3 so you'd get 1/2Kb banks, but if you're designing the mapper yourself you could do whatever you please. As for part number, I'm referring to the lattice machXO2 CPLD (1200HC) with 7Kb dual ported RAM. It'd be your mapper, SRAM, save flash, Synth, and capable of MMC5ish capabilities and all for $6-7. There would be some other added costs but not much more than $1 depending.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
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 »

lidnariq wrote:With just one IC, I'm guessing you're using a 74'161.
Yup.
I don't know how suppliers work in Brazil, but at least in the US, Mouser is selling 74'377s for 20c/1 and 74'161s for 25c/1
I just checked and I can get the '161 for about the same price and the '377 for twice the price at Mouser.
so it is likely that you could add CHR banking if you wanted at no incremental cost.
But not fine CHR banking, which is the kind that's useful for CHR animations. Swapping the whole 8KB or even 4KB is useless for this purpose. Background + main character animation is only feasible with MMC3-class mappers.
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 »

But then the background animations might feel laggy.
I seriously doubt.
If for example you're animating water, and rewrite it's tiles every 10 frames, and sometimes it would be delayed by a frame if the main character had been updated on the frame where water was supposed to animate.
So instead of having a pattern like :
10 - 10 - 10 - 10 - 10 - 10- 10 - 10 -....

We would have something like :
10 - 10 - 11 - 9 - 10 - 10 - 10 - 11 - 9 - 10 - ....

I doubt any human beings would note any difference.

Of course if you're animating the water in a 2-frame sequence it's another story, but who does this really ?
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 »

tokumaru wrote:But not fine CHR banking, which is the kind that's useful for CHR animations. Swapping the whole 8KB or even 4KB is useless for this purpose. Background + main character animation is only feasible with MMC3-class mappers.
I agree, if you really didn't want to break down and drop the dollar or two for the CPLD (and make a new mapper) that would allow fine bank switching it's not much of an option. Personally, I don't really consider that much of a cost difference though. That cost is easily recoverable with PCB quantities.

Your goal is to utilize the simpler, more challenging route though and I can understand/admire that as well.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
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 »

infiniteneslives wrote:I agree, if you really didn't want to break down and drop the dollar or two for the CPLD (and make a new mapper) that would allow fine bank switching it's not much of an option. Personally, I don't really consider that much of a cost difference though.
It's not just cost, you know? It's the complexity in general... Mapper design is something I find very interesting, but I'm not as good with hardware as I am with software (by far!). And there's the whole problem of modifying emulators to support the mappers and the fact that I can't manufacture carts myself... I really don't need that kind of complication.
Your goal is to utilize the simpler, more challenging route though and I can understand/admire that as well.
It kinda is an experiment to see how complex a game can look (and not necessarily be) without deviating much from the basic setup. That means using a simple mapper just to be able to use more PRG-ROM and keeping raster effects, timed code and forced blanking to a minimum.
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 »

tokumaru wrote:It's not just cost, you know? It's the complexity in general... Mapper design is something I find very interesting, but I'm not as good with hardware as I am with software (by far!). And there's the whole problem of modifying emulators to support the mappers and the fact that I can't manufacture carts myself... I really don't need that kind of complication
Yeah I fully realize that. Coming from the opposite end of the software/hardware spectrum most of my projects are trying to battle those issues.

I think it's good to take your route and try to squeeze every last ounce out of what's available with the NES and a simple discrete mapper. Obviously there is a lot that can be done with that alone. Then if one should be so lucky to get to the point of working on a sequel, you can fully appreciate and utilize the hardware expansions. Really that's what many developers did back in the day with this system, just look at SMB and SMB3.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
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 »

Sorry for the bump, but today I found myself thinking about this again...
tepples wrote:I wonder to what extent you can save bytes by planning out which values can be calculated with ASL/LSR/ROL/ROR (and thus kept in A) or with DEX/INX/DEY/INY (and thus kept in X or Y).
How would you go about planning this? I mean, using INX/DEX/INY/DEY/ASL/LSR/ROL/ROR as a "bonus" instead of LDA/LDX/LDY when possible would be easy (and probably wouldn't happen very often), but actually planning which registers to use ahead of time is way beyond my capabilities... Can anyone think of a way to do this?

Ideally, cpow's idea of the generating the optimal 6502 sequence that would generate the desired data (even using JSR/RTS for repeated patterns and such) would be used, but an algorithm for doing that would be insane to code!
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 »

I'm not sure about that specifically. But revisiting this problem my question would now be, how big is too big? Or how close are you to your limit? What is your limit? That was the main problem with your fast method after all right? There isn't a significant cost difference in chip prices between 128KB and 512KB, and the mapper cost doesn't change for a BNROM mapper of that size.

It's just my opinion, but some pennies just aren't worth pinching. Rom size is one of those provided you're under 512KB and have already expanded beyond NROM. Not to mention if you trip and fall while trying to pick up too many pennies, the end result may be that you never complete your adventure.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
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 »

You're right. I'm already using BNROM, and I'm shooting for 256KB of PRG-ROM. I guess I could easily bump the PRG-ROM to 512KB, but since I don't plan on using these "fast pattern updates" that much (maybe 8KB at most, which would expand to 40KB without optimizations) I doubt that'll be necessary.
infiniteneslives wrote:Not to mention if you trip and fall while trying to pick up too many pennies, the end result may be that you never complete your adventure.
You're absolutely right... one of the reasons I don't advance with my projects as much as I'd like is that I get caught up in unimportant details like this. I should learn to focus on what really matters.
Post Reply