x86 support

[lastrega]

I just bought a new HP 7 tablet. It is an x86 model. Pretty decent chip set. However for the first time I get laggy performance. I have drastic on 3 other tablets. They are arm based. One is a tegra3 the others are dual core. They run great. Any suggestions on the settings, to increase performance. Any help would be super, as Iwant to use my new x86 for drastic pprimarily. Thanks. In advance.

[beansta]

Its laggy because of the way DraStic is coded. It has been made to take advantage of the NEON arcitecture on newer ARM chipsets. X86 (and tegra 2) chips dont have this instruction set. While 2.2.0.0a brought compatability for those mentioned chip types but they will be slower and there isnt a whole lot that can be done.

[Lordus]

Which tablet is it exactly?
Please try to set the audio-latency to 'very high', i've seen that making a big difference on X86 devices.

[lastrega]

Thanks for the response. I have tried all the latency setting position. Bout the same. I have an HP 7 1800 lp with an Intel atom CPU, Mali GPU and 1gb ram . thanks for your time.

[Exophase]

This tablet uses a 1.6GHz Medfield CPU, I'm afraid it's a lot slower than what we tested on because it only has one real CPU core. DraStic uses optimized NEON code for 2D and 3D rendering, but on Tegra 2 and x86 systems has to fall back on slower C code because those systems can't run NEON instructions. Since version 2.2.0.0 the emulator uses multiple threads to render 2D and 3D, which helps offset the slower code on systems that have multiple cores. But the single-core x86 users are still hit hard.

Honestly I'm surprised that a relatively recent tablet is using such a dated chip. It's probably too late to do anything about it, but if you're able to return it (but definitely want x86) I'd strongly recommend trading it for something with much better specs like Dell Venue 8, which costs pretty much the same thing.

[lastrega]

Yeah it is only single core, but very zippy... Runs most apps better than my dual cores... So far the only app that lags is drastic.. I understand, why a Ds is an arm cortex device, and my single core X86 has to emulate the processing of an arm and the actual program... No worries it runs , just has audio lag.. And o have good arm devices.. I can also kill any running apps and it helps greatly.. Just wondered if any other setting would help.. Thanks for your time.. Though... I'm not going to return it. It runs everything else flawlessly. It would be a shame to return an entire tablet because it won't run one app.. Runs six guns and games like shadow gun at 60 frames per, so not gonna happen.. But thanks for the advice.

[lastrega]

Interesting update, for some odd reason, it works at almost 100 percent with no lag, while the device is unplugged. My test were with the charger plugged in. Have no clue as to why it runs so much better unplugged, but by god it does.
And luckily drastic causes little battery drain.. Ran final fantasy 4 cuts sciences perfectly, yet I even confirm my findings, cause I plugged it in while playing and almost immediately it started to skip like the Dickens. No clue as to why. But maybe the devs can make a note of this issue, and if any one else buys either an hp7 or similar x86 chip set, then we have a solution sorta.. I installed a fancy battery monitor.. I will keep track of all my findings. And make notes while plugged and unplugged. Weird huh? But any who great emu all the same... You guys rock... Thanks to all who took time to help me. PS I made a plugged and unplugged video if anyone wants to see it. Leeme know and I'll post it to YouTube. Kinda neat to see how fast it messes up once plugged in.

[Exophase]

Sorry, I have no clue why it'd run better when not plugged in. You would think being plugged in would relax the power draw limitations put in place to conserve battery life. The only thing I can guess is that when you're plugged in but not at 100% battery power the system is charging, and the charging circuits increase the temperature of the device which lowers the turbo boost headroom. Do you know if this happens when you're at 100%?

Android devices are always causing weird problems that are hard to debug, because there is so much freedom given to device makers and users to configure it into so many possible states. In one game I've played two very different Android devices would always crash at a certain highly arbitrary point after a cutscene in an optional part late in the game.. and this is a pretty popular game so I figured this would be a known issue but I couldn't find anything on it. I eventually figured out that the crash would only happen if headphones are plugged in. Try and explain that one.

[lastrega]

Ha ha ha .. That's awesome. Cheers

[TnA.Plastic]

There also could be either a thread, which is causing high CPU-load (due to it being a single-core-cpu, there's no real multi-tasking, the CPU has to switch between tasks and an Emulator is heavily affected by the latency and to keep it in sync the other emulated stuff has to wait...), or if the power-controller doesn't suport it,... It sucks to less power from Cable, or atleast to less power to simultaneously load the battery and run on full performance...

Back to the ear-phone-isue, I'd say either the ROM has a too much direct way to call the hardware, or the abstraction is bugous, OR the sound-Emulation has some kind of way to determine, if something is plugged or not (which needs two-way-communication between sound-Emulation and the Android-abstractionlayer...).

Btw.: Thank you very much, for adding support for x86 and non-NEON ARM-CPUs! Does it work with MIPS as well (if there's a MIPS-based Android-Device)?
Even thought C-Code isn't as efficient as using NEON-Instructions on those supporting it, it still works very well on my Samsung Galaxy Tab 10.1 with Android 4.4.2/Omni-ROM (19.1.2014-build) and A1-Kernel. Regardless if I overclock, or not. Even without frameskip and no multi-threaded rendering it works Stil good!