Android makefile fixes,Dont try to overclock superfx every frame

[meepingsnesroms]

Configure new build architecture "armeabi-v7a-neon"(requires new libretro-build-android-mk.sh,also submitted to libretro-super) (V7NEONOPTIMIZATION=1 is set when building for armeabi-v7a-neon) Use thumb as default instruction set.(LOCAL_ARM_MODE := thumb)(on all arm versions) Disable forced instruction set,use arm and thumb opcodes.(-mthumb-interwork)(on all arm versions) Enable non 32bit aligned access on armv7.(-munaligned-access)

These changes should be applied to all cores,this makefile can be used as a template.

[inactive123]

check_variables is used for all potential core options, not just for SuperFX. Yes I know SuperFX overclocking is the only core option so far, but still, normally you shouldn't comment this out, it is there for a reason.

[meepingsnesroms]

But that is the only core option this emu has. On Jun 6, 2016 12:29 PM, "Twinaphex" notifications@github.com wrote:

check_variables is used for all potential core options, not just for SuperFX.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/snes9x-next/pull/68#issuecomment-224062355, or mute the thread https://github.com/notifications/unsubscribe/ABKgxeF-FGqlOb3LLCZiFWWTJbYG772wks5qJHUOgaJpZM4IhhiE .

[inactive123]

I already addressed that in the previous post, scroll up.

Anyway, please split this up from this PR. Also, does your Makefile changes introduce any potential compatibility issues? Platforms that have an ARMv7 CPU but no NEON (like Tegra 2) would no longer run I imagine. Is it really worth it? I doubt it gives us any great speedups to build with NEON support.

[meepingsnesroms]

I will remove it than.

No this will only output neon code if you set the variable to true/1 so it is still compatible,plus changing from compiling for arm to thumb almost halves the exe size and that makes more fit in the cache and less fetches.(thumb works on all armv7 and v6 platforms)

Thumb uses 16 and 32 bit when needed instructions so 2 instructions per fetch on average. On Jun 6, 2016 12:31 PM, "Twinaphex" notifications@github.com wrote:

I already addressed that in the previous post, scroll up.

Anyway, please split this up from this PR. Also, does your Makefile changes introduce any potential compatibility issues?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/snes9x-next/pull/68#issuecomment-224062817, or mute the thread https://github.com/notifications/unsubscribe/ABKgxXNsuZpr1tW_YWrgi0SOFVwFyTDNks5qJHV3gaJpZM4IhhiE .

[inactive123]

Anyway, I guess as long as we only have one core option anyway, it doesn't really matter.

Have you confirmed if SuperFX overclocking still works though when we manipulate the core option?

If you have confirmed it works, I am fine with merging this.

[meepingsnesroms]

Sorry about asking when you already answered,githubs email server cut that off and I replied by email.

[meepingsnesroms]

Yes I have confirmed super fx overclocking still works it checks every reset so you just have to reset in the menu.

[inactive123]

What? I didn't read that part before merging. So you have to select 'Reset' before it will update the SuperFX overclocking value?

Isn't this extremely inconvenient? Please change that back and send another PR if so.

[meepingsnesroms]

If there is ever something that needs to be checked every frame (like enable/disable SNES GPU layers) then it is fine if you remove it,I just wanted to save those extra 10 Opcode's per frame.

[meepingsnesroms]

Actually no,when I changed the over clock value in game in yoshis island (before I made this change) it hung.

[inactive123]

Yeah, please put that conditional back in retro_run then, at least it will work whenever we change the value then.

[meepingsnesroms]

OK. On Jun 6, 2016 12:50 PM, "Twinaphex" notifications@github.com wrote:

Yeah, please put that conditional back in retro_run then, at least it will work whenever we change the value then.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/snes9x-next/pull/68#issuecomment-224067891, or mute the thread https://github.com/notifications/unsubscribe/ABKgxdHMVjo7lBBWjZ-ZtMNYlig-wMPcks5qJHn8gaJpZM4IhhiE .