Jump to content
  • entries
    657
  • comments
    2,692
  • views
    897,937

major performance improvement


SpiceWare

837 views

There's so many variations of each station (pods intact/destroyed, various state of center) that it's not practical to have each version in ROM. Instead, an intact image is in ROM for each orientation. Once per frame a RAM copy of the image would be made for each station, then it would be manipulated to remove destroyed pods and update the center. The RAM images are used for collision detection as well as display purposes.

 

While reviewing the code I realized that the open/close logic for the center only updated 1 station per frame. So only that station's RAM image would need to be updated, as well as any stations the player destroyed a pod on in the current frame. For all other stations, the RAM image was already correct.

 

So I added a render flag that gets set whenever a station's image needs to be updated. I figured it would save some time, but had no idea how much, so I started a round of Alpha Sector 3 on Kids level so that all 8 stations were always open (and thus nothing would need to be rendered). Using the original routine, time remaining in OverScan at the start of the game was $13 (19 decimal):
blogentry-3056-0-40804800-1506647648_thumb.jpg

I then made the changes to implement the render flag and ran A-3 Kids again:
blogentry-3056-0-92193000-1506649715_thumb.jpg

Time remaining in OverScan increased to $21 (33 decimal) :-o (the Vertical Blank time changed from 16 to 15 due to having to draw an extra asteroid)

So not having to update any of the stations freed up (33-19)*64/76 = 11.8 scanlines worth of processing time, so on frames that a station changed we'd use 1.5 scanlines per station. Worse case scenerio would be somehow the player hit 4 pods on the exact same frame, highly unlikely, so I suspect that the typical max number of stations to update will be 2.

Besides that, the continue option now resets the various timers.


For Harmony or Stella (requires Stella 5.0.2 or newer)
draconian_20170928.bin

Source
draconian_20170928.zip

  • Like 1

2 Comments


Recommended Comments

Can you explain a bit about how the XOR algorithm works as I'm struggling to follow it from the code? I think you start with a base station image in RAM, then draw the pods into a second RAM buffer, then XOR the second buffer into the base station image. I'm curious why the second buffer is required? Could you simply draw the pods on top of the base image, or xor them directly onto the base image without the buffer?

 

Chris

Link to comment

Process works like this:

  • initial image copied from ROM is the intact station
  • update center core
  • when a POD is destroyed most pixels are turned off, which would work with AND, but sometimes pixels are turned on, so I use XOR
  • adjacent PODs sometimes flip the same pixel(s), so we can't XOR each pod separately, requiring me to OR the destroyed POD data together first, then do the XOR at the end

I'll add a comment to the source as I'm sure others may wonder about that at some point.

Link to comment
Guest
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.

Loading...
  • Recently Browsing   0 members

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