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.
Originally Posted by benarmstrong
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.
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.