Sunday, September 29, 2013

1 day left

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.


Sylvain Pypebros said...

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.

Sylvain Pypebros said...

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.

Sylvain Pypebros said...

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.

Sylvain Pypebros said...

Of course, with RunME statically allocating 64 OAMs for the 'SpriteWindow', things could not work as fine as they should. fixed.