Thursday 11 February 2016

Priorities

I've fixed the top-level program flow so that game over returns to the main menu in the absence of setjmp/longjmp - not that I could get them working properly anyway.

During testing I discovered another game play bug; entering a room from an elevated arch leaves you hanging in the air unable to move. Hmm...

Most of my "Knight Lore" time today has been working on Neo Geo Z-ordering, which equates to shuffling hardware sprite priorities.

The first task was to defer actual sprite rendering and instead build a list of sprites to be wiped, and another of sprites to be rendered, for the current frame. The former list will be used when objects disappear from the screen, so I know to park the hardware sprite.

The latter list must be processed against the entire graphic object table in order to re-assign hardware sprite priorities. Here-in lies the challenge of devising an adequate algorithm.

My first algorithm produces almost perfect results; in fact I thought it was working for a while until I entered a rather crowded room and some subtle priority issues arose. After eventually resorting to pencil-and-paper I realised the flaw in the algorithm itself.

Algorithm #1 - gets it right most of the time

Back to the drawing board and I've got another algorithm in mind. It's more complicated and is going to take a bit to implement and get right. Even then, I've no proof the algorithm is correct. The problem is that debugging on the Neo Geo is particularly painful with the lack of stdout for printing debugging information, and it's not possible to debug on, for example, the PC without writing some sort of emulation layer for hardware sprites.

Fun, fun fun!

UPDATE: Implemented my new algorithm tonight. I'm assuming there's no bugs, but the results are worse than the simpler algorithm. I'm beginning to wonder if there actually is a solution, short of re-rendering every sprite on the screen (and there's no time for that during VBLANK).

No comments:

Post a Comment