Temperature increases on iOS devices (Iphone 13 pro)

[sonht0555]

I'm using your mGBA core. When playing games for a long time, it gets hot and drains the battery quickly. The problem may be in our mGBA core. Is there any solution to optimize more cores? As I understand it, to reduce heat, it is necessary to minimize CPU activity. Also part is not being able to play the game in battery saveMode, it is an important factor to play the game longer.

[sonht0555]

Or is there any way to optimize the Wasm file?

[thenick775]

Are you playing with fast forward on?

What device model are you using?

[sonht0555]

@thenick775

• I play in normal mode, the game I play is radical red, and sometimes I will turn on FF to go faster (5% during the total gameplay). But most, I don't use FF. I tried switching to https://gba.44670.org/ to try testing, it uses VBA Next core, the phenomenon of high temperature behind the machine is no longer there, but there is no saveState which is a minus point of this core, I have not used it anymore.
• I am using IP 13 Pro.
• By the way, have you started or are you planning to build SkyEmu core yet? I'm looking forward to testing a version of SkyEmu Wasm similar to what mGBA Swam you did.

[thenick775]

I have not started to work with the sky emu core, on my own, this will most likely take a year or two between this and my day job.

It's definitely on the roadmap, but isn't a super high priority right now.

Thanks for the device info, I'll see what I can replicate on my iOS devices!

Most likely the issue is dealing with the way we are handling audio, it's all on the main thread, instead of using AudioWorklets.

I'll have to dive into emscripten primitives to see if that will help.

If it's not the audio, I don't think I'll be able to do much. We're already running -O3 in terms of gcc optimizations, but there could be something I'm missing.

Feel free to do some investigation and open a pr to my mGBA repo if you figure it out!

[sonht0555]

@thenick775
I will try to find out the cause. SkyEmu takes a long time, sorry about my limited understanding. Have you tried to learn how to apply Save-battery-mode in iOS? It is also a solution to force the CPU to not work as much when using the mGBA core. But it's having a problem: the fps drops to 30 :((

[thenick775]

Yep, I definitely see this too, but haven't been able to work around it yet.

iOS power saver mode, or low power mode, throttles the cpu usage of the device down to a flat 30.

This is definitely expected, and without making the mGBA core use less cpu/render cycles, it's probably unavoidable, and a bad idea to try and subvert this behavior.

One option may be to run the game at regular speed internally, and render once every two frames instead of 1 (simulating 60fps while rendering at 30fps). I haven't attempted this, so don't know how choppy it would end up being.

Another is to attempt to run the audio in a background thread using the audio worklet api. I've made some attempts at this when compiling the mGBA wasm binary file, but ran into issues compiling some c library dependencies with -pthread. This is definitely still worth pursuing.

I've looked into the other emulator core you've mentioned in this respect a few times. It's a lighter weight emulator binary, meaning it does a bit less at the cost of being a bit more efficient and smaller.

That core (vba based and compiled to wasm) also slows down while in low power mode, and also goes down to 30fps. Though the effects are less pronounced, potentially because it was already rendering at a lower frame rate, or it's computations are less affected by the throttling.

Definitely worth investigating more imo, but it'll be a good bit of work!

[thenick775]

Also of note, actual css transitions are also slowed down by the browser rendering the react app when in low power mode on iOS.

I think this is also unavoidable to some extent, but wanted to call out that I've seen this behavior extend to more than just the mGBA core!

[sonht0555]

@thenick775

• I also think like you, there have been many times I tried to think about whether I should develop the features of that VBA core, but my limited knowledge of Wasm made it impossible for me to do it. I don't know how to bring modules to Wasm, such as Module.getSave() so that it can be used, for example.
• Regarding 30fps when in save mode, on VBA core or SkyEmu both have used a few tricks to fix it, but SkyEmu is better, almost no difference can be seen, I think it's because the creator of Sky understood it very well. their emulator, and uses OpenGL as a workaround, OpenGL is virtually unaffected by Savemode.
• You have looked at the VBA core, right? Do you think the ability to include Module.getState(slot) and Module.loadState(slot) is possible? Or that core doesn't support getting and loading state.

[thenick775]

In reference to your first bullet point, the emulator core (in whatever language it's written in) would need to support loading save states.

mGBA does this using screenshots, in this case if you download any .ss file from the emulator file system, and change its extension to .png, you'll then see that its just an image. Meaning the emulator core itself is able to restore its state from just an image and maybe some metadata. This is the behavior you would have to add if it doesn't already exist.

Regarding your second point, what tricks did they use? Could you share them here?

If they are using openGL, and compiling to wasm, it would have to be using webGL, or a subset of webGL which we're currently using, but through emscripten and its webgl canvas context that gets painted using SDL2 methods.

And finally, I haven't looked too much into that cores capabilities, I mainly looked into how they were compiling and binding their code to the generated javascript/webassembly code.

If that feature isn't available when running the original VBA, I don't think it would be supported in the wasm port, but can't hurt to look further!

[sonht0555]

I think the css still reacts the same, the problem is that the whole screen is pulled down to 30fps. The only way is to run the game at 2x speed

[sonht0555]

@thenick775

mGBA does this using screenshots, in this case, if you download any .ss file from the emulator file system, and change its extension to .png, you'll then see that it's just an image. This means the emulator core it self can restore its state from just an image and maybe some metadata. This is the behavior you would have to add if it doesn't already exist.

Oh, taking a screenshot is simply saving the state and then changing the .ss to .png
But I think we have to add more metadata to have enough data for the simulator to restore to that state.

If they are using OpenGL, and compiling to wasm, it would have to be using webGL, or a subset of webGL which we're currently using, but through Emscripten and its WebGL canvas context that gets painted using SDL2 methods.

I mean they still process it like that, instead of displaying the data directly on the canvas, they use OpenGL to redraw the simulation and display it again, that's what SkyEmu is doing, the output pixel data is Reprocessed and speeds up drawing by 2x if the screen cannot meet 60fps. (for every 1 fps dropped, it will draw a little faster...) That's how SkyEmu is the most perfect compared to the rest when running in save mode iOS.

[thenick775]

Do you have a link to the code that is doing this?

[sonht0555]

@thenick775

Sky does not specifically specify which parts his core handles. It seems like he doesn't want to share these details in detail. I just asked him to share how his emulator bypasses battery save. Or maybe he doesn't like people who ask as much as me :((

[thenick775]

Can you link to the discussion or issue where you two are discussing this topic?

[sonht0555]

@thenick775 It was in an online chat asking about SkyEmu that I was lucky enough to ask. It is held after each big update of SkyEmu. Since it's on discord, there's nowhere to record it

[sonht0555]

It's difficult, I don't know how to help you :((

[thenick775]

Related: #87 (comment)

[thenick775]

Fixed in #120 🚀

[thenick775]

Noting for context, the heat issue was due to using setTimeout for the most part as a rendering loop instead of RAF, but also is due to performance problems with the way I was initially rendering the emulator context as well.