i bet the shield can run mame 139 fine…can you ask squarepusher to try your 139 core with it?
The author of mame4droid has already said he can run pretty much all 2D games in mame including all the Mortal Kombat games, Killer Instinct 2, and NBA Maximum Hangtime…all at 100% full speed on v0.139. Check out the thread at MAMEWorld.
Guess we can do a more recent version of MAME then too - but I will still keep MAME 0.78 for slower devices. RetroArch and libretro are about maximum portability and about keeping everybody happy - not just those on overpowered devices.
BTW - I just read this on MAME World from RBelmont:
Maybe, yes, no, no. Shield is a great leap forward for ARM, but in x86 PC terms it’s about a high-end Pentium III or original AMD Athlon.
I’m sorry, I hold a lot of respect for RBelmont and still do, but I have to say something about this - this is laughably wrong - in fact it’s so shockingly wrong I am shocked it even comes out of the mouth of a guy that I hold in such high regard Even a PS3 single-core (one of the absolute worst pieces of crap that can be had in microprocessor terms - in-order execution, LHS stalls of 500ms, terrible IPC) can compete with a Pentium 4 2.4GHz PC as has been confirmed in RetroArch tests. A Shield is way beyond that - beyond even a Core 1 laptop and more into Core 2 Duo laptop territory.
These kind of uneducated performance guesses can be prevented by just running a project like libretro/RetroArch and being able to test the same code on a wide range of platforms - I can objectively, 100% accurately state performance figures because of the fact that every libretro port can be made to run on every RetroArch frontend that has been made for all these consoles/OSes - and the amount of “platform overhead” that exists between RetroArch ports is so minimal that it might as well not exist.
No way in hell can a high-end Pentium III or original AMD Athlon run every non-coprocessor game with bsnes/higan performance core at fullspeed like the Shield does. Note - that is v0.92 for you - that already is massively slower than previous versions because of 30bit color and other design issues that really set performance back a good 6 to 16 percent.
He can already test this for himself really - just download RetroArch Android, run it on your Shield, run bsnes/higan performance core. See how every non-coprocessor game is fullspeed. Now try getting that out of a Pentium 3. Good luck - you will need it because it just ain’t happening.
Good to keep 2 versions of mame , i 'm happy that i can still play tetris,pbobble,tatsujin,wardner… on my old phone 
but true it’s good also if we have another version for pc or recent devices.
Im sure squarepusher don’t need me to test it ( and if eventually he needs , he know who ask )
BTW im not releasing here the library , because my port was quick and bad and then i m not ready to release the source code for now , and no source code = no binary …
BTW it not very hard/long to port it to libretro , the longer is to clean code and do it in the good manner ( no quick & bad like me due to my incompetence in C++ ) .
7rtype - go ahead and release your source though on a repo - I’ll be glad to whip it into shape - so don’t worry about the initial quality.
I’m pretty stoked for a newer MAME version so the quicker we can get to the stage of something working the better.
Ok ,so i will push it in on my git later ,
i’m not @home and don’t have access to the source code for now, only the core on my phone
edit : done , it’s on my git , so let’s go ahead …
Yeah, already forked it but can’t get it to compile on x86_64.
It would have really helped if you had made the initial commit the original MAME source instead of it having your changes already merged - guess I need to run it through a directory diff.
You did use the untouched MAME sources right instead of that Android fork? That would make me feel a bit better about it.
Yes i start it with the original mame 0.139 src. ( but with mess src merged)
and yes not ideal to start with my change in the initial commit 
in fact , i just push this one just in case of someone want to test it on the shield ( because it’s very slow on my old htc)
If you have time and not pressed ,i ll delete this one tomorrow and start a new one with original and then only after apply commit .it will be more logic and simple , and give me chance to redone some bad stuff in a more proper way!
for x86_64 , i don’t know as i compile it on my 64 bit system with my 32 bit chroot .
If you have time and not pressed ,i ll delete this one tomorrow and start a new one with original and then only after apply commit .it will be more logic and simple , and give me chance to redone some bad stuff in a more proper way!
OK, go ahead. Do whatever you think is best.
I’ll try with my fork seeing whatever I can piece together on my end and whether or not I can quickly run it on Shield.
I’ve redone the repository , start with http://www.mamedev.org/downloader.php?file=releases/mame0139s.zip for the first commit and then commit and apply the minimal hack to done it works with libretro .
I thinks you should start from this one instead of the old one
it’s not finish and perfect , but for now I’ve successfully build for pc linux & android and tested some games on my devices.
But it’s really slow on my android phone & tablet , only pc is fine.
So i really want to know how it run on the Shield
Cool. I’ll check it out.
Hello and thanks for your work 
Do you know if it’s possible to add an option to set the sound buffer to reduce the audio latency because the Shield has a terrible audio lag…
Compared to other Android devices, Shield already has a “low audio latency” (yeah, believe that …). I don’t think we are using the real low-latency interface in 4.2, but iirc only the most recent nexus devices actually support that.
Implemented buffer size querying for Android 4.2 and up today - it will then determine the audio latency to request based on that.
I tested it on Shield - it was a marked improvement for every core except N64 (but that is probably hamstrung by other external factors I believe). Anyway, Shield should now default to 1024 buffer size and 32ms requested latency - so at least cut in half compared to what it was before.
Great ! So you have a better latency now on retroarch ? You will post it on the store ? (or maybe an apk to test ?) Thanks for your work.
It was a false alarm.
What that MAME4Droid dev suggested COULD have been of use, if
- The property PackageManager.FEATURE_AUDIO_LOW_LATENCY would have returned true on Shield. It doesn’t.
- Therefore, the buffer size (in frames) of 1024 (as reported by AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER - we can’t trust it.
- I have tested with a queryable refresh rate of 32 instead of 64 (which is the current default) - all cores ran fine except for the N64 core with Super Mario 64, OOT and GoldenEye - presumably because those games run between 20 and 30fps and 32ms is far too low of a latency figure to be able to properly handle that without audio crackles (maister can explain that some more if he wants). Therefore, even if we were going to set it at 32, it wouldn’t work out for the N64 core.
And besides, these latency figures that you can tell OpenSL to use - it does not mean that this is actually what you get out of the device during output. Somewhere there is some additional processing expounding on the lag - really, in the end, it all boils down to - ‘massively inferior to iOS’ CoreAudio’. That is the Cliff Notes right there. Even the best on this front (Nexus 7 2013) still has two times higher audio latency than iOS. You have to learn to deal with it. There is no such thing as “low latency audio” on Android compared to something like PC or iOS - it is simply vastly inferior, probably always will be unless Google makes more strides forward.
Anyway, maister can go more indepth if he wants to.
Bottom line - setting querably latency at 64ms should be fine on Shield - it’s playable. No, perceived latency is not 64ms - more like 100ms or more - but that is still very good compared to some of the other devices I’ve seen running.
If you really want low latency audio, go get a LInux PC with RetroArch with an Intel GPU and run in KMS mode - or, failing that, use a PS3 - both the video driver and the audio driver have been made with the lowest possible latency in mind on there. I’m quite proud of the audio/video latency I managed to achieve on the PS3 port - there is a real big difference in fluidity between that and something like your average Android device.
Still, only the obsessive will ever notice these audio latency discrepancies - but then again, that kinda seems like our target audience to begin with.
@squarepusher
I dont know if you have test 0.139 on the shield , but i saw the shield video of Mamedroid by SNESFAN http://www.youtube.com/watch?v=vPEd-LISy5Q and seems to be fine except for some games . you can see the the auto-frameskip in video.
For the 64 bits compile , i’ve check and now it compile fine , at least for me , on my 64 bits system ( i have to export PTR64=1 because autodectect failed for me) .
Still doesn’t compile for me on x86_64 Linux:
g++ -DCRLF=2 -DINLINE=“static inline” -DLSB_FIRST -DNDEBUG -pipe -O2 -fno-strict-aliasing -Wall -Wcast-align -Wundef -Wformat-security -Wwrite-strings -Wno-sign-compare -Isrc/mame -Iobj/retro/mame/mame/layout -Isrc/emu -Iobj/retro/mame/emu -Iobj/retro/mame/emu/layout -Isrc/lib/util -Isrc/osd -Isrc/osd/retro -Isrc/lib/expat -fPIC -fsigned-char -finline -fno-common -fno-builtin -fweb -frename-registers -falign-functions=16 -fsingle-precision-constant -DPC_BUILD -DRETRO_AND -DRETRO -DALIGN_INTS -DALIGN_SHORTS -DLSB_FIRST -fstrict-aliasing -fno-merge-constants -fsigned-char -finline -ffast-math -fsingle-precision-constant -x c++ -std=gnu++98 -c src/mame/mamedriv.c -o obj/retro/mame/mame/mamedriv.o In file included from src/emu/emu.h:54:0, from src/mame/mamedriv.c:18: src/emu/eminline.h: In function ‘void* compare_exchange_ptr(void* volatile*, void*, void*)’: src/emu/eminline.h:349:60: error: cast from ‘void*’ to ‘INT32 {aka int}’ loses precision [-fpermissive] result = compare_exchange32((INT32 volatile )ptr, (INT32)compare, (INT32)exchange); ^ src/emu/eminline.h:349:76: error: cast from ‘void’ to ‘INT32 {aka int}’ loses precision [-fpermissive] result = compare_exchange32((INT32 volatile *)ptr, (INT32)compare, (INT32)exchange); ^ src/emu/eminline.h:351:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] return (void *)result;
Ok i seem i had the same error before i force PTR64=1 variable , seem autodetect 64 bits system failed .
with the the last commit on my git i build for pc linux64 with :
make “NATIVE=1” “PTR64=1” buildtools make “platform=unix” “PTR64=1” emulator -j4
and for android (my host 64 bits after setup android standalone toolchain)
make “NATIVE=1” “PTR64=1” buildtools make “platform=android” emulator -j4