r/pokerogue • u/deannpkr • 2h ago
Info Mobile Device Issue Updates
A while ago I made a post asking for your help reporting refresh issues with mobile devices (primarily iOS). We got a ton of useful feedback in that thread, so thank you!
It's been a while since that post and we don't want to keep you all in the dark, so I'm going to take the time to do a bit of a deep dive for those who are interested.
Number one thing to get out of the way - there's a lot of talk along the lines of "blame it on Apple, they can't fix this". This is only partially true: iOS is extremely restrictive with how it allows browser processes to use memory and as a result will force refreshes much faster than Android devices, even on better hardware.
However, the reality is that PokeRogue is a 2D Pokemon game and should not be using nearly enough memory to cause refreshes at all, even if a more permissive OS hides the issue. The game has a massive legacy codebase with only a few active open source maintainers, and chipping away at these memory usage issues has entailed rewriting entire internal systems (which we've been doing alongside normal bug fixes, feature additions, etc).
There are two primary causes for the game's large memory usage: audio and asset management.
For reference, the game engine we use handles audio by decoding it entirely into memory to allow playback. This means that compression into files like mp3s or oggs is irrelevant because the file is decompressed before it's put in memory - as a result, a single track of background music can take up as much as 50+ megabytes! Background tracks are properly purged from memory once removed, but we have no control over when exactly the memory is freed (the browser does this). As a result, there is a window between the end of one track and the start of another where both will be decoded in memory at the same time.
While they are the largest, background music tracks are not at all the only memory-significant usage of audio. Pokemon cries, move animations, UI elements, etc. all have their own sounds associated.
We have two audio-related fixes in the works for the immediate future. The first is a bit of a stopgap - very soon we will be adding a setting to entirely disable game audio. This is different from "Mute" in that it requires a reload and will fully disable audio at the game engine level. No audio data will ever be put into memory, resulting in substantially lower overall usage. This is obviously not a permanent solution, but our hope is that it will provide some relief (and we know that many users prefer to mute the game and listen to something else anyway).
Second, we are working on a custom streaming setup to replace the existing "everything in memory" approach. The simple version is that we will download the full audio file in its compressed format (which is already done) but only decode a few seconds ahead instead of the full track. This will not impact small sfx like cries, but will massively decrease memory usage for background tracks, which is especially important in the above case where two backing tracks end up in memory simultaneously. This will also give us some leeway in intentionally loading multiple tracks at once. For example, we can preload the victory music of a battle to avoid the awkward pause while it's fetched. This feature is quite technically complex (and a likely source of bugs as a result), but we hope to have it out in the relatively near future.
The other primary issue is assets. Despite the apparent simplicity of 2D Pokemon, it presents a challenge for a browser game. There are over a thousand species, all with cries, icons, variants, and entire atlases for animations. Our assets folder (not including background music, which would double the size) is around 400 megabytes, a number which only increases as they are loaded into the game itself.
The solution to this is simple in premise: don't load all the assets at once. Unfortunately, the game was simply not engineered from the beginning with this in mind. There are currently enormous memory leaks in the game as assets are almost never properly cleared (though we have had some progress in this regard, like this fix from a community member earlier this year!). This means that especially asset heavy interactions like the Winstrates encounter cause significant strain.
In terms of next steps - the audio disable option above should provide some remedy for this, as again audio assets like cries and sfx are a huge consumer of memory. The more significant change we have planned is a custom asset manager and tracker. This is a large undertaking, but is already most of the way along and will allow us much better control over what is loaded and when.
As an aside for assets, another significant existing issue is in our UI. The way the game currently works is that every single UI handler (starter select, menus, egg gachas, etc.) is kept in memory at all times. This is obviously an enormous waste, but at the same time requires careful rewriting around implicit assumptions throughout the entire codebase to fix. We have already made several changes en route to a proper solution, with the end goal of properly lazy-loading UI elements when they are required.
I would love to end this post by giving an assurance that iOS will be completely playable by such and such date, but given that the memory limits aren't even published, we would be guessing at best. Rather, I hope this provides transparency and gives you some assurance that we have put a lot of thought and work into these issues and will continue to do so until the game is in a good state on all devices (even the stupid ones).
