The Upward Spiral - Drawing List brainstorming

RSS Bot · September 7, 2007

So, here's the latest brainstorming with regards to drawing lists for sprites.

Sprite positioning, due to tight kernel timing constraints, are based upon every scanline whacks of HMOVE. That means the HMPx settings are limiting the difference of horizontal positioning between subsequent sprites in one player graphic.

Put another way, the number of lines without graphics for GRPx is equal to the difference in horizontal position between two sprites sharing that player graphic.

I'm using a judgement code to evaluate each sprite for potential inclusion in the two lists for GRP0 and GRP1 each frame. In order to present the minimum flicker, each sprite in turn is given first chance to draw, more or less guaranteeing that for n sprites over n frames, each sprite will be fully drawn at least once within those n frames.

There's one exception: the user-player-sprite, i.e. the player-character, is always given first priority on the GRP0 player. Thus, the player-character will not flicker, ever.

The judgement process first walks the drawing lists looking for an open slot. An open slot is decided by having no current sprite drawing lines mapped to it. (Repositioning lines and sleep lines are the other two possibilities.) When an open slot is not found, we consider the lists to be solved and continue to drawing the frame.

When an open slot is identified, each sprite is judged by looking at its horizontal and vertical positioning. If its vertical positioning is within the opening, then a computation is made to determine the number of lines needed to reposition GRPx from the prior sprite, to the sprite under consideration, and then to the subsequent sprite. If too much horizontal repositioning is required, no sprite lines could be drawn, so its value is zero. If the sprite would have visible lines, then the number of visible lines is recorded as well as the sprite number, unless a previously considered sprite would have had more lines drawn. (i.e. the first sprite found with the most lines possible visible.)

Logically, that push breaks down to pseudocode like

if (best_lines_seen < this_lines_seen) {
  best_lines_seen = this_lines_seen;
 best_sprite = this_sprite;
}

The lists could potentially display as many as five sprites for each player graphic, if they are aligned vertically, but that situation is very unlikely.

The static-length sprite and drawing-list arrays are undecided slightly as I'm tweaking the RAM usage heavily, but I hope to handle eight on-screen sprites and therefore eight drawing-list entries gracefully. That's the number of hardware sprites on my alma mater Commodore VIC-II chip, and seems to be a comfortable number of moving objects at the very large scale of the 8x6 display grid.

Again, sprites are guaranteed first shot once for number_of_sprites frames, so with eight sprites including the player-character, each sprite would be guaranteed a full draw at least once per 7 frames, or (worst-case) appearing about 1/7th to 1/8th of every second (PAL, NTSC). Not great, but that's a worst-case scenario of all seven non-player-character sprites occupying the same vertical area as the player-character, which is thankfully unlikely.

All this drawing-list processing makes use of INTIM for vertical retrace handling and if I find it running away may get capped off periodically (every n frames use a simpler but less fair mechanism) if the script handler starts to suffer on CPU cycles. (Remembering that Ursa scripts are running under the vertical retrace as well to control these NPC sprites!)

http://www.atariage.com/forums/index.php?a...;showentry=3829