4 ms·
I did consider it. Infinite scalability isn't required during runtime; the scene doesn't ever zoom or scale in the games, because that was always so slow in Fla
by rogual 4y ago
I did consider it. Infinite scalability isn't required during runtime; the scene doesn't ever zoom or scale in the games, because that was always so slow in Flash, so the only real benefits would be 1) supporting higher resolutions and 2) reducing file size.
For 1) I decided I'd rather just release an update with larger textures if these ones ever start to look dated. That way I get to keep the runtime code simple. Less code means fewer bugs. I don't want to spend a lot of time fielding support requests from users who hit edge cases in the rasterizer. As for not changing too often, that's true, but taking advantage of that means doing change tracking with dirty-rectangles or similar, which not only adds complexity but also feels like it would make performance less predictable.
And for 2) the game as it stands now is under 50MB so I didn't feel a pressing need to make it smaller, although a tiny executable would be cool in a satisfying, demoscene kind of way.
- bambax 4y agoAh, thanks. That could maybe go into the article as well? Although it's already pretty thorough as it is.