Related
Hey everyone,
is there any port of Winmugen out?
For those who dont know what Winmuge ist here is the homepage:
http://www.infinitymugenteam.com/infinity.wiki/mediawiki/index.php?title=M.U.G.E.N
Im really looking forward to play this on my Xperia, if there is already anything like this.
Perhaps you could emulate dos somehow, and then use that to play the game.
As i can see this is opensource, maybe a DEV could try to compile it.
I don't think it is open source though? I was actually thinking about trying to get it working on Android a while back, but I couldn't find the source... I think it's actually privately developed? If someone can provide a link to the source I'd love to look at it, though I still doubt I will have time.
According to Wikipedia (http://en.wikipedia.org/wiki/M.U.G.E.N), it is built upon the SDL library, which back then when I googled it looked like someone had ported the SDL library to Android, so I was hoping it would not be too hard (with the source) to get it running on top of the Android port of the SDL library.
But porting it over without the source is probably a more daunting task...
~Troop
i wrote with the developers of M.U.G.E.N and the source ist not open. And they wont make it public for any reasons, i still try to get it from them but i wont look so good.
Yes there is an port of SDL for Android.
When I was looking around though, I did stumble upon jmugen - a java port of MUGEN, which sounds promising... but looking at it, it looks like an abandoned project. I haven't found time yet to test how functional it is and if it could be a good starting point for an Android version.
Better than starting from scratch I suppose...
http://code.google.com/p/jmugen/
Just keep in mind it has to be developed under the GNU GPL... which I would be in favor of anyway...
~Troop
thx for that, i will take a look at it
for all that want to play Mugen on Android - here we go http://paintown.sourceforge.net/
Paintown includes Mugen game Mode, fully working. Androidversion in downloads.
NOTE: Im not the developer of this game, i just share this to you.
Press Thanks if i helped you.
Greetz Aco
Can we have nexus 7 2013 lte act as bluetooth headset and have phone book access profile please.....
www.bluez.org they have the whole source code to put this in to any rom, i do not know how to put but someone who knows i think should be straight forward
also there are roms from huifei who manufactures car stereos with bluetooth functionality in them and they are based on android ... http://forum.xda-developers.com/showthread.php?t=2660662
can we have this functionality please in nexus 7 ?
There is source code available for a product called carpod, and android car head unit which also has this bluetooth functionality... i downloaded the source code, and it has gradle files etc... i have no idea how and what to look in to the source code... any suggestions where to look? how to open the complete source code in android development studio etc?
the link for that source code is under Helpful Links section -->> http://forum.xda-developers.com/showpost.php?p=55200512&postcount=1
i really hope a developer can just add this functionality which is already implemented in many available car head units running on android...
Google released some weeks ago Android Auto.
http://www.android.com/auto/
An app on your Lollipop device that can connect to cars head units.
So using your phone with the biger display in your car, with apps specially designed for that.
The problem is that you need a new car or a after market head unit that supports Android Auto.
That sounds really expensive!!
BUT what if we could replace that expensive head unit with a raspberry pi?!
Have no idea yet if that would work, that's why I started this topic, for brain storming about this. [emoji1]
Would be nice to have a multimedia central with Waze running... Hope it gets popular fast
that would be awesome and i am totally into that.
as far as i know, some guy made an lolipop port for the pi2. maybe we can use that as a base.
jackcaos said:
that would be awesome and i am totally into that.
as far as i know, some guy made an lolipop port for the pi2. maybe we can use that as a base.
Click to expand...
Click to collapse
Try my Headunit app of course; see sig...
But it requires Android 4.1+, a decently fast H.264 decoder, at least at 800x480 resolution, and USB Host Mode support, or in future WiFi Direct.
mikereidis said:
Try my Headunit app of course; see sig...
But it requires Android 4.1+, a decently fast H.264 decoder, at least at 800x480 resolution, and USB Host Mode support, or in future WiFi Direct.
Click to expand...
Click to collapse
Hi Mike, my apologies for cold outreach. Interested in your technology, please PM me so we can talk.
Thank you
thundpa said:
Hi Mike, my apologies for cold outreach. Interested in your technology, please PM me so we can talk.
Thank you
Click to expand...
Click to collapse
Anyone can email me anytime at [email protected] .
Is this already built? Or are you just suggesting an idea? I'd love to have it in my car. Do post here if when it is ready. (I mean the PI version)
mathewparet said:
Is this already built? Or are you just suggesting an idea? I'd love to have it in my car. Do post here if when it is ready. (I mean the PI version)
Click to expand...
Click to collapse
Quote from OP:
Have no idea yet if that would work, that's why I started this topic, for brain storming about this.
Click to expand...
Click to collapse
I will be/have released my Headunit app as open source, so someone with the skills could do this.
But I likely won't be doing it myself.
If there is someone with skills to compile your head unit app would be great.
Where can we find the code for your app?
Sent from my Nexus 7 using Tapatalk
luci84tm said:
If there is someone with skills to compile your head unit app would be great.
Where can we find the code for your app?
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
https://github.com/mikereidis/headunit
I might re-consider and do it myself, but my time is limited. I could also just to try help someone to port it.
I would rather have it working well on Android alone than having it half working on multiple platforms.
Hi,
I started to work on it. but I started from scratch for 2 reasons :
1/ I want to understand how the protocol works, it's important because there is no documentation available.
2/ The dev approach is very different : it's mainly based on libusb only and I try to implement the AA protocol without dependency with the underlying transport.
I plan to open code but now it's just too early. Sharing knowledge is a good start.
The Android headunit source code is very helpful to understand the protocol. Thanks for sharing the code.
So far what is done :
-100% asynchronous processing of usb transport so the thing is fully event based. It seems that the code becomes less messy this way and asynchronous programming model fits well with libusb.
-switch to accessory mode works
-ssl handshake is ok so the init phase of the protocol is working
Now I just got my first encrypted message from the phone. Encryption is not a big deal. I think I will be able to capture the first h264 buffers end of this week.
I imagine RaspberryAuto (codename for now) could run on a very lightweight JEOS style Linux with readonly flash filesystem. I will take look at the Openelec project which leverages this kind of system. I never developed UI for RPI, that's the main pain for me.
As it is a 100% C program it won't need a lot of RAM so the cheapest Raspberry model could be enough. H264 is not a problem as RPI supports hardware decoding. I'm a little bit more worried about the cost of the SSL processing (I don't know if the PI processor is good enough for that.
So why a PI ? Simply because it's open and documented, it's fast for h264 decoding, it supports composite output so it can be connected to the factory head unit of a car. Another interesting point is the my code is working on Ubuntu Intel too so there will be probably more choices for the target device at the end of the story. But PI is just enough for this project.
marcjero said:
Hi,
I started to work on it. but I started from scratch for 2 reasons :
1/ I want to understand how the protocol works, it's important because there is no documentation available.
2/ The dev approach is very different : it's mainly based on libusb only and I try to implement the AA protocol without dependency with the underlying transport.
I plan to open code but now it's just too early. Sharing knowledge is a good start.
The Android headunit source code is very helpful to understand the protocol. Thanks for sharing the code.
So far what is done :
-100% asynchronous processing of usb transport so the thing is fully event based. It seems that the code becomes less messy this way and asynchronous programming model fits well with libusb.
-switch to accessory mode works
-ssl handshake is ok so the init phase of the protocol is working
Now I just got my first encrypted message from the phone. Encryption is not a big deal. I think I will be able to capture the first h264 buffers end of this week.
I imagine RaspberryAuto (codename for now) could run on a very lightweight JEOS style Linux with readonly flash filesystem. I will take look at the Openelec project which leverages this kind of system. I never developed UI for RPI, that's the main pain for me.
As it is a 100% C program it won't need a lot of RAM so the cheapest Raspberry model could be enough. H264 is not a problem as RPI supports hardware decoding. I'm a little bit more worried about the cost of the SSL processing (I don't know if the PI processor is good enough for that.
So why a PI ? Simply because it's open and documented, it's fast for h264 decoding, it supports composite output so it can be connected to the factory head unit of a car. Another interesting point is the my code is working on Ubuntu Intel too so there will be probably more choices for the target device at the end of the story. But PI is just enough for this project.
Click to expand...
Click to collapse
Great work, keep us updated I've just ordered a car with android auto but it would be great to have something affordable for my wife's car.
Juicie said:
Great work, keep us updated I've just ordered a car with android auto but it would be great to have something affordable for my wife's car.
Click to expand...
Click to collapse
Hello Juicie,
Yes my new car will come with AA support as well so I have lost some motivation to complete this work these last few days. I can share my code with anyone that would like to continue.
I will do my best to release an alpha version that will work on Ubuntu but there will be more work to do to use the h264 hardware decoding of PI.
wow! that sounds great!
This could get really interesting now that RPi Foundation have announced a touchscreen....
Hi,
I have good news. I have a prototype fully working on Ubuntu (screenshots attached). The rendering is very good and smooth. Nav is fully working.
Now we just need to port the code on the PI itself. I only used libraries available on the PI so it should be straightforward except for the rendering. For rendering I use gstreamer because gstreamer is portable and supports omx (hardware accelerated h264 rendering on the PI). I think I just need to set the PI omx decoder and sink into the gstreamer code to make it work. The tricky part could be to capture the touch events if the sink doesn't provide them itself.
Problem is I don't have a spare PI to complete the job.
hi,
That's really great news didn't expect such good progress!!
I do have a rpi and can test if you give me the app.
The problem at the moment is that I don't have an android device running lollipop..but I can try to find one
Sent from my GT-I9300 using Tapatalk
I'm going to follow this !
If you need someone to test feel free to ask !
Hi
I will try to build an image pour the PI asap then.But I will have to disable the touch events at beginning because the purpose is to port the code and use the omx decoder engine.. That's a first step.
marcjero said:
Hi
I will try to build an image pour the PI asap then.But I will have to disable the touch events at beginning because the purpose is to port the code and use the omx decoder engine.. That's a first step.
Click to expand...
Click to collapse
Where are you currently hosting your code?
Dear XDA members,
if you feel the same as the friends at https://postmarketos.org/ :
"We are sick of not receiving updates shortly after buying new phones. Sick of the walled gardens deeply integrated into Android
and iOS. That's why we are developing a sustainable, privacy and security focused free software mobile OS that is modeled after
traditional Linux distributions. With privilege separation in mind. Let's keep our devices useful and safe until they physically break!",
then it is time for you to step forward!!!
Last night initial support for the OPPO Find 7a was commited to the postmarketos pmaports git repo
https://gitlab.com/postmarketOS/pmaports with commit https://gitlab.com/postmarketOS/pmaports/commit/1f8095771c4659d31e8b228dd85018e9ca9963ca.
It was a pain to get this committed as I'm not used to the git workflow, nonetheless with the help of the maintainers over there
and after deleting a few merge requests ( a no-no, don't do that!!) at the end we got it done.
At the moment the device port is only for the Find 7a for the simple reason that I own one but I'm sure it can be extended to the
Find 7 and Find 7s.
The answer to the question that you dear reader have in your mind now: "what works?" is easy: NOTHING WORKS YET!!!
The only thing working so far is that the kernel compiles, you can flash it or fastboot boot it, start a rootfs on the microsd card
and ssh into the system over a usbnet connection to look at all that lovely processes running.
Lots of work still needs to be done, I'm pretty shure that I will not be able to do this myself as my knowledge about the hardware
part of the device is minimal and I would need to reinvent the wheel for every little progress.
As I'm sure that there are still a lot of knowleadgeable develepers (THAT'S YOU!!!) lurking around this list my hope is to lure them
to contribute to this project.
I personally dream of the Find 7 running postmarketos and KDE plasma-mobile but even maemo would be ok!!!
Come on, let's do it!!!
Best regards,
farmatito
Links to get more info:
https://postmarketos.org/
https://wiki.postmarketos.org/wiki/OPPO_FIND_7a_(oppo-find-7a)
https://wiki.postmarketos.org/wiki/Porting_to_a_new_device
Screen and touchscreen working!!!
Still a lot of work to do. Help is appreciated!
Progress report
New package for installing various firmware blobs merged!
Next big thing should be to try to make video hardware acceleration work,
if there are any experts here help is appreciated!!!!.
Progress report
The attached photo shows my Find7a running the XFCE4 desktop.
The interface is fast enough even without hardware acceleration.
As the Desktop is not optimized for mobile devices it is not
a such a great user experience, but the basics work.
Still a lot of work to do, help is appreciated.
Progress report
Wifi Works!!! and you can browse the internet!!!
Help is still appreciated!!
No progress
This time there is no progress to report:
video acceleration not working yet due to the fact that the kernel is rather old (3.4.113), backporting newer drivers did not work out as the codebase differs to much (so no KDE plasma).
making the various sensors work is also rather difficult as the kernel uses a Device Tree and so even if there are drivers for the sensors you need some board specific info to create the device tree nodes.
last but not least the last version of xfce4 in alpine linux is not touchscreen friendly. GTK combo-boxes are now unusable (will eventually try maemo).
Help is very, very appreciated.
Saw this post, has a Find 7 and want to know more.
I'm currently owning a MTCE device. I'm a software developer (.NET). I'm a design and UX fetishist.
I see many folks of you have posted different apps, skins, mods, a.s.o. to get the best out of the headunit that is possible.
One problem I have seen is, that if I want to have a full working headunit, I will have to read thousand of forum-posts, try hundreds of software and then get stuck by a few apps that design is not fitting together.
Why isn't it possible, to join the forces to make a fully working ROM with preinstalled software that looks as if it was designed and made by the manufacturer? One design (maybe skinnable), one UX, selectable apps. So a newbie (like me) will get a fully functional headunit (including the basics like radio, DAB, mediaplayer, navigation, ...) that looks like factory-made with installing only the ROM.
Modern cars already have a well working headunit that has a seamless UI and UX between the different functions. Why shouldn't this be possible on our headunits?
I would suggest, that all of you developers, skinners, modders, should join your forces and create an experience for our headunits that will outreach the currently built-in headunits of modern cars.
What's wrong with hal9k or malaysk mod? They are fully working and in my opinion are better than original head unit from my car. You can even use google assistant, so you can control everything by your voice.
Maybe my mods will suit your needs?
Have a look at my channel:
https://www.youtube.com/user/KoTiX71
RolandE1204 said:
I'm currently owning a MTCE device. I'm a software developer (.NET). I'm a design and UX fetishist.
I see many folks of you have posted different apps, skins, mods, a.s.o. to get the best out of the headunit that is possible.
One problem I have seen is, that if I want to have a full working headunit, I will have to read thousand of forum-posts, try hundreds of software and then get stuck by a few apps that design is not fitting together.
Why isn't it possible, to join the forces to make a fully working ROM with preinstalled software that looks as if it was designed and made by the manufacturer? One design (maybe skinnable), one UX, selectable apps. So a newbie (like me) will get a fully functional headunit (including the basics like radio, DAB, mediaplayer, navigation, ...) that looks like factory-made with installing only the ROM.
Modern cars already have a well working headunit that has a seamless UI and UX between the different functions. Why shouldn't this be possible on our headunits?
I would suggest, that all of you developers, skinners, modders, should join your forces and create an experience for our headunits that will outreach the currently built-in headunits of modern cars.
Click to expand...
Click to collapse
I exactly know what you are talking about.
Whether malaysk nor Hal9k are the greatest thing since sliced bread and do not fulfill what I and you @RolandE1204 are expecting.
A common UI with same buttons and same background, coordinated in function and visibility would be awsome.
...but..... and now we have the main issue:
All firmware are made of apps from different developers and are just bundled in the firmware. This leads automatically to different UI for each single app.
You won´t get a navigation app which fits any other UI. You won´t get a player app fitting the UI of your launcher. If you would want this, each single app needs to get developed or at least adapted to a UI.... None will do that and as far as I know there is no possibility to create a common UI which adapts 3rd party applications. Each app has it´s own one.
This is one of the benefits of an OEM unit. There you have to pay a lot more and it is not configurable at all, because it is completely closed.... but with a common interface...
That's right ... but does it have to be like that?
@rigattoni You're absolutely correct. But does it have to be this way? Here at xda-developers are all the guys (and girls) that do the best work like malaysk, hal and many others that do very great work.
With a little more work together, there could be a complete solution that would not also work but also look great.
I may think too simple but there has to be a design and UX guideline, that has to be created and every application that will be developed using this guideline, will fit nearly seamless into the bundle of all other apps.
Also I'm sure that there are also som people like me, owning a slightly older car that hasn't built in a headunit with such functions. I like my car (Peugeot 308CC) and would buy it again but I wanted to add functionality that hasn't been in (rear drive camera, good working navigation, ...).
Just to clarify: I'm not searching for a free solution and I understand that this means a lot of work that can mainly be done by enthusiasts, but I'm also willing to pay for a solution that works and looks like a charm. So I think that even if we are talking about different applications that work together seamless, I am sure that there are people like me, who are willing to pay money for this.
I'm currently living with a mediaplayer (poweramp [blue]) that has a different behaviour and look like the radio (stock [black/white]) and a navigation app (magic earth [orange]) that also doesn't fit in. Other applications (TPMS, Bluetooth-Calling, Car-Status) are also looking very different.
I know that there are persons doing great work in modifying roms and apps but they all have their different design-language. So why not using a centralized design and UX language and creating a bundle of software that makes every owner of an android headunit as proud as he can be?
Do we get these devs together to work on one version with a common UI?
I would love everything to look similar, but I would settle for great looking apps that look different. Like that guy who posted the youtube link - nice radio app, but would look for a different music app
kmlnvm said:
What's wrong with hal9k or malaysk mod? They are fully working and in my opinion are better than original head unit from my car. You can even use google assistant, so you can control everything by your voice.
Click to expand...
Click to collapse
Yes, confused, malysk and hal9k are already this way. Perhaps OP wants to define look and feel.
Perhaps too, OP might not understand that source code to the MTCD units has not been released and that to a large extent work is by reverse engineering?
---------- Post added at 09:27 AM ---------- Previous post was at 09:26 AM ----------
rigattoni said:
Do we get these devs together to work on one version with a common UI?
Click to expand...
Click to collapse
Sure, how would you do that?
@marchnz: It was just a question. Nothing else to be interpreted into this question...
I'm aware
@marchnz: I'm aware that reverse engineering is hard work. I've already done this by myself (as I said, I'm a .NET developer).
I'm not into developing android software but I'm sure it is a lot of work too.
As long as I do have the commitment of some developers that they want to follow design guidelines, I'm able to create some. What I don't want to do is, to create guidelines that nobody is considering. Also I do not want to patronize someone. So if someone commits that he wants to use guidelines and has a definitive app in mind he wants to work on, we can work out guidelines.
Maybe first of all invite some developers:
@jamal2367
@Malaysk
@Hal9k_
@mike.b
@f1x
im sorry I didnt get your meaning
whats the plan?
i'm a developer I mean what are we going to do?
can you explain more clear?
What has to be done is to unify the UI and UX of all the major apps that are needed.
The best would even be to make them skinnable.
So there is a need to create a common UI for
- Radio
- Media-Player
- Bluetooth (Calling)
- Vehicle (Doors, Trunk, ...)
What I already can say is, that there will be a skinnable version of magic earth (navigation) in the near future.
Also it would be nice if during this process, some smaller issues of a software can be fixed. (ie. Radio looses the station-names on reboot and only shows frequencies)
Anyone who will contribute on this project, please leave a message or send me a PM.
RolandE1204 said:
What has to be done is to unify the UI and UX of all the major apps that are needed.
The best would even be to make them skinnable.
So there is a need to create a common UI for
- Radio
- Media-Player
- Bluetooth (Calling)
- Vehicle (Doors, Trunk, ...)
What I already can say is, that there will be a skinnable version of magic earth (navigation) in the near future.
Also it would be nice if during this process, some smaller issues of a software can be fixed. (ie. Radio looses the station-names on reboot and only shows frequencies)
Anyone who will contribute on this project, please leave a message or send me a PM.
Click to expand...
Click to collapse
Hey
If you are interested in a radio player that runs over the internet then have a look here!
GitHub: https://github.com/jamal2362/URL-Radio
Download: https://jamal2367.org/downloads/?dir=Apps/URL Radio
You could install it on your mobile phone and use the app in landscape format and see what it looks like on the MTCE.
jamal2367 said:
Hey
If you are interested in a radio player that runs over the internet then have a look here!
GitHub: https://github.com/jamal2362/URL-Radio
Download: https://jamal2367.org/downloads/?dir=Apps/URL Radio
You could install it on your mobile phone and use the app in landscape format and see what it looks like on the MTCE.
Click to expand...
Click to collapse
I've never written about a radio that works over the internet.