Explaining Low Latency, Delay, And Optimization

Low Latency, in simple terms, is when you have minimal delay between the time you press your buttons, aka taking an action to send to the computer and the time it actually takes for that action to be processed. For example, if you have low latency you will have very minimal delay and in osu! it will appear at the bottom right as low MS. If you have high latency you will have a noticeable delay and will have high MS in osu!. Here are some screenshots for better representation.

Now you might be wondering what my skins have to do with this? Or how can an osu! skin cause lower latency? Well, basically, most of them are 2 aspects: the hands and the file size. One thing you notice with larger skins like cookiezi's skin, for example, is that they have many useless files that, most of the time, aren't even being utilized for anything and this leads to a lot of them being over 50 MB in size, which in my opinion, is obnoxiously large for something as simple as an osu! skin. Other than this, bigger files take up more space on your SSD or HDD. They also come with more processes the computer has to run in order for them to function properly, meaning that on lower-end PCs and typically "outdated" hardware, these large skins will indeed cause a relatively noticeable difference and performance decrease commonly in the form of microstutters or random signficiant changes in latency, which is where my skins and many other skins labeled under "Ultra Lite" come in handy. The largest skin I have is "ckz.2c" at a size of 1,755 KB. with the smallest being "xsh.2c" at a size of 1,617 KB. You might be thinking, "Oh well doesn't that mean you have to like strip the skin clean and sacrifice many eye candy features just to lower the file size" you see in theory this would be true, but actually I sacrifice next to nothing to make these skins low file size whilst also still making them feel "complete" in the sense where some skins that are stripped clean just feel like test subjects rather than completed things. Using compression tools, 44byte pngs, 64 bytes of silent WAV's, and making sure to not have any unused files at the time of the skins' completion, I am able to achieve an incredibly low file size without sacrificing any important qualities whatsoever.

Most popular skins tend to come with @1x's, like "followpoint-1" and @2x's, like "followpoint-1@2x". You can associate @2x with, meaning double the pixels and double the quality because that's what they are, and you can associate @1x with images in their original form at their base size. Another important thing about @2x's is that they are the file that is in priority, aka the file that is being actively used. Knowing this, you can safely delete every file @1x as long as it has a @2x present. Doing this saves file size as well as confusion when navigating skins in the folder. The way @2x works is by taking an image that is a certain size in pixels, for example, "400x400" and halving it to "200x200" pixels in game. This means that there is a "400x400" pixel file being shown as "200x200" but with the exact same quality as if the file were "400x400" pixels. As expected, though @2x's are almost always larger than the original file that was being upscaled, meaning they take up more space but As of recently, I have found that with image compression, the file size is decreased by 50–90% whilst keeping equal in-game quality due to maintaining the @2x. For example, I'm going to show a few images of an approach circle going through the file changing stages I follow while making my skins.

For context, an osu! skin has 7 main sound effects that it uses across 3 different samplesets (21 files total). On most competitive skins, sliderticks, sliderwhistles, and sliderslides are all muted files. Therefore, knocking the audible number down by 9, making it 12 sounds in total (4 for each sampleset). The key four I will be talking about here are hitwhistle, hitnormal, hitfinish, and hitclap. As we see here from these screenshots taken in Audacity, Rafis has unequal delay on all 4 of the key samples that are actively being used, with the most delay being seen on the soft-hitfinish and the least amount of delay being seen on the soft-hitnormal. Differences in delay may cause your tapping to be inconsistent when certain samples are played and delay in general will cause your tapping to be well, inconsistent in general. Luckily, something like this is a very simple fix that anyone can do (Audacity is free). All we need to do is simply cut out the delay of the sound and make the sound start where the first highest peak is.

Very simple and now the hitsounds don't have any delay, and they also come with the bonus of being a slightly lower file size. Always remember before you put on offset to check if your hitsounds are delayed or not. You might play poorly at first if you have been using delayed hitsounds for a long time, but in the long run it will do you more benefit than playing with delayed hitsounds did, and you will start to notice accuracy improvements on every type of map. Also, if you want to fully minmax your hitsounds, you can do what I do, which is adding a fade-out filter, then cutting the remaining blank audio space to save some more KB's.

I hope this little explanation helped clear up some confusion regarding this topic. Thank you for reading :3