OK we wait, thanks wwylele, they was no change manually adding the files Anyway, just too many errors on building.
No, but linkmauve had it running on an ARM based Linux device already.
Note that you probably don't have good GL3.3 drivers there, so expect some broken graphics.
Also due to the Vertex Shader JIT only working for x64, it will be very slow (way slower than on any desktop device).
If there will be a CPU JIT in the future it (probably) won't work for non-x64 platforms either.
Note that you probably don't have good GL3.3 drivers there, so expect some broken graphics.
Also due to the Vertex Shader JIT only working for x64, it will be very slow (way slower than on any desktop device).
If there will be a CPU JIT in the future it (probably) won't work for non-x64 platforms either.
I thought phones were x64? or is android N the first, because I've heard conflicting things
Most high end and new phones are x64. In fact Dolphin also is being limited in terms of android i believe to only x64 phones as well for new builds. It's for the best anyways, i bet any old x32 bit phone wouldn't run them
There's still a huge difference between x86_64 (commonly referred to as x64) and 64-bit ARM.
Last edited by Oishikatta,
So, is android N the first 64 bit ARM, when all of the others are 32bit ARM, even though they already have 64 bit OS? Is that why development for Citra Android hasn't started yet or are you guys just waiting to finish the PC version first? I remember one person saying android N is the first 64 bit version of something, which is why there isn't 3ds on Android, and another person told me that there IS a citra for Android already, but I cannot find it anywhere.
Where is the newest windows build after 7/28/16 btw?
Last edited by Jobenblue,
ARM x64 was announced in 2011 by ARM and has been available since 2012. High-end phones have been making use of it since the end of 2014 and nowadays most mid to high end devices benefit from the ARM x64 instruction set.
Support for x64 ARM has been in Android since forever, but didn't really flourish when they changed their compiler from Dalvik to ART (ahead of time compiler) ever since Android 5.0. However, ARM shouldn't be compared to your typical x86-x64 instruction set though.
Not sure if multiplatform is going to be a goal for Citra.
Support for x64 ARM has been in Android since forever, but didn't really flourish when they changed their compiler from Dalvik to ART (ahead of time compiler) ever since Android 5.0. However, ARM shouldn't be compared to your typical x86-x64 instruction set though.
Not sure if multiplatform is going to be a goal for Citra.
There is no "ARM x64". I guess what you want to say is "64-bit ARM". x64 is a CPU architecture mostly seen on PC, while ARM is another CPU architechture (family) most smart phone using (fun fact: so does 3DS, 32-bit though). Although both support 64-bit processing, there is still a huge difference between two architectures. Please don't use misleading word so that people can understand it correctly.
Dose the citra source code take advantage of the two cpu cores, looking though the files seems only uses one, also I'm always wrong lol
268MHz CPU clocks = 268123480 x1 , should be using two.. lots
edit- 268MHz CPU clocks - ARM11 2x MPCore & 2x VFPv2 Co-Processor 268MHz(~268123480 Hz).
2x
268MHz CPU clocks = 268123480 x1 , should be using two.. lots
edit- 268MHz CPU clocks - ARM11 2x MPCore & 2x VFPv2 Co-Processor 268MHz(~268123480 Hz).
2x
Last edited by drwhojan,
Sorry man, I meet milti cores within the citra emulator it self as in the source code to build it, not running from pc cpus
If you mean taking advantage of 2 cores of 3DS, then it is a wrong way to do that.
On the one hand, one of the cores is always reserved for 3DS system (which is rewritten in citra and does not run on emulated 3DS CPU at all) and some times can be partially used by game if specified (which is unimplemented yet). Either way, The core usage should follow what it behaves on real 3DS, which means you can't just "take advantage" whenever you want.
On the other hand, running games one two emulated cores won't benefit anything if you still emulate everything in a single thread. What @DestinyFeather said is actually closer to the essential of problem. If one want to emulate dual core efficiently, he may want to emulate them in two threads and so that they can run on two PC cores.
Last edited by wwylele,
I see wwylele thanks, could be best to stick with his/her option.
Are some how just Frameskip freeze to be fixed some day, I tested it and it is a lot faster at start of game play, just be four the freeze kicks in
[Core]
frame_skip=0 , to 1 fast but freeze seconds later at startup
Are some how just Frameskip freeze to be fixed some day, I tested it and it is a lot faster at start of game play, just be four the freeze kicks in
[Core]
frame_skip=0 , to 1 fast but freeze seconds later at startup
Dayum! This looks clean.
BTW. About the emulator, has no one found the error of Hyrule Warriors Legends? Few months ago(Leo121's build), the game was booted with Geometry Shader and some Scaled Resolution.
It has been noted over 1 year ago in may as an issue. It is from regression basically and some builds removed the commit that caused it.
Similar threads
-
- Portal
