SpiceWare's Blog

It will contain a 0 whenever Player 0 needs to be repositioned (1 is used for black).

That's cool. I was considering the same approach back when I was working on an unannounced project a while ago. In my case, I decided to put the reposition signal in the PF0 data instead.

I use a 0 value on PF0left to trigger end-of-display-kernel so I don't have to count scan lines. It's on a fractional data fetcher set to fetch each byte 5 times for NTSC and 6 for PAL. When there's a door being drawn I just set one of the bits in the lower nybble so it doesn't abort early.

 

I do have an idea to triple-purpose the PF0left datastream - unroll it and use it to update both PF0 and one of the ENAxx registers from a single data fetch - it would save 2 cycles per scan line and could be the difference between drawing 2 or 3 shots per frame. I don't want to update missiles mid-scanline as that would cause problems with the software collision detection. There's a little extra time on the edges though as the shots won't ever be on the leftmost 12 pixels or rightmost 12 or 8 pixels(depending on Berzerk or Fenzy maze style) of the display.

 

I'm also thinking about shifting all the RESP0's to trigger 1 cycle earlier as P0EarlyHM71 causes the program to jump back into the main kernel loop 1 cycle late. Wasn't an issue when I worked out the routines for Chun Li, but could be for this. That'll just require the ARM code to be tweaked in how it figures out which EarlyHM routine to call for the repositioning. I plan to work this out before implementing Repositioning for P1.

Heh-heh. I like that pal version robot! Looks more detailed under the ribs.

One thought did come to mind though. If the gfx in pal will be squished a tad, maybe it will be good to trade a scanline from the mid section for a larger chest or the rib area will look too tall and the upper chest to thin.

 

 

I'll PM you that modification since I can't post any images in blog replies.