SP1 Scrolling: Performance Review
In this section I have compiled the performance characteristics for all the previous tests. For this, I have needed to normalize the code so that comparison between measurements are meaninful.
I have disabled the regular ROM interrupt processing and activated a minimal IM2 interrupt routine and performance counter in all the previous SP1 examples, so that we have a consistent way of measuring the performance of all of them.
Performance is then measured as a Frames Per Second counter which is shown every second at the bottom left corner. It is interesting to see how it changes depending on the number of tiles on screen and the different algorithms used for updating the scrolling zones.
Synchronizing to screen retrace via HALT instruction has also been removed in all tests, since it is not needed in SP1 games, and also allows us to measure the raw speed with no artifacts.
Finally, all scroll areas have been normalized to a 16x16-cell zone, and the number of sprites has been set to 6 in all tests that have them.
The following table resumes the measured performance on each of the tests:
| Test # | Directory | Description | FPS |
|---|---|---|---|
| Test 0 | sp1-baseline | PoC to test raw performance of SP1 updating whole scroll area | 22 |
| Test 1 | sp1-randomtiles | Whole scroll/top-row-update loop, full column scroll and invalidation | 17-18 |
| Test 2 | sp1-sprites | Test 1, with added moving sprites | 13 |
| Test 3 | sp1-partial-inv-1 | Test 2, with added partial column invalidation, method #1 | 17-25 |
| Test 4 | sp1-partial-inv-2 | Test 2, with added partial column invalidation, method #2 | 20-25 |
| Test 5 | - | Not implemented | - |
| Test 6 | sp1-parallax | Test 3, with 2 added parallax zones scrolling at different speeds | 11-17 |
Conclusions:
- For a 16x16 scrolling area, a baseline framerate of 22 FPS shows that scrolling games with SP1 are quite a possibility, given that SP1 conveniently integrates background and sprite management in a single library.
- The scrolling routine is not the critical part, but the SP1 update is. Initial baseline measurements indicated that the scrolling code spends only around half a frame for scrolling an area of this size, and the rest of the time being used by SP1.
- The optimizations done in Test 3 and Test 4 (partial invalidation instead of fully invalidating the whole scroll area) are indeed valuable and make the FPS ocassionally reach the baseline measurement, and even a bit higher. This is quite remarkable, given than on these tests we have sprites moving all around. Optimization in Test 4 show slightly better performance than Test 3.
- In both Test 3 and Test 4, results depend highly on the number of visible background tiles, which is to be expected.
- The parallax effect, contrary to what was indicated in the previous statements, generates a measurable additional load with respect to code with a single scrolling zone.
- For a scroller game with a single zone (no parallax), the better algorithm seems to be the one in Test 4