Hello,
Just got interested in the project, i have some experience with qt and cpp; also this could take me to a interesting place for learning.
I've seen so much question related to android, in reality i wonder if the translation for android backend could be more efficient because of the ARM architecture.
I'll be getting a decent pc for testing some games i have, but i will love to hear some of the things needed for making a android exec, besides the input, audio, and so on.
You'd need to make an ARMv8 backend for the dynarmic JIT, and create a new graphics backend for OpenGL ES or Vulkan because even high end recent mobile GPUs only support up to OpenGL 3.2
@BreadFish64 Cool i get it.
So now, the emulator have an opengl backend so that would be the easier way to go.
Is there any documents for getting started, like where to start?
Or i'll have to dive in by myself and ask around?
one mobile processor - NVidia Tegra X1 has ARMv8 and full OpenGL 4.5.
but devices... Nintndo Switch and Android TV :)
@adderly Maybe starting on an interface configuring some options can be a good start.
After an intensive research, i need to get pretty familiar with assembler to be able to make a backend. I will start simple, i saw a TODO list. But really no much details about the tasks; which GUI configuration is really needed.
For now the closer start is GUI with qt or the all hailed Command line argument parser impl.
ARM -> ARM recompilation should be pretty straightforward (i suppose armv7 is enough, no need for armv8 64bit).
you may use QT for gui.
but i think, is't the most easy parts of porting
For an easier starting point, the interpreter mode should work on ARM, and the software renderer doesn't require nearly as much work to port.
(of course it'd be slow as molasses but gotta start somewhere)
Yes, i guess it sounds better.
I would suggest perhaps attempting a port to desktop Linux on ARM, first.
Closed as this is not an issue. Wouldn't mind if you hopped onto IRC/Discord to have a chat.
Most helpful comment
For an easier starting point, the interpreter mode should work on ARM, and the software renderer doesn't require nearly as much work to port.
(of course it'd be slow as molasses but gotta start somewhere)