It is currently Tue Oct 17, 2017 6:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu Aug 23, 2012 9:45 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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!

Quote:
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.

Quote:
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.

Quote:
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).


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 11:34 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 11:48 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19085
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 11:49 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 11:55 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 12:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6273
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 12:11 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 12:36 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
lidnariq wrote:
With just one IC, I'm guessing you're using a 74'161.

Yup.

Quote:
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 1:59 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
Quote:
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 ?


Top
 Profile  
 
PostPosted: Thu Aug 23, 2012 8:52 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Fri Aug 24, 2012 5:34 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Fri Aug 24, 2012 11:06 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Tue Jan 28, 2014 2:46 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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!


Top
 Profile  
 
PostPosted: Wed Jan 29, 2014 1:16 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Wed Jan 29, 2014 1:57 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group