Open GoogleCodeExporter opened 8 years ago
Compile mame4droid is really simple. Install android ndk to get a toolchain for
armabi.. Install eclipse and android sdk as well... You can follow google
instructions at google developer... The only little trick that you need to do
is copy the native lib to jni lib folder and rename to proper .so name
Original comment by seleuco....@gmail.com
on 24 Feb 2012 at 5:16
Ok, thank you. Unfortunately it's those simple things that I do not know, maybe
because I'm not Android developer, but I do know my way around MAME, so please
give us some more details just to get me started:
Q1. What version of Android SDK are you compiling with?
Q2. I have Android-7 (2.1) and Android-8 (2.2) SDK installed on Windows, I hope
I will be able to use that. Therefore, could I just take already built .so
files from the .apk and then finish the compile on my system without needing
Linux, armabi toolchain or NDK at all? -- That would be the most convenient,
assuming the code I want to change is not in .cpp files, or so it would seem.
Q3. Well, in any case I did try to compile what you have in that separate
"Android" folder and got the following error:
MAME4droid\res\values-v11\styles.xml:20:
error: Error retrieving parent for item: No resource found that
matches the given name 'android:Theme.Holo.NoActionBar.Fullscreen'.
I have no idea is this due to mismatching Android SDK version or I am not
actually supposed to do it that way at all, so please point me in the right
direction.
Original comment by zelko...@gmail.com
on 25 Feb 2012 at 9:23
[deleted comment]
Got it! Here is what I did in case anyone is interested... I managed to find in
"manifest.xml" you were using Android-11, so the error I got made much more
sense and then I downloaded latest SDK, Android-15, which then compiled
everything fine, except folder "lib" was missing from the .apk completely. So,
I took the libs from your .apk and placed in "JNI" folder like you said and
that didn't work actually as resulting .apk was still missing "lib" folder,
then I placed those libs from ".apk/lib" folder (both complete armeabi &
armeabi-v7a folders) into "Android\MAME4droid\libs" folder instead, and this
time ANT compiled and packaged it all fine.
So, the point is, if someone wants to mess around ONLY with Java part of the
code then Linux, NDK or armeabi tool-chain is not necessary as you can compile
it just as any other Android app with your Windows SDK -- only first you have
to place those two lib folders from existing mame4droid.apk and put it in your
projects "/libs" folder before compiling the project.
---
Ok, so hopefully soon I will have that vertical axis working along horizontal
one, and then I'll go see about the refresh and sound syncing. I also have a
fix for "720 degrees" game so the sprites do not flash and disappear, and I can
also build emulation of the game's specific controller where instead of
left-right you could make circles over virtual d-pad, effectively simulating
'720 degrees' quirky handle and thus making the game playable outside its
authentic cabinet for the first time since it got emulated. And this might also
translate well to X/Y sensor input, where instead of circling a finger you
could wobble the whole device, which could be very well suitable to illustrate
and simulate players twirling the air and perhaps fit the game even more than
its authentic controller, it could be fun!
I would also like to implement this: when you DISABLE VIRTUAL JOYSTICK and tap
on the screen, then option dialog pops up, but what I want instead is to map
this touch input as some action button. -- The thing is, virtual pad control is
the worst possible way to play these games, the fingers block the view and just
touching the screen slows down the app and eats even up to 10-20 frames of
animation, for whatever strange reason. Therefore for my mobile gaming I try to
get rid of virtual D-Pad for as many games as possible, by mapping input to
sensors or hardware buttons, absolutely avoiding touching the screen.
Anyway, I will try to do those changes on my own, but I suppose there could be
little things you could help me with that otherwise would take me a long time
to figure out, so if you are keen and have time, where can we talk about all
this some more, here?
Also, once I make my changes, what do you want me to do with it? Are you
looking forward to include outside code in your project, or perhaps you would
prefer if I branch off and publish it on my own?
Cheers,
Zeljko
Original comment by zelko...@gmail.com
on 25 Feb 2012 at 2:43
Realy good work...
I am finishing 0.134 mame port. It really mame as should be... Really nice
emulation, superb sound as well, but has some drawbacks like drivers poorly
optimized... You need a really powefull android device....
i said that becouse it will be 2 mame4droid builds... 0.37 build targeted to
low end devices and mame4droid reloaded suited for highend devices...
I would like to test your changes and if you makes then selectables it would be
nice to add to source tree...
Keep me tunned aboout your progress
Original comment by seleuco....@gmail.com
on 25 Feb 2012 at 7:40
Sheesh! I just spent last few hours playing Star Wars, wow! It turned out 1000
times better than I expected, it's almost like that game was made for it -
cockpit actually leans and wobbles around as you move cross-hair, fantastic!
Took me some time to get used to it, set up sensitivity and decide about
whether and what axis to invert, or not. It felt frustrating at first, but now
I think I'm almost good with it as with mouse on a PC, but this is so much more
fun. I'm so happy about it I'm gonna make a video and put it on YouTube, awww!
You have to try it, I'll post the code in a separate message after this. It's
just a bunch of copy/paste from the stuff that was already there. I wasn't even
bothering to figure out what code does, I just did for "PITCH" what you did for
"TILT", and as a result I could not hack it up quickly to make it work properly
with normal angles like 45 degrees. The best results I got when you hold the
phone in horizontal plane as the centring point, so that's how the code below
works. I will sort that out eventually and throw in auto re-calibration so
anyone can hold it the way they like, but right now I'm gonna play some more,
and try other games... like Gyruss & Time Pilot, hehee!
Which reminds me, I have to contact authors of SNES emulators, none of which
have support for X-axis as well, for some reason, as having played Star Wars
like this I am sure Star Fox would be amazing too, and so they simply ought to
do it. And also, can't wait to try how 720 Degrees will turn out, but for that
I need to setup NDK first and hack up game drivers.
--
I very much prefer 0.37, even on my own PC cabinets, probably because I don't
really care too much about too many games that are not already supported there,
and I like to make use of my old computers. I also enjoy making things
absolutely optimal, that's why I am interested in mobile software, so if I do
any work on this build after I finish with what I said before, then that would
most certainly be for the reason to make it faster and smaller, and then faster
again, so it can run on the poorest device possible. I'd even throw out support
for some games if that would make possible to speed up all the other games, or
significantly cut the size down.
Anyhow, thanks again for making this port! ...and I'm sure some richer kids
will just the same appreciate that new MAME port you're making and +1000 or
whatever more games, on their fancy new phones more powerful than my desktop
computer. ;-)
Original comment by zelko...@gmail.com
on 25 Feb 2012 at 10:53
[deleted comment]
Gyruss works wonderfully with sensor controls too, just great! Time Pilot is
also very playable and maybe even more intuitive to begin with, but Gyruss,
like Star Wars, just somehow feels right, like it was made for this, amazing.
These settings worked for me:
Star Wars: DeadZone=none, Sensitivity=7
Gyruss: DeadZone=low, Sensitivity=10
Time Pilot: DeadZone=none, Sensitivity=10
I think a little vibration should be there to inform player when phone is
tilted over the axis limit, so to help keep the display as steady as possible
if that would help the player to avoid making unnecessarily big movements.
I've seen around internet forums people are not excited very much about
emulators on phones, mainly due to same reason, which is awkward input via
virtual joystick, so much beyond my expectations this kind of thing actually
seems to be what can change that, at least for a few selected games, but if
those few more games fit so well to this control scheme like Star Wars and
Gyruss do, then it would still be all worth while as there is nothing I'd
rather play right now, so cool!
Original comment by zelko...@gmail.com
on 26 Feb 2012 at 2:03
sound cool... i only add tilt sensor as left-right becouse i thought that it
was a toy more than a useful thing.
i like use mame4droid with a external controller like wiimote and hooked to tv.
Touch controls works better with tablet devices also...
one thing to implement that i think it will be a good adition is a railgain
using touches... :)
i am interested in your display and sound sync improvements... could you give
me more info...
Original comment by seleuco....@gmail.com
on 26 Feb 2012 at 8:31
some more thing... tilt sensor it is only using accelerometer.... you should
think on add gyroscope as well....
it is not easy since you should add some kind of initial positioning using
magneto or accelerometer sensor and you should do a complementary filter to
remove noise... but i think it will be like day and night on precission.
Original comment by seleuco....@gmail.com
on 26 Feb 2012 at 8:36
[deleted comment]
Gyros are in all new medium-high end devices... i think it would be nice to add
it...
what device are you testing on?
take a look:
http://stackoverflow.com/questions/5314217/gyro-accelerometer-magnetometer-and-k
alman-filter
It sound cool your sync algoritm... i hope to test it and test on my own
devices. My tegra 2 test platform runs on perfect sync, no tearing or
glitches.... internal double buffer? i don't use fbo opengl...
anyaway my galaxy nexus and galaxy tab 10.1 It has a lot of power.. so maybe i
would look for a low end device....
Original comment by seleuco....@gmail.com
on 27 Feb 2012 at 2:26
[deleted comment]
[deleted comment]
I'm testing on 600MHz+GPU Samsung Galaxy 5 (240x320).
About 1/3 of the games run at full speed, games like Commando, Ghost'n Goblins,
Star Wars, run at about 50%-70%, so I set the 'frameskip' for these games to 6
frames, and MAME then locks the frame rate to HALF, so in effect doing what I
described above and then those games run almost perfectly smooth, much more so
than with 'auto-frameskip'.
For games like Street Fighter that barely move with 'auto-frameskip' I put
frameskip to 9, and the instead of 60FPS MAME locks it to 15FPS, and all of
sudden those games are actually playable and you would hardly notice that some
animation frames are missing because they then actually run at constant 100%
speed and so the animation itself stays UNIFORM, smooth and fluid.
You can try that. Even if all the games run at full speed on your system you
can still set the frame-skip to 6 or 9 (for 60fps games) just to see how there
is no much difference between 60 and 30 fps, and that 15fps is not so bad
either.
You know, no one really seem to know about this. It's kind of obvious, but
actually many published PC and console games, and world class physics engines
like Microsoft Havok, Nvidia PhysX and Bullet, ODE, Ogre... I've seen their
source code, they all make the same mistake, not to mention all their code
looks alike, as if they copied it one from another, together with bugs and
lousy algorithms, hahaa!
The thing is it's not that much obvious, especially on consoles where
developers know target system performance and can keep the load down so the
frame-rate does not drop under NTSC/PAL (60/50) fps (too often), but still, I
like things to be perfect, if possible.
Some of them surely do know, for example 'Shadow of the Colossus" runs at 30fps
on PS2, they don't even try for more, they knew fluid 30fps is much better than
choppy 60fps, and better than some attempt at telecine to hold fps around 40-50
fps when action on the screen gets hot, like so many other games unwisely do.
I'm talking about two similar but different things here. Cutting frame-rate in
half is ONLY about when the system is underpowered for the application. The
other thing is about syncing (emulated) game speed with display refresh rate.
--
Anyhow, it's only with certain games that you can test this perfection of
emulation, animation and pure fluidity of fluffy soft smoothness, but yes, with
majority of games it's almost impossible to notice anything.
1.) Moon Patrol -- Absolute No.1 test game for this. Its original speed is
57fps, so to get smooth scroll you have to do it properly otherwise it will be
pretty obvious. Look at holes on the ground or occasional letter, also pay
attention to audio.
2.) Bank Panic -- Also very good to test scroll smoothness, but here you can
hear sound glitches better.
3.) Pirate Ship Hygemaru -- Terrible audio crackling.
I tested this on more than 10 different computers with many versions of MAME
including several Andorid devices now with MAME4all, it's always the same, so
those glitches are there, it's not my computer that has a problem, but please
note that those imperfections may not seem very obvious, so you might need to
actually pay attention to spot there is something wrong. About 70% of the
people told me they can not see or hear any problems, and many others that did
notice the problems didn't care too much about it, but again, I like it to be
perfect, that's all.
Original comment by zelko...@gmail.com
on 27 Feb 2012 at 8:30
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
How the hell its possible that with frame skip 6 games are smoother ? haha, can
you guys make this somehow more official and use this method instead of bad
auto frameskip ?
I tried violent storm which is a bit choppy on auto frameskip but on skip 6 is
super amazing smooth! Its very weird and it looks like youre right, its a shame
that devs dont see that mistake in source code.
So this emu aims for 60fps on android ? Can you guys do something about it
cause looks like its working and its very worhty to look into:)
Hey maybe its the frameskip code that was changed in version 0.73 that gave
such slowdowns ? How about trying frameskip code from 1.5.2 in reloaded ?
I tried battletoads now in reloaded and on auto fps skip sound and smoothness
are so so, playable but when i set frameskip to 6 then i see improvement and
sound is much smoother + fps is great, smooth like on PC.So is it possible to
set fps to lets say 30 in MAME and then it wouldnt have to process 60 frames
but only 30 ? 30 is smooth enough for games.
Original comment by 2black...@gmail.com
on 28 Feb 2012 at 10:40
Frame-skip 6 in MAME locks 60fps games to 30fps, so if the game was struggling
with 60fps working around 90% - 110%, then with 30fps it would be working say
150%-170%, but the important thing is then it would not dip below 100%, which
is when the worst glitches happen. It works because 30fps is still pretty
acceptable for human eye, especially on a small screen, and that way frame rate
can stay stable and uniform. The bigger the screen the greater would be the
distance moving objects show up at each frame, so the difference between 15,
30, 60 and 120 fps is much more important the bigger your display is.
If the game is not scrolling one, you may very well try frame-skip 1, 2 or 3,
or whatever is enough, you just need to keep that game speed above 100%. That
is if you disable video-sync and set up your desired frame-skip the game will
try to go for the maximum speed, and that speed should not be dropping below
100%, but I'd rather cut the frame rate to 30fps to keep in sync with the
display and keep the speed at above 150%, more so than have 60fps at 110%,
since when you start pressing buttons and many sounds start playing then that
game would probably be dipping below 100%.
I'm afraid in case of MAME developers did it intentionally. That is they do not
want to change what was "original" game speed, usually something like 59,94fp
or 60.12fps. Which was fine while we all used CRT monitors as they could sync
to those frequencies, but LCDs can't and so as long as games do not run at
exactly 60fps or 30fps, and most of them do not, then there will be glitches.
But they'd rather have glitches than speed up or slow down game speed zero
point something percent which would not even be noticeable and is common
practice for any other video streaming media or multimedia, like console games
or dvd movies. Go figure.
Original comment by zelko...@gmail.com
on 29 Feb 2012 at 1:22
[deleted comment]
You should always try frame-skip 0 first. Maybe see if there is deference
between "normal" and "double buffer" syncing. To make it faster try dropping
video depth to 8bit and sound to 11KHz, only then if the games is not working
around 150% I would turn the frame-skip to 6. Also make note that on my phone
OpenGL rendering is much slower when it is supposed to be faster, so try
changing rendering mode too.
Original comment by zelko...@gmail.com
on 29 Feb 2012 at 1:40
You're right zelkoaks. i know some games runs better at constant fameskip that
with autoframeskip... that's why i always added as an option to the people who
want to spent some time with emulator options.
Normal people are ok with frame skipping.. that's a fact.
I develop an option in mame4droid 1.0 that i removed on later versions that try
to do 30fps frame locking... i failed... it don't works as i wanted... the
problem was when i wanted to use 2d hw acceleration ant it wasnt fluid.
I'll add your acceleromer improvments on furture versions... i want now to
start to develop the iOS mame4droid reloaded versión so i don't time to your
hi scores idea.... but i think it is very interesting
Original comment by seleuco....@gmail.com
on 29 Feb 2012 at 2:43
[deleted comment]
[deleted comment]
[deleted comment]
Compiling mame4droid was not simple.
Original comment by zelko...@gmail.com
on 5 Mar 2012 at 8:32
Original issue reported on code.google.com by
zelko...@gmail.com
on 24 Feb 2012 at 2:33