I have quirks in moving inkjets and the pendat doesn't feel like progressing forward right now (nor left now, afaik). There's a more concerning issue, however: I will have to cut the number of monsters present in the level. With pendat reaching up to 6 or 7 "limbs", and each limb being an individual OAM, and all those OAM (i.e. hardware sprite) being statically assigned to objects, I regularily (e.g. when inkjet throws droplets) hit the "128 OAMs" barrier of the hardware that makes some sprite becoming invisible. Another engine update will be requiredwelcome to fix that. That shall be the road ahead.
edit: fixed with automated OAMs management. It took over 1 year, but hopefully, meanwhile I had realised that I was far from the hardware limit and just experiencing issues in runME because it pre-allocated half the OAMs "for internal purpose"
4 comments:
Remember, we have software copy/reassignment of GOBs. It could be used to avoid implementing freeze/unfreeze by skipping those "OAM_DISABLED" entries, but only as long as we have "logical" OAM identifiers available in our display lists.
links in those lists are 8-bit and could be tweaked so that 252 logical OAMs are allowed. That would allow us to support the "demo level" with minimal coding effort.
setting the rails is more complicated than expected. The tile-number -> block number -> collision flags -> state transition chain is too long and involves too many tools to be efficiently debugged.
Plus, the special tiles need to be set on a 16x16 block, and we have no visual hint on whether this rule is true when editing the map.
Wait a minute ...
1 Hero (5 OAMs)
3 Bladors (3 OAMs)
4 RectoVerso (3 OAMs)
1 Pendat (8 OAMs)
3 Inkjets (3 OAMs)
4 Spongebop (3+1)
I should have at most 60 OAMs (droplets and wandering feet not accounted)... I'm still far away from the 127 OAMs limit.
Of course, with RunME statically allocating 64 OAMs for the 'SpriteWindow', things could not work as fine as they should. fixed.
Post a Comment