<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Performance on Wizball Remake</title><link>http://craigchandler.xyz/wizball-remake/tags/performance/</link><description>Recent content in Performance on Wizball Remake</description><generator>Hugo -- 0.150.0</generator><language>en-au</language><lastBuildDate>Fri, 20 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="http://craigchandler.xyz/wizball-remake/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Save And Continue No Longer Feels Painful</title><link>http://craigchandler.xyz/wizball-remake/posts/2026-03-20-save-speed-day/</link><pubDate>Fri, 20 Mar 2026 00:00:00 +0000</pubDate><guid>http://craigchandler.xyz/wizball-remake/posts/2026-03-20-save-speed-day/</guid><description>&lt;p&gt;The save-and-continue work has had a very welcome second phase: it is now fast enough to feel reasonable on the low-powered handheld target rather than like an awkward proof of concept. That matters more than it probably would on a desktop build, because a feature designed around short play sessions immediately loses its charm if stopping to save feels like a long interruption.&lt;/p&gt;
&lt;p&gt;I am deliberately not going into all the engineering detail here, but the broad story is simple enough. The problem was not really the size of the save file on its own, it was the amount of unnecessary work wrapped around it. Tidying up that hot path made a much bigger difference than trying to shave a few bytes off the file itself. The end result is that save and load now feel brisk enough that the whole idea of dipping in, suspending a run, and coming back later makes sense on device.&lt;/p&gt;</description></item></channel></rss>