Just to point something out that the non-developers here might not know about...
Oracle sued Google for Android because Google recreated the Java API with it's own code in Android. Oracle lost the case, but it has been appealed. Still, it doesn't look good for Oracle as the the EFF, courts, and computer scientist are siding with Google. The precedence seems to be saying that the API cannot be copyrighted only the code that powers the API.
The catch is Java is open source and iOS is not. So does the precedence apply? Is the iOS API copyrighted or only the code that powers it?
BlueStacks is clearly counting on the precedence set in the Oracle v. Google case to protect them. This product would have taken YEARS to develop, so there is no way this is new. They've just been waiting for the right time. BlueStacks probably feels with everything leaning in Google's favor against Oracle, they can afford to risk it.
Personally, I think BlueStacks is taking a HUGE risk. Going to be really interesting to see what happens.
Rednival, just put the question to the previous poster, BenArmstrong. He officially represents Blue Stacks.
Previous court rulings state that you can't copy write API's (the abstracted interface that connects an app to iOS in this case), you can only copy write the code beneath the API. If this company made their own API without using any Apple code, there isn't much Apple can do. Then again Apple thinks they own the rights to a rectangular box, so you know they will try to stop them.
Like other's have said, the developer would have to resubmit their app to gamepop. As a developer myself, I'm assuming most developers will do this. If you can expose your app to a larger group of people with no extra development, you will. Perhaps Gamepop won't do so well, but I bet Google, Microsoft, and maybe even Blackberry would love to buy this technology.
I'm sure some where in Apple's TOS to developers it states that they are developing exclusively for iOS and all iOS devices, so if a hacker creating a game console violates that TOS, couldn't that be used in court?
Nonsense. Look at how many games there are that are on both iOS and Android. What makes you think that developers agree to be exclusive on iOS.
If you have other questions, I'll try to answer but I'm hopping around articles answering comments so it might take a minute
Hi Ben, thanks for hopping in.
My question is whether BlueStacks has created an iOS emulator (so that a compiled iOS application could be run on your console with no recompiling of source code), or whether you've created an iOS-compatible SDK (and tools) and so existing iOS applications will need to be rebuilt against your SDK to run on the console (even if it requires no code changes)?
If it's an emulator, then are you concerned about possible patent violations? If it's an SDK, then are you concerned about trying to keep your SDK up-to-date with Apple's iOS SDK as they make changes to it?
You'll be able to take the code written for iOS and compile it using your SDK to run on your gaming device. So no one is going to be taking iOS games directly from the App Store and running them on non-Apple devices. Developers, however, will be able to use the exact same code that compiles in XCode to compile a package (using your SDK) that runs on Android. The only exception/gotcha is that code relating to in-app purchases will have to be modified to use Google or Amazon for payments.
Does that about sum it up?
Quote:
Originally Posted by Gatorguy
Rednival, just put the question to the previous poster, BenArmstrong. He officially represents Blue Stacks.
I welcome Ben to comment on whether my assumption above (of how this works) is correct, but I seriously doubt he would reveal (or be privy to) any possible legal defense strategy that would be used, assuming a legal challenge arises.
Interesting. No clue how this happens without a law suit. Someone smarter than me want to chime in why not?
Remember Psystar? There will be a lawsuit and you can take that to the bank. But, of course, we'll first have listen to all the "monopoly" crap we heard when Psystar assumed room temperature. You know, the claims that Apple had a monopoly on the Apple hardware business. Stupidity reigns supreme on the Internet.
My question is whether BlueStacks has created an iOS emulator (so that a compiled iOS application could be run on your console with no recompiling of source code), or whether you've created an iOS-compatible SDK (and tools) and so existing iOS applications will need to be rebuilt against your SDK to run on the console (even if it requires no code changes)?
If it's an emulator, then are you concerned about possible patent violations? If it's an SDK, then are you concerned about trying to keep your SDK up-to-date with Apple's iOS SDK as they make changes to it?
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop (and we'll do all the porting/engineering work for developers). Only code changes necessary by a developer would be to add in a 3rd party payments SDK such as, Amazon or Google, in order to make IAP work.
Not concerned about any legal challenges as we have specifically stayed away from using any patented code or Apple "bits." Same is true of our Android partnerships, we don't have an SDK that we are forcing developers to integrate in order to be on GamePop. We are focused on bringing the best content to TV and giving developers the best shot at making real money from this growing market segment.
Quote:
Originally Posted by rednival
So, benarmstrong, if I understand this correctly:
You'll be able to take the code written for iOS and compile it using your SDK to run on your gaming device. So no one is going to be taking iOS games directly from the App Store and running them on non-Apple devices. Developers, however, will be able to use the exact same code that compiles in XCode to compile a package (using your SDK) that runs on Android. The only exception/gotcha is that code relating to in-app purchases will have to be modified to use Google or Amazon for payments.
Does that about sum it up?
I welcome Ben to comment on whether my assumption above (of how this works) is correct, but I seriously doubt he would reveal (or be privy to) any possible legal defense strategy that would be used, assuming a legal challenge arises.
@Rednival - A game as it stands today wouldn't work straight out of the App Store. We do work some magic on our backend to make it work properly using APIs, proprietary tech etc. We also have to do the key mappings to make the controllers work perfectly. There's definitely work we have to do on our end, but as far as the developer is concerned, he is pretty much free to focus on his games. The only exception being that if there is IAP, there will need to be a 3rd party payment SDK integrated (of which we take $0). We've done our homework to make sure we are on solid ground. There's not much to tell from a legal aspect.
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop (and we'll do all the porting/engineering work for developers). Only code changes necessary by a developer would be to add in a 3rd party payments SDK such as, Amazon or Google, in order to make IAP work.
Not concerned about any legal challenges as we have specifically stayed away from using any patented code or Apple "bits." Same is true of our Android partnerships, we don't have an SDK that we are forcing developers to integrate in order to be on GamePop. We are focused on bringing the best content to TV and giving developers the best shot at making real money from this growing market segment.
ok, thanks for the answer Ben. I appreciate that you can't go into specific technical details about it.
As an app developer whose main interest is in selling as many copies of my app as possible, I wouldn't really be concerned about a platform's patent violations one way or another (given that it wouldn't affect me). However, as someone whose had my own technology copied and sold (and not had the resources to do much about it), I tend to feel strongly on the matter.
My concern is that, even without using any Apple code/bits, your emulator might duplicate a patented behaviour of iOS in some way (given that Apple has patented a number of iOS behaviours). However, if you've limited it to games only, then it's likely easier to avoid such patents.
You'll be able to use the GamePad controller that comes with every console. Or, you can download the GamePop companion apps for iPhone/iPad or Android. You'll be able to use whatever device you have in your pocket to launch and control apps on your TV. It's pretty crazy how much more alive it makes the games feel when you can turn your phone to the right and see the car on the screen move to the right. Accelerometer FTW!
That's just Mac OS 10.7, the successor to Mac OS 10.8.
It's likely iOS 7 -- which is the next version. Of course, it's quite coincidence that they are ALSO going to be announcing 10.7 OS -- but I doubt they want to ruin their naming conventions and tie both in this way.
Graphics are only one small part of a game, and that's all OpenGL provides. There's also audio, networking, input handling, etc. It's a minefield of potential patent violations emulating all of this identical to iOS.
I'm a game developer with strong familiarity in the iOS SDK APIs for audio, networking and input handling. To assert that this is a "minefield of potential patent violations" is kinda silly. While Apple's APIs are well designed, they are not doing anything particularly proprietary or that can't be replicated by someone competent without violating any patents.
In fact, I challenge you to find a single patent that Apple has filed that a console would have to violate to do what they're doing. Otherwise what you're saying is effectively, you *fear* there are patents and you're *uncertain* how someone could make a console that doesn't violate them and you *doubt* that these people have done so. But FUD is not knowledge, it's not even an informed perspective. I'm well informed about the SDK, have you got any patents to back up your claims?
Really, it would be pretty hard to patent the stuff the iPhone does because most of it has been done more than 20 years ago--- in these areas. Touch interfaces and recognition is a different story. But for game code? Show us some patents that a console would violate.
Quote:
Originally Posted by benarmstrong
Hi all,
Lots of good questions and concerns here. I'll see if I can answer a few of them for you:
1) We definitely aren't just taking games from the App Store and making them work.
2) Many games work with no modifications needed from developers. If there is IAP present, the developer will need to add a 3rd party SDK to handle payments and then it's ready to go.
3) Outside of potentially adding a payment SDK, then there is no work needed by a developer. We (our engineering team) builds all of the controls and does the key mapping internally. This is to ensure there is no lag time (even 5ms lag is a game destroyer in Fruit Ninja) and that developers can focus on building great games.
So, you seem to contradict yourself. In point one, you imply that you cant' run AppStore binaries (eg: not emulation) in point 3 you claim that your engineers need to add code - meaning the games need to be recompiled. In point two (and one) you say "no modifications" are necessary.
Quote:
Originally Posted by benarmstrong
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop
Ben- You're a marketing person, are you not? Your "tech magic" comment gives it away. You are contradicting yourself. If it is an emulator-- which people are concerned bout-- then there would be no "porting" of the games. If it's a compatible API-- then there is porting, and no emulator. These are mutually exclusive approaches.
It seems quite clearly that this is a compatible API and you're talking about porting-- but you're using the word "emulator" and you're the one confusing "even the saviest of tech reporters" by doing so.
You give the impression that you don't really understand how it works. There's nothing proprietary about providing a compatible API (except how you do it, which nobody here cares about).... so this straightforward question should be easy to answer.
What about game center achievements or in app purchases? Freemium games depend on in app purchases for income, and then the ad supported apps/games too, and then games like Infinity Blade 2 where you are required to login (annoyingly) to Facebook to play the dailies.
using the word "emulator" is confusing "even the saviest of tech reporters"
This happens with WINE and Crossover (likely why WINE stood for Wine Is Not an Emulator - http://www.winehq.org/about/ ) - these run Windows apps without Windows. They do the same sort of thing, catching the function calls and handling them with their own code. There are often incompatibilities with WINE/Crossover though so compiling against the compatibility layer would ensure apps work properly.
I reckon some games will be tricky to get working properly. The Ouya console has a cursor overlay to be able to do things like grab the catapult in Angry Birds. Even for games where controls can be mapped to fixed hotspots, there are often in-game actions that have a touch area that changes throughout the game. The upcoming Deus Ex game for example has in-game objects to interact with and a whole touch-based augmentation area. Having to use a cursor for all that could be quite tedious.
Obviously, it's up to the developer to decide if it's worth the effort porting their games over and implementing a whole new control scheme.
I suppose we'll see a few of these type of fairly cheap gaming boxes but things like Angry Birds are on the PC now so a Steam Box would be a more worthwhile buy for gaming IMO. Even Intel has tiny, inexpensive boxes:
I'm no expert, but I'm fairly sure that you can't legally virtualise an OS without the permission of the OS owners. It's not about who owns the code underneath the virtualisation, it's about being allowed to run the OS in that way at all.
I wouldn't worry about it anyway as the device seems kinda crappy and it's aimed at a very tiny segment of the market (people who like iOS and the games but are somehow still needing a physical controller instead of using the on-screen controls). In other words, mostly old-school gamers, people who rip off games and use emulators etc. This is also a shrinking market segment, so even if it gets off the ground it won't last long.
I'll offer another possibility. Look up the Dolphin Emulator. This thing can emulate the Wii. The performance of most iOS and Android devices are around 30% of that generation's living room consoles. Dolphin emulates the Gamecube/Wii without emulating the OS and doesn't require any Nintendo firmware. In fact, given an extremely specific model of dvd-rom you can play GC/Wii discs on your PC.
This is how I think these up-coming iOS and Android "game consoles" are going to work. They're simply going to visualize the parts (CPU/GPU) needed, emulate the rest. Since the underlying API's are still OpenGL in games, sending openGL instructions is only slightly more than trivial.
The real difficulty, and what makes me unlikely to ever consider buying this, or that MadCatz Android tv console device is that the actual technique to getting the software on the device is unlikely to be anything easy.
If I buy a bunch of software on iTunes, it's not going to automatically be copied to these third party devices. No what's going to be required is that the developer's actually develop for these consoles using some middleware that allows unchanged iOS and Android software to be be used on it. eg, the binary you'd normally send Apple is sent instead to them, and it wraps the API.
At any rate the Ouya http://www.ouya.tv/ , madcatz project mojo http://www.madcatz.com/first-look-project-m-o-j-o/ , aren't doing anything new that previous attempts (XGP, GP2x, GP32, Pandora http://www.open-pandora.org/) at homebrew-able game consoles haven't done and failed commercially at before. What you'll notice is that the the entire purpose of these "open" consoles is to play pirated games. It may not be marketed as such, but that is the only reason people buy them and flash carts.
Of course you can virtualise an OS without permissions from the manufacturer.
You simply create a set of APIs that mimic the signatures of the APIs that Apple provide.
That's what the ReactOS project is aiming to do with Windows NT.
The application will have no idea it's not running on Apple's architecture.
There seem to be a lot of people here who do not understand what GamePop is doing. They are creating their own OS that has all of the known and needed Apple API's. This is not even 'virtualizing an OS', it is creating a compatible OS. I am not saying they will not be sued but this is technically possible WITHIN the bounds of copyright law. There could be patent issues that cause problems for GamePop. I am assuming that a game dev will have to do a mild edit and recompile and that is about it. I doubt the software would run with zero modifications due to signatures.
There seem to be a lot of people here who do not understand what GamePop is doing. They are creating their own OS that has all of the known and needed Apple API's. This is not even 'virtualizing an OS', it is creating a compatible OS. I am not saying they will not be sued but this is technically possible WITHIN the bounds of copyright law. There could be patent issues that cause problems for GamePop. I am assuming that a game dev will have to do a mild edit and recompile and that is about it. I doubt the software would run with zero modifications due to signatures.http://cryptoanarchy.com/
As I understand it, it's similar to the WINE project for Linux. It runs the apps natively without having the OS available.
As I said before, there's nothing illegal about this. As long as they're not using Apple's code, there's no copyright violation - just as WINE didn't violate Microsoft's copyrights.
The only risk is if the system does something which infringes an Apple patent - which is entirely possible. But they should be OK as far as copyrights are concerned.
If it ran an app direct from what's on itunes then they would at least break copyright on the encryption.
If the an app uses the default ios and this still looks the same or similar, then there going to breaking copyright on the ui.
Id also question how much of the api's you could actually recreate before you end up breaking copyright. For instance im not 100% certain how far down the ui views actually compile. On certain OSX apps you can get access to the files and edit them. If it were the same on ios then reading the file and interpreting it would certainly break copyright on the file format.
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop (and we'll do all the porting/engineering work for developers). Only code changes necessary by a developer would be to add in a 3rd party payments SDK such as, Amazon or Google, in order to make IAP work.
The article headline should read "GamePop console to run games ported from iOS with few changes" instead of "GamePop console to run iOS apps without using any Apple code". As written, it is not very clear.
Comments
Rednival, just put the question to the previous poster, BenArmstrong. He officially represents Blue Stacks.
Like other's have said, the developer would have to resubmit their app to gamepop. As a developer myself, I'm assuming most developers will do this. If you can expose your app to a larger group of people with no extra development, you will. Perhaps Gamepop won't do so well, but I bet Google, Microsoft, and maybe even Blackberry would love to buy this technology.
It says they're not using Apple code, so there are no copyright issues.
Since they're not using Apple code and don't run iOS, there are also not TOS issues.
The only possible issue would be if they are emulating a feature covered by an Apple patent. That could be a problem.
Nonsense. Look at how many games there are that are on both iOS and Android. What makes you think that developers agree to be exclusive on iOS.
Quote:
Originally Posted by benarmstrong
If you have other questions, I'll try to answer but I'm hopping around articles answering comments so it might take a minute
Hi Ben, thanks for hopping in.
My question is whether BlueStacks has created an iOS emulator (so that a compiled iOS application could be run on your console with no recompiling of source code), or whether you've created an iOS-compatible SDK (and tools) and so existing iOS applications will need to be rebuilt against your SDK to run on the console (even if it requires no code changes)?
If it's an emulator, then are you concerned about possible patent violations? If it's an SDK, then are you concerned about trying to keep your SDK up-to-date with Apple's iOS SDK as they make changes to it?
So, benarmstrong, if I understand this correctly:
You'll be able to take the code written for iOS and compile it using your SDK to run on your gaming device. So no one is going to be taking iOS games directly from the App Store and running them on non-Apple devices. Developers, however, will be able to use the exact same code that compiles in XCode to compile a package (using your SDK) that runs on Android. The only exception/gotcha is that code relating to in-app purchases will have to be modified to use Google or Amazon for payments.
Does that about sum it up?
Quote:
Originally Posted by Gatorguy
Rednival, just put the question to the previous poster, BenArmstrong. He officially represents Blue Stacks.
I welcome Ben to comment on whether my assumption above (of how this works) is correct, but I seriously doubt he would reveal (or be privy to) any possible legal defense strategy that would be used, assuming a legal challenge arises.
Quote:
Originally Posted by Andysol
Interesting. No clue how this happens without a law suit. Someone smarter than me want to chime in why not?
Remember Psystar? There will be a lawsuit and you can take that to the bank. But, of course, we'll first have listen to all the "monopoly" crap we heard when Psystar assumed room temperature. You know, the claims that Apple had a monopoly on the Apple hardware business. Stupidity reigns supreme on the Internet.
Quote:
Originally Posted by auxio
Hi Ben, thanks for hopping in.
My question is whether BlueStacks has created an iOS emulator (so that a compiled iOS application could be run on your console with no recompiling of source code), or whether you've created an iOS-compatible SDK (and tools) and so existing iOS applications will need to be rebuilt against your SDK to run on the console (even if it requires no code changes)?
If it's an emulator, then are you concerned about possible patent violations? If it's an SDK, then are you concerned about trying to keep your SDK up-to-date with Apple's iOS SDK as they make changes to it?
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop (and we'll do all the porting/engineering work for developers). Only code changes necessary by a developer would be to add in a 3rd party payments SDK such as, Amazon or Google, in order to make IAP work.
Not concerned about any legal challenges as we have specifically stayed away from using any patented code or Apple "bits." Same is true of our Android partnerships, we don't have an SDK that we are forcing developers to integrate in order to be on GamePop. We are focused on bringing the best content to TV and giving developers the best shot at making real money from this growing market segment.
Quote:
Originally Posted by rednival
So, benarmstrong, if I understand this correctly:
You'll be able to take the code written for iOS and compile it using your SDK to run on your gaming device. So no one is going to be taking iOS games directly from the App Store and running them on non-Apple devices. Developers, however, will be able to use the exact same code that compiles in XCode to compile a package (using your SDK) that runs on Android. The only exception/gotcha is that code relating to in-app purchases will have to be modified to use Google or Amazon for payments.
Does that about sum it up?
I welcome Ben to comment on whether my assumption above (of how this works) is correct, but I seriously doubt he would reveal (or be privy to) any possible legal defense strategy that would be used, assuming a legal challenge arises.
@Rednival - A game as it stands today wouldn't work straight out of the App Store. We do work some magic on our backend to make it work properly using APIs, proprietary tech etc. We also have to do the key mappings to make the controllers work perfectly. There's definitely work we have to do on our end, but as far as the developer is concerned, he is pretty much free to focus on his games. The only exception being that if there is IAP, there will need to be a 3rd party payment SDK integrated (of which we take $0). We've done our homework to make sure we are on solid ground. There's not much to tell from a legal aspect.
Thank you both for the questions!
Quote:
Originally Posted by benarmstrong
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop (and we'll do all the porting/engineering work for developers). Only code changes necessary by a developer would be to add in a 3rd party payments SDK such as, Amazon or Google, in order to make IAP work.
Not concerned about any legal challenges as we have specifically stayed away from using any patented code or Apple "bits." Same is true of our Android partnerships, we don't have an SDK that we are forcing developers to integrate in order to be on GamePop. We are focused on bringing the best content to TV and giving developers the best shot at making real money from this growing market segment.
ok, thanks for the answer Ben. I appreciate that you can't go into specific technical details about it.
As an app developer whose main interest is in selling as many copies of my app as possible, I wouldn't really be concerned about a platform's patent violations one way or another (given that it wouldn't affect me). However, as someone whose had my own technology copied and sold (and not had the resources to do much about it), I tend to feel strongly on the matter.
My concern is that, even without using any Apple code/bits, your emulator might duplicate a patented behaviour of iOS in some way (given that Apple has patented a number of iOS behaviours). However, if you've limited it to games only, then it's likely easier to avoid such patents.
This meme again?
Good luck to them, they're going to need it.
How do you even interact with the thing?
Quote:
Originally Posted by Crowley
Good luck to them, they're going to need it.
How do you even interact with the thing?
Hi there,
You'll be able to use the GamePad controller that comes with every console. Or, you can download the GamePop companion apps for iPhone/iPad or Android. You'll be able to use whatever device you have in your pocket to launch and control apps on your TV. It's pretty crazy how much more alive it makes the games feel when you can turn your phone to the right and see the car on the screen move to the right. Accelerometer FTW!
- Ben from BlueStacks
That's just Mac OS 10.7, the successor to Mac OS 10.8.
It's likely iOS 7 -- which is the next version. Of course, it's quite coincidence that they are ALSO going to be announcing 10.7 OS -- but I doubt they want to ruin their naming conventions and tie both in this way.Quote:
Originally Posted by auxio
Graphics are only one small part of a game, and that's all OpenGL provides. There's also audio, networking, input handling, etc. It's a minefield of potential patent violations emulating all of this identical to iOS.
I'm a game developer with strong familiarity in the iOS SDK APIs for audio, networking and input handling. To assert that this is a "minefield of potential patent violations" is kinda silly. While Apple's APIs are well designed, they are not doing anything particularly proprietary or that can't be replicated by someone competent without violating any patents.
In fact, I challenge you to find a single patent that Apple has filed that a console would have to violate to do what they're doing. Otherwise what you're saying is effectively, you *fear* there are patents and you're *uncertain* how someone could make a console that doesn't violate them and you *doubt* that these people have done so. But FUD is not knowledge, it's not even an informed perspective. I'm well informed about the SDK, have you got any patents to back up your claims?
Really, it would be pretty hard to patent the stuff the iPhone does because most of it has been done more than 20 years ago--- in these areas. Touch interfaces and recognition is a different story. But for game code? Show us some patents that a console would violate.
Quote:
Originally Posted by benarmstrong
Hi all,
Lots of good questions and concerns here. I'll see if I can answer a few of them for you:
1) We definitely aren't just taking games from the App Store and making them work.
2) Many games work with no modifications needed from developers. If there is IAP present, the developer will need to add a 3rd party SDK to handle payments and then it's ready to go.
3) Outside of potentially adding a payment SDK, then there is no work needed by a developer. We (our engineering team) builds all of the controls and does the key mapping internally. This is to ensure there is no lag time (even 5ms lag is a game destroyer in Fruit Ninja) and that developers can focus on building great games.
So, you seem to contradict yourself. In point one, you imply that you cant' run AppStore binaries (eg: not emulation) in point 3 you claim that your engineers need to add code - meaning the games need to be recompiled. In point two (and one) you say "no modifications" are necessary.
Quote:
Originally Posted by benarmstrong
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop
Ben- You're a marketing person, are you not? Your "tech magic" comment gives it away. You are contradicting yourself. If it is an emulator-- which people are concerned bout-- then there would be no "porting" of the games. If it's a compatible API-- then there is porting, and no emulator. These are mutually exclusive approaches.
It seems quite clearly that this is a compatible API and you're talking about porting-- but you're using the word "emulator" and you're the one confusing "even the saviest of tech reporters" by doing so.
You give the impression that you don't really understand how it works. There's nothing proprietary about providing a compatible API (except how you do it, which nobody here cares about).... so this straightforward question should be easy to answer.
I suggest you get an engineer to weigh in.
What about game center achievements or in app purchases? Freemium games depend on in app purchases for income, and then the ad supported apps/games too, and then games like Infinity Blade 2 where you are required to login (annoyingly) to Facebook to play the dailies.
This happens with WINE and Crossover (likely why WINE stood for Wine Is Not an Emulator - http://www.winehq.org/about/ ) - these run Windows apps without Windows. They do the same sort of thing, catching the function calls and handling them with their own code. There are often incompatibilities with WINE/Crossover though so compiling against the compatibility layer would ensure apps work properly.
I reckon some games will be tricky to get working properly. The Ouya console has a cursor overlay to be able to do things like grab the catapult in Angry Birds. Even for games where controls can be mapped to fixed hotspots, there are often in-game actions that have a touch area that changes throughout the game. The upcoming Deus Ex game for example has in-game objects to interact with and a whole touch-based augmentation area. Having to use a cursor for all that could be quite tedious.
Obviously, it's up to the developer to decide if it's worth the effort porting their games over and implementing a whole new control scheme.
I suppose we'll see a few of these type of fairly cheap gaming boxes but things like Angry Birds are on the PC now so a Steam Box would be a more worthwhile buy for gaming IMO. Even Intel has tiny, inexpensive boxes:
http://www.amazon.com/Intel-Next-Computing-Black-BOXDCCP847DYE/dp/B00B7I8HZ4/
http://www.amazon.com/Intel-Computing-Gigabit-i3-3217U-DC3217IYE/dp/B0093LINVK
Haswell graphics would give it a boost and should play most Windows games at a quality to rival the PS3/360.
I'll offer another possibility. Look up the Dolphin Emulator. This thing can emulate the Wii. The performance of most iOS and Android devices are around 30% of that generation's living room consoles. Dolphin emulates the Gamecube/Wii without emulating the OS and doesn't require any Nintendo firmware. In fact, given an extremely specific model of dvd-rom you can play GC/Wii discs on your PC.
This is how I think these up-coming iOS and Android "game consoles" are going to work. They're simply going to visualize the parts (CPU/GPU) needed, emulate the rest. Since the underlying API's are still OpenGL in games, sending openGL instructions is only slightly more than trivial.
The real difficulty, and what makes me unlikely to ever consider buying this, or that MadCatz Android tv console device is that the actual technique to getting the software on the device is unlikely to be anything easy.
If I buy a bunch of software on iTunes, it's not going to automatically be copied to these third party devices. No what's going to be required is that the developer's actually develop for these consoles using some middleware that allows unchanged iOS and Android software to be be used on it. eg, the binary you'd normally send Apple is sent instead to them, and it wraps the API.
At any rate the Ouya http://www.ouya.tv/ , madcatz project mojo http://www.madcatz.com/first-look-project-m-o-j-o/ , aren't doing anything new that previous attempts (XGP, GP2x, GP32, Pandora http://www.open-pandora.org/) at homebrew-able game consoles haven't done and failed commercially at before. What you'll notice is that the the entire purpose of these "open" consoles is to play pirated games. It may not be marketed as such, but that is the only reason people buy them and flash carts.
Quote:
Originally Posted by UnbiasedDave
Of course you can virtualise an OS without permissions from the manufacturer.
You simply create a set of APIs that mimic the signatures of the APIs that Apple provide.
That's what the ReactOS project is aiming to do with Windows NT.
The application will have no idea it's not running on Apple's architecture.
There seem to be a lot of people here who do not understand what GamePop is doing. They are creating their own OS that has all of the known and needed Apple API's. This is not even 'virtualizing an OS', it is creating a compatible OS. I am not saying they will not be sued but this is technically possible WITHIN the bounds of copyright law. There could be patent issues that cause problems for GamePop. I am assuming that a game dev will have to do a mild edit and recompile and that is about it. I doubt the software would run with zero modifications due to signatures.
As I understand it, it's similar to the WINE project for Linux. It runs the apps natively without having the OS available.
As I said before, there's nothing illegal about this. As long as they're not using Apple's code, there's no copyright violation - just as WINE didn't violate Microsoft's copyrights.
The only risk is if the system does something which infringes an Apple patent - which is entirely possible. But they should be OK as far as copyrights are concerned.
If it ran an app direct from what's on itunes then they would at least break copyright on the encryption.
If the an app uses the default ios and this still looks the same or similar, then there going to breaking copyright on the ui.
Id also question how much of the api's you could actually recreate before you end up breaking copyright. For instance im not 100% certain how far down the ui views actually compile. On certain OSX apps you can get access to the files and edit them. If it were the same on ios then reading the file and interpreting it would certainly break copyright on the file format.
Quote:
Originally Posted by benarmstrong
The easiest way to describe it (even to the savviest of tech reporters) is that our proprietary (that's the key word) technology is most like an emulator in functionality. I won't be able to divulge all the secrets and tech magic we have been working on, but suffice it to say a game built for iOS as it stands today is 90% complete and ready to be ported over to GamePop (and we'll do all the porting/engineering work for developers). Only code changes necessary by a developer would be to add in a 3rd party payments SDK such as, Amazon or Google, in order to make IAP work.
The article headline should read "GamePop console to run games ported from iOS with few changes" instead of "GamePop console to run iOS apps without using any Apple code". As written, it is not very clear.