This was my original plan, before I even started this thread. It's plainly the superior solution, as the expensive big jump table lookup only happens once during the object creation.Oziphantom wrote: Or if you have a large number and you have a large number of shared update functions. Do the more expensive look up once and then store the Bank and Ptr Lo and Ptr Hi along with State number for each entity. Thus each frame you load/store the bank then jump to the Lo/Hi function for maximum speed. And then when you need to change it you have the State number to modify and then do the more expensive 256+ 2byte -> 3 byte look up.
The downside is that you end up using a lot more memory. Instead of just storing an Id in a byte (or two bytes if we use a big jump table), you'll now have to store the flags, sprite, update-, death-, and collision-routine addresses.
If you want to allow up to 8 game objects alive at once, you'll have to set aside 8 times as much memory. Just the things I mentioned above would result in 8*8 = 64 bytes of RAM spent. And it will keep growing as you add more stuff to enemies.
If you are using a mapper with more RAM, it shouldn't be much of a problem though. I still might end up using that solution. It's also cool because you can "modify" a living object to change it's behavior, like pointing it's update routine address to an RTS for when it's frozen in ice.