Is there a website or downloadable document that contains information about the 3D capabilities (Fillrate, Features, Shader Units etc) of the 3D Hardware used in many of today's smartphones such as IPhone 3G, IPhone 4, the more popular Android Devices, Windows Phone 7 etc?
If a resource like this existed that sure would have saved me a lot of time! Back when I first started my current job, my first task was to make a spreadsheet of information about the 3D capabilities of all the smartphones out there. It was waaaay harder than I expected, because the various device manufacturers are surprisingly cagey about specific info other than what's in their marketing brochures. I didn't even get every device out there (just a solid sampling of the best known ones) nor did I investigate them to quite the depth you're asking for.
In general however I found a few common patterns and most useful resources that, taken together, told me most of what I needed to know.
First off, pretty much all the smartphones out there use either a PowerVR chip or a Qualcomm chip (formerly/alternatively known as "Adreno"; it's a long story, read the Wikipedia article) for the GPU. For example, all iPhones use a PowerVR GPU (different generations though) and Microsoft has mandated that all WinPhone 7 devices use the exact same Snapdragon chipset from Qualcomm. Motorola Droids use PowerVR, HTC Android phones use Qualcomm, etc.
Second, I relied heavily on the sites GLBenchmark, PDAdb.net, and good ole Wikipedia. For example, going to the "Results" tab on GLBenchmark brings up a list of all the smartphones they've tested, then go the the iPhone 3Gs results, and then go to the "GL Environment" tab:
http://www.glbenchmark.com/phonedetails.jsp?benchmark=glpro20&D=Apple+iPhone+3G+S&testgroup=gl
Oh hey look, it has a PowerVR SGX 535
Related
I've been investigating a way of tracking a device's location in a building, at first I was intending to use iBeacons. However I have been since told that it must be done by monitoring access points and looking for the MAC address of that device.
I can't seem to find any generic sort of library or API that can hook into an access point and give me details. Infact I don't even know where to start looking which is making it even harder.
Has anybody had dealings with this and could point me in the right direction? Any programming language acceptable.
I have written software from scratch to do exactly this, but to my knowledge, no frameworks are available.
The basic steps are:
Get a number of small, low-cost computers (Raspberry Pis work nicely) to act as sensors that do WiFi scanning in promiscuous mode, collecting unique macs and detection times. On Linux, you can use C or Java software to collect these records.
Write the info from the sensors to a server, including the sensor identifier so you know where each device was detected.
Write lots of code to crunch the numbers.
You should be aware of three big issues:
Mobile devices aren't always detectable on WiFi. If they are asleep, or simply not communicating, you will not detect them. On iOS the best you can hope for is detections every minute or so if the device is not locked and not actively using WiFi.
On iOS 8+, mac addresses are scrambled under certain conditions,boften making it impossible to track unique devices.
Building the above from scratch is a lot of work. Think several man months for even a basic system.
I know you were asked to build it this way and not with beacons, but beacons do provide a much simpler path forward if you can ensure an app on each device and can revisit this design constraint.
I suggest you to do this with iBeacons.
But :
On IOS 8 , when u try in anyway to get mac adress from a device , you obtain this value : 02:00:00:00:00:00.
The best way to get an unique identifier for a device is to use the identifierForVendor method form UIDevice.
Like this :
UIDevice *device = [[UIDevice alloc]init];
NSString *uniqueIdForDevice= [NSString stringWithFormat:#"%#", [device identifierForVendor]];
NSLog(#"%#",uniqueIdForDevice);
That gives you an ID that's unique for that device for your company.
I hope this can help you.
I'm not sure what the constraints are on your particular design but there are existing systems that allow you to get the kind of monitoring I think you're looking for. As davidgyoung writes, there are a few technical challenges that exist at OS level that will be present in whatever wi-fi solution to choose (e.g. iOS MAC address rotation). That aside, you might get some value from looking at solutions from Wi-fi hardware manufacturers like Cisco: https://meraki.cisco.com/solutions/cmx . They have a pre-built platform for visitor data (i.e. showing you where phones are in buildings/spaces). I think all the major wi-fi hardware manufacturers have something similar now and Cisco are likely to be top-end. From memory, Aruba were much cheaper (I'm going back ~10 months).
There are also software providers like Euclid Analytics ( http://euclidanalytics.com ) who build on top of the hardware and API's of providers like Cisco to provide visitor info like I think you want.
This isn't an exhaustive list as I'm writing this from memory but hopefully a bit of Googling based on the above should give you a better chance of success than rolling your own.
Good luck,
James
If you want to do indoor location services, then I would recommend checking out Cisco Connected Mobile Experience software.
You can try it free.
Based on my analysis, it is the best solution out there. I am biased because I work there. But, I do competitive analysis and have yet to find anything I think works better.
I am looking for a modern system to do some bare bones Assembly programming (for fun/learning) that does not have the legacy burden of x86 platforms (where you still have to deal with BIOS, switching to protected mode, VESA horrors to be able to output pixels to the screen in modern resolutions/colordepths etc.). Do such systems even exist? I suspect it is not even possible today to do low-level graphics programming without dealing with proprietary hardware.
qemu is likely what you want if you dont want to have to build that stuff in. You wont get as much visibility as to what is going on in the guts of it.
For hardware, beagleboard (dont get the old one get the new one with reasonable connectors, etc), or the open-rd board. I was disappointed with the plug computer thing. The hawkboard I like better than the beagleboard, but am concerned about the big banner about a pcb design problem. The raspberry pi will be out at some point and will also provide what you are looking for. Note that for beagleboard, etc, you dont have to run linux or anything like that, you can write your own binary and xmodem it over or use the network and then just run it, not a problem at all.
The stellaris eval boards all/most have oled displays, monochrome and small but graphics, not sure how much you were after.
earth-lcd used to have an arm based board with a decent sized panel on it.
there is of course the gameboy advance and the nintendo ds. flash/developer cartridges are under $20. the gba is better to start with IMO, as the nds is like two gbas competing for shared resources and a little confusing. with a ez flash cartridge (open source software to program), was easy to put a bootloader on the gba and for like another $20 create a serial cable, I have a serial based bootloader for loading the programs. If you have an interest in this path start with the visual boy advance emulator to get your feet wet and see how you feel about the platform.
If you go to sparkfun.com there are likely a number of boards that either already have lcd connectors that you would mate up with a display or definitely displays and breakout boards that you could connect to a number of microcontroller development boards. Other than the insanely painful blue leds, and the implication that there is 64KB (there is but non-linear 32KB+16+16) the mbed board is nice, up to 100mhz, cortex-m3. I have some mbed samples at github as well that walk you through building an arm binary too boot an arm from flash for those that have not done it (and want to learn that rather than call some apis in a sandbox).
the armmite pro and the maple (sparkfun) are arm based arduino footprint platforms, so for example you can get the color lcd shield or the gameduino
There is the open pandora project. I was quite dissappointed with the experience, after over a year paid another fee to get the unit and it failed within a few minutes. Sent it back and I need to check my credit card statement, maybe we took the return and give it to someone who wants it path. I have used the gamepark gp32 and gpx2, but not the wiz, the gpx2 was fine other than some memory I/O problem in the chip that caused chaotic timing. the thing would run just fine but memory performance was all over the map and non-deterministic. the gp32 is not what you are looking for but the gpx2 might be, finding connectors for a serial cable might be more difficult now that the cell phone cable folks used to cut up is not as readily available.
gen 1 ipod nanos can still be had easily, as well as the older gen ipod classics. easy to homebrew, the lcd panels are easy to get at. grayscale only, maybe only black and white I dont remember. All the programming info is had from the ipodlinux folks.
I have not tried it yet but the barns and noble folks are homebrew friendly or as friendly as anyone on that scale has been so far. the nook color can easily be turned into a generic android device, so I assume that also means you could develop homebrew on the metal, not sure though, have not studied it.
You might look at always innovating, my experience with them was similar to the open pandora folks. These folks started with a modified beagleboard in a box with a display and batteries, then added a couple more products, any one of them should be very open, and homebrew friendly so you can write whatever level you want, boot and run on the metal, no problem. For the original product it was one of those wait for several months things.
I am hoping the raspberry pi becomes the next beagleboard but better.
BTW all hardware is proprietary, it is just a matter of whether they choose to provide programming information or not. vesa came about because no two vendors did it the same way, and that has not changed, you have to still read the dataseets and programmers reference manuals. But as you can see above I have only scratched the surface, and covered the sub or close to $100 items. If you are willing to pay in the thousands of dollars that greatly opens the door to graphics based development platforms that are well documented and relatively sandbox free. many are arm based since arm is the choice for phones, etc and these are phone-like, tablet-like, eval platforms.
The Android emulator is such a beast; it runs a linux kernel and driver stack (including /dev/fb) that one can log into via the android debugger bridge, and run (statically linked) arm-linux-eabi applications. Framebuffer access is possible; see example.
The meta-question rather is, what do you mean by "low-level" graphics programming; no emulator is going to expose all the register and chip state complexity that's behind a modern graphics chip pipeline. But simple framebuffer contents manipulation (pixel buffer access) is surely simple enough, as is experimenting with software rendering in ARM assembly.
Of course, things that you can do with the Android emulator you can also do with cheap physical ARM hardware, like the beagleboard and similar. Real complexity only begins when you want to access "advanced" things - that's anything accelerated functionality beyond just reading/writing framebuffer contents.
New Answer
I recently came across this while looking for emulators to run NetBSD on, but there's a project called GXemul that provides a full-system computer architecture emulation with support for a variety of virtual devices and CPUs. The primary and most up-to-date core looks to be MIPS-based, but it also lists support for emulating the ARM architecture. It even includes an integrated debugger and it sounds like you can just assemble your code into a raw binary with some bootstrapping code and boot it as a kernel inside the emulator from the commandline.
Previous Answer
This isn't an emulator, but if you're interested in having a complete, ARM-based computer that you can develop whatever you want on that doesn't cost much, you should keep an eye on the Raspberry Pi project. They're very close to selling a complete, tiny, low-power ARM-based computer for $25 a piece. It has USB ports, ethernet, video out, and an SD card reader, and can boot Linux, although in your case you'd probably want to boot your own code and access the hardware directly.
EDIT: Looks like Erik already mentioned it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I and my Friends have been trying to custom build a mid-range mobile phone. We are thinking of porting linux to it and modify it as per our requirements.
Now, The problem is that we are unable to decide about which processor to use - weather to use ARM or any other and if ARM then which ARM architecture. It would be great if someone could also suggest which linux variant to port.
OUR AIM: We want to build a device in this category, please please follow the link:
Please Click here
Please give your valuable inputs, it will help a great deal to us youngsters.
Thanks and Regards,
Avi and Co
Are you seriously getting into the phone business or is there some other real goal you are after (learning how something works, wanting to create a phone user interface, etc)? Getting into the phone business means tens to hundreds of millions of dollars, per product, of development money. Armies of lawyers to figure out the dozens of companies you are going to have to pay patent royalties to (do you follow slashdot.org?), etc. With that budget you already have the money to buy each of the popular eval boards and try them out. Likewise the software staff to try each of the linux porting methods.
Not to completely discourage you though.
ARM makes processor cores, but not chips. Other companies take an ARM core, wrap it with something interesting and sell that chip as a product. There are many websites that show the deconstruction/disassembly of quite a few phones and other products. You need to research this, I would be surprised, but if there are phones that use commercially available processors, those are the chips you should look for. I suspect most are going to be custom made for that phone or phone vendor and you are likely not going to be able to even get a datasheet much less a way to buy them on a board (other than buying a phone of course).
ARM is a very good choice for phones, there are many good reasons why ARM is used in phones and most other handheld devices. Go to ARM's website and look at the cores availble. Compare that to what websites claim phones or other similar devices (ipad, kindle, nook) are using. Then search around for companies that have chips with those cores. You will probably just end up looking at the ti omap or the marvell chip in the openrd or plug computer (I dont know its name/model off hand, kirkwood or something like that). The nvidia tegra is the hot new chip for phones, I think they have an eval board.
If you have not already ported linux to ARM then I would actually suggest working on that against QEMU, and wait on purchasing any hardware. As already mentioned a little googling goes a long way. You can even create and test your phone user interface software without needing to purchase any hardware. By surfing around getting a feel for what lcd panels, etc are used by various vendors you can get a feel for what your software is going to be limited to or have to do. It wont cost you anything but time to figure out what you do and dont want or will or wont support without having to spend any money on hardware.
I would compile everything for a generic arm at first (armv4 for example) and worry about tuning for the particular core later, if at all. Sure, ultimately you are going to need to get a feel for the performance of that core and caches and mmu, etc. worry about that later you have a lot of research to do and software ground work first. If you must get a beagleboard or openrd (with all the extras you have to buy to make a beagleboard usable/useful, the openrd is cheaper, faster, etc). (avoid the plug computer, doesnt fit with what you are trying to do anyway).
There are many good reasons why linux is not used on phones, so you need to research that as well and decide if that is the path you really want to take.
You are likely going to end up with an mpcore or cortex-Asomething. So the ti opap, nvidia tegra, marvell sheeva, etc, all fall into that category. You can get the feel for a cortex A series from any one of them.
After reading this post and some derivative publications (ddotdash.com) I wonder whether it is possible to use a handheld as a main platform for development of web applications for mobile web browsers.
For web development I use a rather common set of tools: Cheap netbook, Ubuntu 9.10, Ruby on Rails, VIM, GIT. I think it is possible to use all of those on Nokia n900 due to the fact that it has Maemo OS on it which is based on Debian (all debs are possible to install and you can always compile problematic debs from source).
Nevertheless, I am concerned with 3 problems:
Display size. I have 1280x800 resolution on my netbook and it is convenient for me to have Terminator (multiple consoles), VIM, file browser, Firefox and some PDF books opened at the same time. I wonder if it would be possible to use all these apps on 800px horizontal resolution.
Computing power: Via Nano (or Atom) processor does not distinct dramatically from that on Nokia n900 (at least in MHz), however I wonder if 256+768(virtual) memory on Nokia will be enough for my work (I have 3 GB now on the netbook).
Keyboard. Frankly it is not a problem due to the fact that I have Nokia su-8w bluetooth keyboard that is comfortable enough for touch typing. However it is interesting to read some comments on this problem. [Edit]: Bluetooth keyboard is not so comfortable - a developer has to dispose a handheld on the keyboard and it is not easy to look at the small screen from such rather big distance (keyboard can be placed on a table or on the knees only).
Having solutions for the problems mentioned above, I will have an opportunity to exploit all the wonderful advantages of the mobile development platforms, such as:
work from anywhere (it is important for me);
develop for the same form-factor that is used by the developer and intended users both;
pocket-size working tool :)
It may well be possible - the question is how much energy you'll expend compensating for all the restrictions. It's like developing in Notepad: possible, but not a pleasant experience.
I develop a bit on my netbook too, and it's okay - but I wouldn't want to do it all day.
It's certainly quite cool to be able to develop on a handheld device, but I don't think it's really practical for significant amounts of code. If this is for your own personal pleasure and you think the benefits outweigh the costs, that's one thing - but I wouldn't do it for commercial apps.
I would like to ask a few questions regarding mobile game porting...
Let say if I have a simple 2D C++ game engine and have a PC game based on that engine and I want to port it to different mobile platforms BREW, J2ME, iPhone, Android, Symbian, etc..
Do I need to re-code the engine and the game for each platform? or is there an easier and more efficient way? I am sure the process is complicated since different phones have different graphic/processor/memory/etc. I am just curious about the overview of mobile game porting process. :)
Thanks!
There are several ways of attacking mobile game porting. First of all, until very recently it was mostly BREW and J2ME. The iPhone, Android and BlackBerry are changing this landscape and making the impossible task of mobile game porting even more impossible. I worked in 3rd party mobile game development for many years until recently. I watched BREW vanish and saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There are estimates to its cost, both time and money, and it seems to bell curve around 50-60% of the total development cost for each game is just porting.
At our company, we handled porting by having two engines that paralleled each other, one in BREW, one in J2ME. We never supported Symbian as Symbian development does not make any money. It is mainly for high-end tech demos that might be on one or two devices, nothing that could reach the mass market. Plus, most Symbian phones supported J2ME.
We would be required by publishers to provide any where from 7-23 reference builds of the game, targeting many different devices, in both BREW and J2ME. Just before moving on, publishers were also starting to require a J2ME touch screen reference version, and an iPhone SKU was being left as "to be determined" based on the final product and how cost effective an iPhone version would be at that time. The reference versions would then be passed on to a porting house to translate the different references to the thousands of other required SKUs.
Companies like Gameloft still brute force their way through porting. That's why Gameloft's games are constantly at a higher quality than the rest of the industry. However, it is just not possible for smaller companies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with 5000 developers.
There are many companies out there developing engines to cut porting costs. Mobile-Distillery is one I was in contact with quite a lot, but we ended up never using it. So, I can't vouch for them. The problem here is that you will be at the mercy of another companies engine. Performance could be problematic due to the fact that it is being built to target thousands of SKUs. Plus, you really have little control over the low level implementation of your game in this instance. The end result seems to be a game that targets the lowest common denominator of phones.
Finally, a lot of developers are just abandoning the idea of supporting all mobile platforms. There is a huge flood on games on the iPhone because 1) it requires only targeting one platform and 2) there is a 70 percent profit share through the AppStore for developers. Through carrier releases, the percentage is not even comparable.
This of course depends on in which language your "simple engine" is written. Java is supposed to be easier to move between platforms, since it in effect is a platform of its own. If your engine is written in something more low-level, like C++, it will likely depend on platform-specific libraries for graphics and input, since C++ doesn't provide you with that.
I can personally recommend edgelib as a cross platform layer for mobile games and application development.
It is widely used, offers excellent performance and supports most of the important smartphone platforms in existence today: Symbian, Win Mobile, IPhone and others.
Most important: It's cheap and offers a free complete evaluation until you decide to produce commercial content with it.
You can find it at: http://www.edgelib.com
You can see a showcase of games and other projects based on this platform at the site.
Unfortunately, BREW is not supported though. And since it isn't a real open platform, it poses quite a challenge compared to other mobile OS platforms as it's development community is mostly professional and not very "talkative" in online terms...
This will perhaps change as the competition is getting more open by the minute.
I am not affiliated with Edgelib... this is just my personal opinion. :)
There is no free lunch. The platforms you are considering are not compatible, most of then allow you to run C/C++ code so in theory you could port the engine to some Standard, such as ANSI, or C99 and it would compile in most of the platforms PC, BREW however this does not take in account the libraries your engine might need. For example if your engine uses OpenGL then it would work in the PC, and some consoles but on Symbiam devices you need OpenGL-ES which is not exactly the same, so you need an abstraction for all libraries you use.
About J2ME and Android they are Java platforms, so no C/C++ can be run there without any special VM lib at least. In this case you need to port the C/C++ code to Java which can be overkiling.
So my answer to this is while you can make an abstraction to your libs and code using standards you might be able to use the same engine in several platforms as long you can use the same compiler for them.
Take a look for example to this engine CubicVR it allows you to compile the same engine for PC/Linux/MAC/iPhone (maybe)/Sony PlayStation Portable
What I have used for multiplatform development is to implement a hardware abstraction layer. The engine is coded in C++ but using a plain C interface to implement the system calls. This allows you to use full-fledged C++ for your game and engine and link with the system abstraction written in whatever language your platform needs. Symbian doesn't support 100% of the features of C++, and still has a few bugs, and IPhone API uses Objective C. C is compatible which most of the platforms you mention (well, not Java) and linking C is easier than C++, as there are less problems (ABIs and all that stuff).
Implementing a additional interface in C is a little slower, but will help you a lot when porting it to other platforms. Also, it allows you to have a Win32/Linux/Mac build besides the Symbian, BREW, etc. one. I have worked, mainly, with Symbian and N-Gage, and the debugging capabilities of those platforms are signifficantly behind Visual Studio or GDB. Iphone, on the other side, has a lot of cool tools to debug and profile your app.
If the engine you have is not written in JAVA or FLASH I don't see a way that you can use your engine out of the box without recoding it in a language which might run on a mobile phone.
If it is coded in JAVA or FLASH, I think you're main problem (beside the performance difference between a phone and a pc) is the main memory. As I've heared, the main memory is the biggest problem in mobile phone game development.
As others have pointed out, if your engine is built on top of some 'platform independent' framework such as Java, then it's supposedly easier than if it's written in a lower level language. However, neither Java nor Flash is, for example, supported on the iPhone/iPod touch, and it'll probably take a while until they are. On the other hand, if I recall correctly, the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn't use to implement your engine.
In general, it depends on the application/game engine you've written. Most likely you'll have to change something, as very rarely are all features available on all platforms. J2ME graphics is a classic scenario of 'platform independent'-dependence, or so I've heard. How much you'll have to change solely depends on how portable your code is, i.e. how well did you separate out the parts that potentially need changing.
Unfortunately, this is the best answer I can give you.