Jump to content
  • entries
  • comments
  • views

Repositioning for P0



hardcoded sprites for testing the repositioning routines for Player 0. There's 2 DataStreams, 1 for the color and another for shape. The color stream is always read first. It will contain a 0 whenever Player 0 needs to be repositioned (1 is used for black). The reposition prep is contained in the next 2 Graphic Datastream bytes and the next Color Datasteam byte, so a reposition takes 2 scan lines.


At the moment I'm using Early HMOVE so there's no black bars on the left edge of the screen. Because of the maze layout, the bars would only be noticeable during the room shift when you exit to the right, so I may revisit this later if cycle constraints dictate reverting to a normal HMOVE.




I believe I'll need to handle Player 1 differently, setting it to use VDEL so I can update it at any point during the scan line. Because of this, a reposition of Player 1 will most likely take 3 scan lines instead of 2.


Sorry, but there won't be a PAL ROM for a while as the routines are currently hardcoded for NTSC. Speaking of which - instead of PAL having squished images, I think it would be slick to have slightly modified graphics for the PAL version. Here's a mockup of what I'm thinking with an NTSC robot on the left, PAL on the right.

blogentry-3056-0-65204600-1306369743_thumb.png blogentry-3056-0-15841900-1306369748_thumb.png









Recommended Comments

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.

Link to comment

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.

Link to comment

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.

Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...