Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tilemap optimisations #626

Merged
merged 6 commits into from
Mar 8, 2021
Merged

Conversation

Daft-Freak
Copy link
Collaborator

@Daft-Freak Daft-Freak commented Mar 2, 2021

Reduces "Super Blit Kart" render times by 8ms and makes the track rendering > 2.5x faster. First commit also means you can put something in the tile index you have defined as empty for other uses.

(I also have some patches for sprite stretch blits, but I think those need more work/testing)

Doesn't have a noticable effect, but is less instructions.

(Maybe ~0.1ms saved)
Convert to using fixed-point and skip/combine pixels where possible

Saves ~6ms in blit kart
wc += dwc;
doff++;
c--;
} while(c && (wc.x >> fix_shift + 3) == wcx >> 3 && (wc.y >> fix_shift + 3) == wcy >> 3);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, warning on every compiler...

@Daft-Freak
Copy link
Collaborator Author

Hmm, very slightly worse for drawing a non-scaled fullscreen hires tilemap (< a millisecond). Though that's already a suboptimal case... (looking up the tile for every pixel when it isn't going to change for 8 most of the time)

More numbers:

  master kart-opt-tilemap
hires 13ms 13.2ms
hires half scale 13ms 7.3ms
hires quarter scale 12.8ms 4.4ms
kart mode7 12ms 4.5ms

Special case for translation only : ~5ms

@Gadgetoid
Copy link
Contributor

Thank you!

I think the benefits to mode7 far outweigh any minor drawbacks, though I notice this still has optimised cases for fixed-size spritesheets and it would be interesting to see what happens if arbitrary limits like those are lifted. I think some chatter on Discord suggested this change gives enough headroom for that not to be a problem?

I've a strong preference for simplicity over optimisation but if we're not hitting draw times that get us comfortably within 50fps.... well it doesn't matter how easy to use something is if it tanks your framerate.

The lack of FPS counter on Tilemap Test/Demo is conspicuous when testing this change 😆 but I can't see any perceptible drawbacks in our - granted, very basic - examples. Nice work!

@Gadgetoid Gadgetoid merged commit b519a05 into 32blit:master Mar 8, 2021
@Daft-Freak Daft-Freak deleted the kart-opt-tilemap branch March 8, 2021 11:39
@Daft-Freak
Copy link
Collaborator Author

At least for the mode7 case, removing the "power of two bounds" and "16 column spritesheet" restrictions cost ~.2ms each. I think it had a much larger impact on the non-scaled case though. (Since it's then affecting every pixel).

(I kind of like the 16 col restriction though as it makes the max-size spritesheet square)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants