Thanks for the responses!
Quietust wrote:
I also can't help but wonder exactly what it is you're doing that requires a jump table longer than 256 entries...
Sumez wrote:
I'm genuinely interested in knowing what practical use such a big jump table could possibly have?
SMB3 already has 180 different kinds of game objects: Mushroom, Fireflower, Leaf, Hammer Bros Suit, Goombas, Flying Goomas, Koopa Troopas, Boo, Chain Chomp, Cheep Cheep, Piranha Plant, Bullet Bill, Bob-omb, Thwomp, Blooper, Dry Bones, Hammerbros, Sledge Bro, Nipper Plant, Para-Beetle, etc etc etc etc.
You could problaby trim away some of the broken unused game objects from the engine, and use the leftover 76 slots, but in the end the majority of slots is already taken. If you were going to, say, port over the game objects from SMB2 and SMBW you'd find yourself running past the 256 limit in a flash.
There is also the thing that a lot of game objects use another game object as a different "state", for instance, enemies that hide in their shell when stomped on does so by changing themselves into a different game object. I could probably bake those behaviors into the original game object but it would be a pretty big overhaul, and it would incur some execution cost.
And there are even game objects that have duplicates with slight behavior differences. Bob-ombs shot out of a cannon walk around for a few seconds before exploding, while Bob-ombs found naturally in various levels walk around forever until Mario disturbs them. Nintendo solved this by simply making it two different types of game objects that invokes mostly the same routines.
Bregalad wrote:
That. You didn't give details but if you need a jump table larger than 256 entries I can almost guarantee you're doing something wrong. This is why there is no "techniques" mentionned in the wiki - because nobody needs that.
You can almost guarantee that no NES game needs jump tables larger than 256? Wut?
How about like, a JRPG that wants more than 256 types of enemies? More than 256 types of items/weapons?
I get that usually 256 is more than enough, but surely that cannot be some universal rule.
rainwarrior wrote:
you could also put a JMP (indirect) instruction in RAM (ZP?) ahead of time, update its operand with the computed lookup address, and run that directly instead of fetching it with LDA.
Oh, you mean having code instead of data? That's an interesting idea, enemies could have an "initialization" routine instead of static data. You'd probably have to store certain of those values in RAM though, unless you wanna run that routine each time you need to look up some bit or byte.
rainwarrior wrote:
If you've got an appropriate mapper with enough banks, you might even use banking to select pages of your table quickly. Put each 256-entry table in a different bank, and then a quick STA $8000 could be faster than doing any branching/indirection. (You can still use the rest of the bank for other data.) If your table is really large you're probably already dealing with banks anyway.
Interestingly enough, this is already what SMB3 does for it's game objects, except each bank only holds 36 entries for some bizarre reason (defeating the point). I thought about adopting the same technique, but figured it's too messy.
Does switching banks incur any cycle cost? If not, I might reconsider it. All each entry would need would be a bank number and the usual object id, and looking up the data would be ultra cheap, provided that the only cost to switching the bank would be the LDA/STA to the register.