VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

When I try to run UniPCemu when the current commit is build for Android using the android-NDK, I see it booting up, but very slowly(up to 8700 cycles/second usually). Can anyone see why this is so slow? After starting and clearing the CGA screen, it's running at 11000 cyclesd, then back to around 9.5K cycles/second. Is it only so heavy because it's rendering CGA? Or is something else causing it to be this slow(cycle time synchonization using gettimeofday?)? It's running at ~50% when on a 4.0GHz i7 CPU on a PC, but the Android version has always been very slow for some unknown reason. So it's running at 0.2% speed right now.

Can anyone see why it's so slow? Is it simply the VGA rendering? Or is something else slowing it down considerably on these devices?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 3, by superfury

User metadata
Rank l33t++
Rank
l33t++

After messing about with the UniPCemu settings(on a Samsung Galaxy S7), I found out something: The extreme slowness happens only when setting the Direct Plot setting in the video menu to forced? Setting it to automatic or disabled makes it run at ~700K cycles/second emulating a 8088@4.77MHz(with 14.31818MHz base clock)? Maybe a dirty text surface problem, making it constantly render and render the main surface when not needed?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 2 of 3, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found the cause of the odd Android(and probably PSP too, since they're both rendering the exact same way, although different screen resolutions are used) slowness bug: the renderer was constantly rendering 'dirty' frames. But the frames weren't dirty at all: the renderer keeps a flag when rendering frames, to determine if the screen needs to be redrawn. Two of those flags are used: one for the video(VGA, CGA, MDA, SVGA) output(set for every rendered dirty frame) and one for every text surface(set when it's contents have changed). Those two flags are OR-ed together to determine if the screen needs to be redrawn(60 times a second). The dirty flag of the emulated video card wasn't being cleared when it was rendering in Direct Plot mode(either in Automatic mode, with the emulated screen resolution less or equal to the Android/PSP screen resolution or Forced). Thus it was rendering the very same frame 60 times a second. Each time, it also had to render the text surfaces on top of it. This caused it to take so much time, that the emulator core(which runs the CPU, video hardware and all other emulated hardware) barely had any time left to do it's own work, thus slowing down.

Now it's running at up to a whopping 1M cycles/second! (With direct plot forced and no video scaling, running a Compaq Deskpro 386 system with VGA) 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 3, by superfury

User metadata
Rank l33t++
Rank
l33t++

So, when optimizing the view for fullscreen Android(by picking the most visually pleasing video settings with old-style NTSC CGA and enabling all sound hardware, setting the CPU for 8088@4.77MHz), it's now running at 8%. So, while there's still some optimizing and speed improvements left, it's running way better now(for 8088 MPH on your phone 🤣)!

Edit: Trying to use edit.com goes wrong, for some reason messing up the graphics card, but 8088 MPH seems to run nicely. The opening scrolling doesn't seem to have the old troubles anymore! 😁 Although, this may just be timing coincidence or device(floating point) dependant.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io