Jump to content

major performance improvement

Posted by SpiceWare, in Draconian 28 September 2017 · 429 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):
Attached Image
I then made the changes to implement the render flag and ran A-3 Kids again:
Attached Image
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)
Attached File  draconian_20170928.bin (32KB)
downloads: 34
Attached File  draconian_20170928.zip (666.12KB)
downloads: 34

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?



  • Report

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.

  • Report

Search My Blog

Recent Entries

Recent Comments

Latest Visitors

0 user(s) viewing

0 members, 0 guests, 0 anonymous users