Slashdot Mirror
Cross With the Platform
Tim Bray tweeted, No platform has hit the big time till it's been flamed by JWZ. He was referring to this rant in which Zawinski systematically dismantles any claim the iPhone has to cross-platform compatibility. "I finally got the iPhone/iPad port [of Dali Clock] working. It was ridiculously difficult, because I refused to fork the MacOS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right? Oh ho ho ho. I think it's safe to say that MacOS is more source-code-compatible with NextStep than the iPhone is with MacOS. ... they got some intern who was completely unfamiliar with the old library to just write a new one from scratch without looking at what already existed. It's 2010, and we're still innovating on how you pass color components around. Seriously?"
The OS is the same, but UIKit is NOT the AppKit. It's like bitching against linux when trying to build your Qt code against gtk.
People don't like developing for the iP[whatever]. I suppose we'll be seeing a new article every time someone somewhere complains about it.
#ifdef APPLE_HARDWARE
doItTheirWayOrHitTheRoad();
#endif
You complaining about a company that retains control of whether or not you can release the app to the device even if it conforms perfectly to their APIs. If that's not a deal breaker for you why do you think that complaining about shitty incompatible frameworks or passing colour components on slightly different programs is going to worry them? You're wasting your breath.
These posts express my own personal views, not those of my employer
Windows mobile probably has more of a backwards compatibility problem than the iphone... The core OS of the iphone is the same as normal OSX and it's only the interface APIs which are different - and rightly so, the whole interface is fundamentally different in how you interact with it.
Windows mobile on the other hand is a whole different os with a completely different kernel.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The only valid complaint I see in this whole article is with NSColor/UIColor – NSColor really should be in the Foundation API (common to both Mac OS and iPhone OS), not the AppKit/UIKit APIs.
His OpenGL example is hilarious. "Oh my god, I can't use glBegin and glVertex"... Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!
As for UIKit being very different from AppKit... Well of course it is! UIKit is for building touch based UIs, if you transfer the exact same things as you have on Mac OS straight over, you end up with a shit mishmash of rubbish. The important thing here is that both APIs share their Foundation API (the basic programmery stuff you need like dictionaries, arrays, strings, etc).
the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right?
And at the core, they are - they share a large amount of code, with iPhone OS running a slightly modified version of the Darwin kernel. Where they diverge though, might have something to do with the whole UI being completely different. I assume he just didn't realise that the UI was different, since that seems to be the level of discourse available. So an app written for OS X, using a window manager with a point and click mouse and variable screen res, just dropped right onto a fixed resolution, touchscreen device.... Right. No need to change any code! (or rather, it'll be a simple case of "if iphone then do x..").
I'm all for criticising the iPhone's genuine faults, but this sounds like a kid who threw his toys out of the pram and is whining to get them back, only to want to throw them out again.
In TFA, JWZ said "It was ridiculously difficult, because I refused to fork the MacOS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right?"
FLAMESUIT ON
At the risk of being shot down by every MacOS/iPhone hacker here... There are two main points that JWZ makes which are quite interesting:
1) I refused to fork the MacOS X code base
2) the desktop and the phone are both supposedly within spitting distance of being the same operating system
So the beef he has, while totally valid is because of:
a) refusal to fork the codebase
b) assumed that both iPhone OS == MacOS X
Hmm. I understand the refusal to fork the codebase, but if that's what's _required_ then that's what needs to be done to have the app on the iPhone. And what's the other bit about "assume" making an ass out of you and me? Ditto for the OpenGL/OpenGLES rant...
FLAMESUIT OFF
The Wknd Sessions - Malaysian and South East Asia independent music
The problem is not that the UI is -completely- different.
It's an UI that is massively the same, just ran through a bulk rename, shuffle parameters order around in function calls and explode/implode some methods / typical sequences.
The UI -could- have been VERY similar, with only minimal differences easy to #ifdef through - the underlying philosophy is. Instead, there was some active effort put in making it totally incompatible, where making it compatible would be easier and more obvious.
A typical case of "an extra week of writing code can save you a hour you'd spend on reading documentation instead."
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!
Unless I'm missing something, or you're living in 2020, OpenGL version 2 was released in 2005, and you're 10 years off.
Oh, btw, it was deprecated in OpenGL 3.0 - 13 years off from being accurate.
Can we all please stop making apps, and start making web-apps?
Then we can all benefit from your development effort, and we are not restricted to buying apple hardware. As an added bonus, you don't have to bend to the idiosyncrasies of the iphone api.
Yes, I know, apps allow us developers to use the convenient micro-payment system which exists in the form of the app-store, but come on, there are plenty of other ways to get paid for your work.
In the meantime, it *would* be nice if some other big company (google?) would invent a micro-payment system similar to the app-store, but (of course) for web applications instead of for a proprietary platform.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
First, if you can't modularize your code - it's not framework' fault.
Second, if a piece of code work like a clock (read: goodwritten), then you can port it to any modern platform with any modern language. That not includes special cases, e.g. porting from OGL ES 2 to OGL ES 1.
And third, don't fight against framework, use it perks instead. ifdefs is not a framework but compiler feature, it may not work fine with framework because framework was written for a particular device, not for a GCC.
No, Java Enterprise Web System I believe. I see a lot of self parodic posts blaming that API for all manner of implausible ills.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Yeah... I don't know what he's complaining about. iPhone OS uses OpenGL ES 1.1 and OpenGL ES 2.0. Of course you can't use immediate mode primitive drawing functions. In fact, you shouldn't be using them on the desktop either, if you're at all concerned about performance. Vertex buffers are the way to go.
And why should we care?
No.
More like Audi/BMW putting a 250 km/h speed limiter on the car you just bought. Sure, you can go ahead and remove the limiter yourself, and why the hell not change the fuel mappings on the ECU while your at it? Audi/BMW will not support the modifications nor honor the warranty on your car, but there's nothing 'physically' stopping you from making the modifications. They are by no means obligated nor legally required to tell you how to circumvent their limitations and reverse engineer their software.
When an engine suddenly catches on fire doing 270 km/h+, or you suddenly loose control on the car, the last thing they want is for you to point the finger at them and say: "Well you technically allowed us to do this". They are just doing everything possible to cover their asses.
Look at Windows Mobile for a minute. Stock installs are actually quite decent. But when Joe Sixpack starts installing "Bubble Popper 2.0", and "FREE XXX PIX" on his phone, and the phone shits a brick, guess who takes the blame? Yeah, Microsoft and their "damn unreliable OS".
Your evaluation period for Productivity 1.0 has ended. Please purchase more coffee to continue using this product.
If you mean, are making an AAA game title, sure, but then your job is probably "3d graphics programming specialist" or something, so you can jump through whatever hoops are necessary. There's a huge range of apps for which performance is not really a concern; they ran fine on hardware of 10 years ago, so they ought to be able to run fine on today's. xDaliClock is one of those.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Oh but don't worry, if you use the new enlightened way of doing OpenGL programming, you can write a "Hello World" app that fades between two images in:
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
All with one set of C++ client code, compiled to native executables for each platform.
If you want iPhone support, you'll need the Subversion source base; the code works, but we haven't rolled a release for a while.
Its Open Source under the MIT License, chosen specifically to be compatiable with both GNU GPL and proprietary development.
Request your free CD of my piano music.
What's worse, you're at the mercy of the web app vendor. If they take down their app or start charging more money for it, you're SOL.
Request your free CD of my piano music.
I suggest that you watch the very first dev video on beginning development for iPhone and Mac OS X and continue on from there. At no point does ANY of Apple's materials ever mention that you can write once and compile for both platforms. All they claim is that the tools and syntax and the same (XCode, Interface Builder, Objective-C, etc.). I've been programming for a few decades now and specialize in .NET. And, although I hated the experience of going from comfy C# to Objective-C, that's really the only pain. If you really look at how UIKit differs from AppKit, you may actually realize that it's the right tool for the job. Although Microsoft has paid the bills for quite some time now, I can honestly say that writing for Windows Mobile SUCKS... not because of syntax or compatibility issues, but because of the bloat and limitations of the mobile environment (Compact Framework on Windows Mobile). At least Apple got it right by accepting that the iPhone platform really IS a different animal, compared to a MacBook or Mac Pro, and built a more appropriate framework.
No, performance is *always* a concern on a battery powered device. Every single instruction has a cost in ergs. You don't want to waste them.
Can you be Even More Awesome?!
The problem with this "explanation" is that the application's effort to use vertex buffers is significantly higher than the effort to use immediate mode.
A hardware implementation of IM (like the one in Silicon Graphics machines) would probably bring much higher energy efficiency than carefully packing up VBOs with software. Even when there's no hardware implementation, the packing up can be equally well performed by a driver, thus just shifting the energy consumption around, not increasing it.
Thus, immediate mode is actually at worst just as efficient as VBs for small vertex counts or dynamic objects, and at best allows hardware acceleration where there is none with VBs.
Blame and credit alike... it does claim that if you read C code into memory, that it can then parse the read C, but I don't think it could parse the read C, which is why the java is being used for things it really doesn't want to be used for in Egypt to this day.
The revolution will not be televised... but it will have a page on Wikipedia
There are some important architectural points to keep in mind if you ever hope to take your application cross-platform. One is the separate the "engine" or core code cleanly from any kind of user interface. That way you can keep what is most fundamental about your application constant, then write a new UI to exercise it for each new platform.
Another consideration is to avoid using any platform specific APIs, formats or protocols for anything that extends outside of the application itself. I'm sure Apple's Core Data is the best thing since sliced bread - until you try to email a Core Data document to your buddy who's got an Android phone.
What is ironic is that the iPhone provides sqlite, which is a simple SQL database that keeps all its data in single files. sqlite is Open Source, and widely available, so you really could use an sqlite database as a user document, in just the same way that you couldn't do with a Core Data doc.
Request your free CD of my piano music.
No, the UI is completely different. Events are completely different, because of multi-touch-related stuff, and consequently, everything else needed to be rewritten as well. It shares naming conventions and some concepts with Mac OS X's AppKit, but that's all. Focus is different, windows are different, views are different, the first responder is mostly unused, etc.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
The problem with this "explanation" is that the application's effort to use vertex buffers is significantly higher than the effort to use immediate mode.
No, no it's not.
Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.
Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it. After that point, all the CPU need to is yell at the graphics card "now render this".
The *reason* we've moved from immediate mode to vertex attribute arrays is because they're faster and more efficient. Of note, these days, even shader pipelines are more efficient than fixed function ones, because the fixed function pipeline is commonly implemented in the driver as a shader. A shader that is doing a bunch of stuff you don't need it to, along side the stuff you do want to happen.
That I agree with, which is why I purposely quoted the part of his sentence including "on the desktop". On the desktop, the vast majority of OpenGL apps, i.e. anything except state-of-the-art AAA game, does not really need to squeeze that last bit of performance out.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Can I take this opportunity to mention that I find programmer-fights fascinating?
Carry on, guys.
You are welcome on my lawn.
As a non-OpenGL programmer, help me out here.
Is that sarcasm or are you impressed? I'm having a hard time telling. 380 lines of C for "Hello World" is a tad much, but using OpenGL to fade between images...
Learning HOW to think is more important than learning WHAT to think.
Wow dude man.
I'm also tempted to comment on his choice of development hardware (G4) being a bit on the cheapskate side, but I am not familiar with it and don't know how serviceble this older hardware is.
I am Slashdot. Are you Slashdot as well?
I haven't actually read TFA
You needn't point out that out, because it's painfully obvious that you know absolutely nothing about Dali Clock, its cross-platform history, or JWZ's own well-documented history and experience.
Educate yourself first, then speak.
http://www.jwz.org/xdaliclock/
http://en.wikipedia.org/wiki/JWZ
He's been developing ZooLib for twenty years, but it has only been Open Source for ten.
Andy is a consultant; whenever he gets a new contract, if ZooLib doesn't already provide some functionality he needs for his gig, he adds it into ZooLib.
As for the website not listing many apps - I'm the webmaster, but not a very diligent one. Most of ZooLib's apps are sold by the various clients that Andy and I have had over the years.
Request your free CD of my piano music.
You missed the part where this is the Dali Clock. The iPhone needs to melt in order for the program to be completely functional.
-- If you try to fail and succeed, which have you done? - Uli's moose
Entirely correct @ shaders.
However, I have to take exception with your description of immediate mode - the reason it performs so poorly now is that modern graphics chips are designed pretty much exclusively for DirectX (at least, this goes for ATI).
On machines where immediate mode performance was actually some kind of a priority (for instance, SGI Octane IMPACTSR and relatives), executing a glVertex command amounted to 3 memory writes into a command FIFO that was mapped into a fixed address in userspace which was accessible with a short form of a SW opcode (remember, this is MIPS, there is a range of 64k addresses that can be accessed without loading a base register: -32768 to 32767).
The hardware even managed the hiwater/lowater status of the fifo, and notified the kernel to perform a context switch to a non-gfx process when the gfx process was filling up the command FIFO. Those switches were as a matter of fact "virtualized" (before it was cool) by a combination of hardware, kernel (if hardware contexts are exceeded) and userspace - not entirely unlike what DX10 ADM was supposed to be, except this was in 1995.
For large static meshes (only transforms applied with Vertex Shaders), buffers are definitely going to perform better, because the meshes can be located in local memory (VRAM). However, if something is dynamically generated, immediate mode in a good implementation is no slower than a memcpy, and it does not require a kernel transition to submit a command buffer to card's ring (like modern cards like to do).
While there are many conceptual similarities between the two operating systems, they are different enough that they really should have been considered separate platforms from the very start.
I've been doing cross-platform development for twenty years. Don't Even Get Me Started.
Request your free CD of my piano music.
Pretty sure that's sarcasm, since it would be a couple dozen lines with the deprecated stuff.
I don't get why the ARB does half the stuff it does. Why can't we have a default shader that does all the basic stuff we've been depending on for years?
Not much of an OpenGL programmer either, but I'm pretty sure that's sarcasm.
OTH, fading between images using compositing to allow that operation to be GPU-accelerated is a pretty legitimate use of OpenGL, though.
web (specifically, web browser) development, with Major (capital M) contributions to the mozilla/netscape/firefox ecosystem since before mozilla/firefox existed as projects in their own right (going all the way back to Netscape 1.0), as well as fingers in things like Emacs and popular X applications.
STOP . AMERICA . NOW
Wow, there's a big jump from "likes Apple" to "supports child rape" - I can see why you posted AC.
For the record, I hate that the built in calendar app on the iPhone doesn't carry across the ToDo lost from iCal, only the event calendars, and that I have to use a third party app to sync my ToDo list.
I also dislike the slight pause the phone has sometimes when I answer it and it says has picked up, but there's no connection for a second or so. I'm not sure if this is the network or the phone, but it's probably the phone.
It also needs a way to lock the screen orientation by default without the use of a third party app.
The app store needs a checkbox update system so I can choose if I want to update all but one app (rather than either updating everything or updating one at a time).
Sometimes if you take a picture in landscape with the phone "upside down" (ie, tiled over one way rather than the other from vertical) the tilt sensor gets confused about which way up the photo should be and you end up having to gingerly hold it to stop it spinning all over the place - the photo app needs a way to lock rotation, and to be able to edit the "up" direction on images you have taken.
I'd also like it to keep reminding me I have an unread message via vibrate/tone if I don;t unlock the screen, rather than just remind me once.
I don't support DRM and have spoken against it in the past.
While we're on the subject of Apple faults, the Finder really needs some love, and Mail.app really needs to have a more graceful fail method if a mailserver rejects authentication rather than just continually prompting for the password with no indication of failure.
Oh, but I'm sorry, don't let my actual beliefs and opinions get in the way of your blind AC hate of Apple and preconceived ideas about me. It's a little bit pathetic and hilarious, but I feel compelled to point out the inaccuracy.
So, we were talking about how Apple's API for a fixed resolution touchscreen was different to the one for a variable resolution mouse+keyboard based GUI, and how some whining guy on a blog is complaining that Apple didn't make it as easy as "1. recompile app, 2. ????? 3.Publish on app store 4. Profit".
IF he thinks that's hard, he should try using the Java GUI on an Android app sometime.
SJW: Someone who has run out of real oppression, and has to fake it.
Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.
Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it.
Unless I'm very much mistaken, vertex arrays (in client memory) is what the driver does internally to implement immediate mode anyway. I.e. all your glVertex etc. calls are collected in an array, which is sent to the GPU on glEnd(). So, if you just do all that yourself to avoid using immediate mode, you won't gain any performance. What IS faster is using vertex buffer objects, because they reside in graphics memory and thus DON'T "require a single upload of a constant array to graphics memory" -- which might otherwise become a major bottleneck if you're rendering the same geometry over and over again.
"It's 2010, and we're still innovating on how you pass color components around. Seriously?"
It's 2010, and we're still using cars? Where's my jetpack dangnabbit!?
Because it's not optimal for how graphics cards work these days. What would you prefer - an API that makes it clear what the optimal code path is, or a way that lets you save a few lines, but results in poorer performance?
And DirectX works exactly this way too, by the way, so it's not just OpenGL. The problem that OpenGL was having was that it was getting bogged down with legacy calls that these days are bad practice.
Your argument is basically a 3D version of the "But I can write Hello World in BASIC in much fewer lines than in C!"
Indeed - not to mention that there are plenty of other mainstream widely used alternatives too (e.g., Nokia).
Jailbreaking is NOT a solution. It just isn't.
Exactly. It's interesting that it's considered an acceptable workaround for a phone that's meant to "Just Work", and is supposed to be easy to use and good for non-geeks. The irony is that whenever a similar workaround is suggested for another platform, the Iphone fans ridicule it.
Then there's the point that when we get stories about Iphone viruses, people claim it doesn't count because it only affects jailbroken phones - which is it, I wonder?
"His OpenGL example is hilarious. "Oh my god, I can't use glBegin and glVertex"... Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!"
What?
glBegin() was deprecated as of OpenGL 3.0.
OpenGL 2.0 was released in September 2004 (5 years ago.)
If you meant OpenGL 1.1, that was 13 years ago, and glBegin() certainly wasn't deprecated.
Loading...
Tell me please, then, why did he have to use OpenGL in the first place? All he wanted was to display a bitmap on the screen. You'd think such basic functionality could be supported by the API on both platforms in a compatible manner...?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
And please, the functionality and features of Gmail and Google calendar absolutely crap on the lame excuse of the Apple offerings. Don't even try to argue this one
I got about this far, thought about how I use Gmail+GoogleContacts+GoogleCalendar on my iPhone right now (and they work perfectly), and stopped reading.
Nice trolling, though. It was a good try.
This kind of thinking is what leads to decisions like "no multitasking for third party apps" ..
There is plenty of horsepower so i can be lazy and write crappy outdated code and then blame the platform for not being "backward compatible/cross platform compatible"
There is really nothing to see in this article/rant other than an angry person looking to find flaws in something because suddenly that is "the cool thing to do"
I would like to remind him however that Apple has gone out of its way to make crossPlatform be a "bad idea" on iphone, they make no apologies for it, and actually have a really good reason for doing so .. Big deal
But OpenGL immediate mode really is fast enough for a huge range of applications. It was fast enough twenty years ago, so surely it should be fast enough today also, unless someone graphics cards have magically gotten slower.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Can we all please stop making apps, and start making web-apps?
That was tried at launch, remember? People rejected the concept on a massive scale. Were you calling for Apple not to release and SDK back then?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Apple does not stop me tethering, or charge me any money for it. My iPhone had tethering out of the box for free. Don;t blame Apple for a carrier decision. Carriers in the rest of the world are not stuck in the late 90s like the US.
You mentioned tethering twice in two separate bullet points.
You can buy turn by turn navigation for a one off cost from the app store for your iPhone with at least three different apps with no monthly charges.
User replaceable battery - similar to the iPod battery exchange, they just give you a reconditioned phone in exchange for your old one. They come from the refurb department.
Number 6 is just rubbish. You know you can hard-boot the phone right? If it crashes in software (and mine has) you can force restart it without the software running, or while it's frozen. This is the same as removing the battery and replacing it, it;s just done in the phone's base firmware. There's no "scary demerit" for a problem that you are making up.
There are enough points of comparison between the iPhone and Android to work with (and some where Android is better, some where iPhone is better) without you having to make stuff up. Do you work for Fox News when not posting on slashdot?
There's a reason Apple preaches up and down about a MVC paradigm when working with Objective-C and Cocoa. It -does- make this kind of port much simpler. If the code was divided up properly in the first place, then the Model and the Controller parts would be basically just a recompile for the iPhone from MacOS X. The view would have to be redone, but as far as MacOS X -> iPhone goes that should be almost entirely done in Interface Builder.
Now granted the app in question is a very old app. But by virtue of that, given that it displays a UI, that's going to cause more work. But as someone above said, "It's like bitching against linux when trying to build your Qt code against gtk". The VIEW portion of the app is being done for different devices, and AppKit isn't exactly lean enough for embedded programming.
So all I got out of the article is that the guy maintains an old messy code base, which he usually has to fork to port to new platforms but for some weird reason he thought because the -kernel- and low level api's are the same between these two platforms, that it would just compile and run...
Brilliant.
How many websites make their source code available?
HTML5 includes support for apps that can work offline. But this requires that the entire logic of the app be written in JavaScript and that the JavaScript source code be sent to the end user's browser.
But I get almost all of that with WebOS (except for the SD card, which is quite nice).
No, I don't trust in god. He'll have to pay up front, like everybody else.
"7. I can install what I want.*"
*Provided that what you want exists for Android (and in some cases your phone's specific flavor of Android), which it probably doesn't.
0 1 - just my two bits
Windows Mobile does not have a backwards/forwards compatibility problem with desktop Windows because both run .NET. The GUI parts are different in places but you don't want to re-use those anyways as a desktop UI looks and works like crap on a mobile device. For the most part, though - and certainly including such basic bits as color management - .NET on the desktop is a perfect superset of .NET Compact Framework on Windows Mobile. Furthermore, the docs neatly outline what is available in CF and what isn't. At one of my previous jobs we used to literally compile the exact same (non-GUI) C# code for Windows Mobile and Windows XP/Vista. Only very few #ifdefs were required.
Now that Microsoft is going with Windows Phone 7, where apps will apparently be entirely Silverlight-based, I am guessing compatibility will be even better. Imaging building a web/desktop app in Silverlight/WPF and then changing the compiler flags to make an app that runs locally on any Windows Phone 7. No #ifdefs in sight. Nobody else has anything close to that level of portability between desktop/mobile except maybe Adobe.
Quality, performance, value; you get only two, and you don't always get to pick.
"Righteous indignation"? You didn't know this before you bought the phone?
Watch this Heartland Institute video
What would you prefer - an API that makes it clear what the optimal code path is, or a way that lets you save a few lines, but results in poorer performance?
I'd prefer both: a low-level API for the fastest performance, and a wrapper library for a more gentle introduction to the API. Haven't you heard of the maxim about getting it working now and fast later?
This is good advice for most programs - but we're talking about an animated clock. There's nothing there but UI code.
Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.
Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it.
Unless I'm very much mistaken, vertex arrays (in client memory) is what the driver does internally to implement immediate mode anyway. I.e. all your glVertex etc. calls are collected in an array, which is sent to the GPU on glEnd(). So, if you just do all that yourself to avoid using immediate mode, you won't gain any performance. What IS faster is using vertex buffer objects, because they reside in graphics memory and thus DON'T "require a single upload of a constant array to graphics memory" -- which might otherwise become a major bottleneck if you're rendering the same geometry over and over again.
I was forced once to develop a Windows app using Ada. Trying to develop an application on Android based on standard Java GUI libraries sounds about equally wise.
Developers are free to choose to write for whatever platform they choose.
It boils down to these items:
Do you want a large, potentially lucrative market and don't mind all the restrictions and cost associated with developing for iPhad (i.e. $99 fee, Apple hardware/software only, Objective-C only, app acceptance subject to Apple's whim, **frequent updates as each new OS release could potentially break your app, etc.), then by all means develop for the iPhad platform.
Do you want a platform for which you can choose your development hardware, software (that is available free), no restrictions on what or how you develop, Java, C++ or C languages supported, and are willing to try and market your app in smaller, more chaotic distribution channels, then go ahead and develop for the Android platform.
I would add Windows mobile development to this list, but I haven't done any development work for Windows mobile so I withhold any comments on where it fits. However, I would assume that it probably fits somewhere in between the two afore-mentioned platforms.
I've already made my choice.
**this one is bound to invoke the wrath of applemmings:
frequent updates as each new OS release could potentially break your app
I'm sorry if this invokes ire, but this is absolutely true. 99% of all updates I've received for the apps that I and my family's 4 other iPhones have installed have been updates to support the features of each subsequent OS release, and in most cases to fix them so they would even work with the new release.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
The problem is that browsers aren't completely the same and they probably never will be because every browser maker wants to differentiate their product.
If we could actually get all the parties to agree to implement a standard, we could just have a desktop standard API that includes web services. Then we wouldn't have to carry the browser model baggage.
But that's not going to happen and neither is the browser-based utopia.
Another problem is immediate mode vertex data is tied to the GPU front end vertex / data fetch rate, while vertex buffer data is read through the texture fetch path (much, much higher bandwidth). So the max rate for each type is fundamentally bottlenecked by the architecture, even if you could transfer it in at the same rate. The fixed function GPU front end is not as massively parallel as the general purpose shader engines / texture fetch portion. To reach the same levels of performance on immediate mode, the architecture would have to change significantly, and it would most likely come with a large area hit, which directly translates into chip yield / cost.
I found this quote from jwz's reply to one of the comments telling :
"Part of the problem with being spoiled for choice is nowhere is there documentation -- that I would have dearly loved to find when I was just starting to learn this stuff -- that says things like, "look, you really don't want to use anything beginning with NS, just use the CG ones, that's the maximally-compatible way." It's damned near impossible to even find statements like, "CG-based stuff will work on 10.3-present, and CG is officially not-yet-deprecated so you've got a least a few more releases before you'll be expected to rewrite it all.""
So basically he implemented things a certain way a couple of years ago and later when he wanted to reuse the code for what's basically another platform he found out that by doing it that way he fucked himself. Then he does what we all do: get mad at the gun for allowing us to shoot ourselves in the foot; "if only there'd been some documentation AND I had read it AND had been smart enough to follow the recommendations". Earth shattering, clearly. The only way this is news is because it contains the magic words Apple and iPad.
If all else fails, immortality can always be assured by spectacular error.
EMACS is great and you could post a long list of accolades, but 'top selling' wouldn't be one of them.
Every single thing in the documentation is associated with an implicit "this will be the same in at least the next two major releases of OS X", unless it has an explicit "this was deprecated in version xyz of OS X".
So far, I don't know of a single API that has been removed from Mac OS, although a lot have been deprecated since 10.0.
In general though, you're right. Expecting your code to "just work" on a brand new platform is moronic. Especially a platform as different as iPhone OS is. To be honest, most likely he's seen that there *is* a lot in common between the Mac OS and iPhone OS, and assumed they must be almost exactly the same.
I like the entirely pointless twitter link in the summary. Hey, here's what one guy thinks about iPhone development, but first, have an entirely irrelevant and content-free quip from some other guy! Yeah!
"Dismantles any claim..."? Here's a hint: if any such claim has been made by Apple, I've yet to see it in any docs or presentation.
Yes, Cocoa and Cocoa Touch are a lot alike in language and conventions. I can even get a lot of properly-structured code to work just fine between the two platforms. But at no point have I been deluded into thinking that a simple recompile is all that's needed to go from one to the other.
The rest just sounds like the ranting of a bitter old man who is reminded why programming isn't really for him anymore. (This coming from a fellow bitter old man who oddly still can't stay away from the compiler.)
Actually, there are several operations that make the vertex fetch operation less parallel than you might think. In particular, vertex sharing by multiple primitives is usually handled with a small depth (32-64 vertices) buffer. In other words, if a vertex index occurs twice in your object, but those occurences are >128 locations apart in your index buffer, the vertex will be processed twice and you won't get peak performance. Another example is the primitive assembly stage, when processed vertices that are output from the Vertex Shader are merged into primitives according to the data in the index buffer. This is a significant performance bottleneck that makes VBO bandwidth lower than fragment shaders.
The assumption that improvement of immediate mode performance would necessarily come with a large area hit is not supported. Most of the GPU area is not control units (which this would end up being, since the datapaths are already in place); it's the memory controller, raster backends and shaders. A quick look at the floorplan of a modern (>2008) GPU proves this quite readily. Even the primitive assembly / triangle setup unit usually occupies less than 2% of the GPU, and it is the current VS rate bottleneck.
It's also about command space. Say you have 64k per command buffer, and flushes are ungodly expensive. Now say that immediate-mode verts need to get placed directly in the command buffer, and VBO renders cost roughly 50 dwords per 16m verts. A wise maths person might conjecture that the maximum number of verts one might expect to submit quickly in immediate mode is about 10, yes?
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_render.c#n141
~ C.
The thing is, much of the time you don't need to write a custom shader. Usually, you just want the same processing done that's been done for ages.
The argument is more akin to "why do I have to do a bunch of syscalls to set white text, black background, for my Hello World, instead of just letting the default of white text, black background be loaded automatically?"
Especially since quite a bit of legacy hardware doesn't support shaders period!
Audi/BMW will not support the modifications nor honor the warranty on your car
Actually, at least here in the UK, they are legally obliged to honour the warranty, unless they can provide reasonable evidence that your modifications caused the fault you want them to fix. My suspicion is that the situation is similar elsewhere.
It's even better if you imagine they're both wearing monocles.
It's all there. Android is over 40,000 apps now. Anything of value you can find, go actually look instead of being an armchair quarterback. And no, I don't see the value in 20,000 duplicate fart and flashlight apps that populate the ITunes store.
1) Blame whomever you want. All the other phones can tether on AT&T. The IPhone can't. Case closed.
2) Care to back it up and mention which apps are these? And with Android I don't have to pay at all. Fail.
3) Are you serious? I spent all that money for a new phone--why would I want a used and abused one to replace it simply for a new battery? Geez, I assumed they just replaced the battery--I didn't know this. This is even worse.
4) If this is true and actually works (the hard-boot), which I doubt (software can always crash--even firmware), I'll give you that one.
Wasn't aware they integrated it. Doesn't negate the rest of my points.
I agree. WebOS is a pretty nice darn platform. I just have issue with Apple zealouts and more importantly all the tech media basically labeling it the Jesus-phone all the time, when superior alternatives exist. It's just who I am--I hate to see people duped so blatantly.
"I don't hate Apple products, I hate its users."
It's an UI
Wow... do you actually say "ooey" when verbally referring to "you-eyes"? Because, that's, like, kinda weird. :)
Re (3), there's no conception of ownership and longevity in the Apple model. The objects I've kept over the years have proven themselves to be of reliable build (including at component level!), received excellent care from me, been occasionally tweaked in nontrivial ways to my liking, etc. If someone said to me, "Well, your DVD drive is broke... I'll have to give you a whole other machine" I'd laugh out loud.
Man, me too. I always read through them and I don't know what the hell they're talking about most of the time. What is it with that? Maybe I find it fascinating that these arguments happen at all. I mean, you would think that, aside from emerging technologies, the best practices for everything has already been worked out. I guess it's silly to think that but maybe I just thought there would be less to argue about. It seems as if every point a person makes is contradicted. Is there a zen superhacker who knows all and we can just ask him? Maybe Hugh Jackman?
MG
Wait.. are you seriously suggesting that Apple change the hardware of their devices to fit the way you think the software should work??
Can you be Even More Awesome?!
No, but there's this argument going around that "immediate mode necessarily performs worse" which is simply not true, if your hardware is not constrained. My view comes from spending a good few years designing GPU chips - we could do whatever we wanted as long as there was enough demand for it.
There isn't enough demand for immediate mode, and for OpenGL in general. That doesn't mean it's not possible to make it perform well.
Additionally, Apple likes to make their own hardware (just look at their recent ex-ATI employee acquisitions) so they can do whatever they please with their chips. Especially in portables.
I did not mention command buffers as a way to submit IM operations; I agree with you entirely that it would result in very sub-par performance.
Some machines, generally older than the R300 or in fact any of the consumer hardware (the ones that OpenGL came from), were optimized for IM and executed it through direct MMIO writes from userland. This avoids the problem of both command buffer size limitations and the high price of ioctl-style command buffer submits.
My first encounter with JWZ was through the config files for Netscape 1.0. I was trying to make the software use the keyboard the way I was used to on Linux. The comments in the config files should have been an aid to that. Instead, I found a lot of angry rants signed "JWZ". Some lectured me that the usual way to configure the keyboard was stupid. Other were poorly-informed flames aimed at various UNIX workstations vendors. Very little actual technical info. I conceived a serious dislike for the dude then and there.
So I have to ask, What did JWZ ever actually accomplish? There must be something. (Working at Netscape long enough to retire on his share of the AOL buyout doesn't count.) If not, why does anybody pay attention to him?
I think Apple's proposed new licensing terms would ban this framework: "Applications that link to Documented APIs through ... [a] compatibility layer or tool are prohibited."
They basically want to make it impossible to write iPhone apps that share UI code with any other platform (including, or maybe especially, competing mobile devices where having very a similar UI in your app is perfectly sensible).
For crying out loud, lose the application fanboysim (Parent and Grand Parent). Both web applications and desktop applications have their uses.
A web app is good for a front end that is consistent for anyone who uses it and is available from anywhere. I have a few web apps installed internally and they are great for centralised control (updates, database) and can be used from anywhere.
Desktop applications are powerful and generally easier to use as they aren't constrained by mark-up languages (XML, HTML). But they are more difficult to manage (your computer may be fine, talk to me when you have 250 or even 100 with no hardware standard) and generally have more problems then web apps (.net version, doesn't work with IE8, relies on IE6 hacks, forget about Linux and Mac). Licensing is also more of an issue.
Lets look at mapping, A WMS (Web Mapping Service) like Google Maps is good for everyone to find information but if you've ever tried doing some editing in Google Maps it's a real pain. So I do editing in ArcGIS (or Google Earth pro) and upload the files into the WMS so everyone can access the information. This way I don't have to give everyone a copy of ArcGIS in order to allow them to get data out of maps.
Moral of the story, evaluate your needs and deploy a web application where it is needed and a desktop application where it is needed.
Calling someone a "hater" only means you can not rationally rebut their argument.
Audi/BMW do not prohibit you from using the car on roads though. Apple does not prohibit you from using jailbroken phones on the iTMS.
Sony does that with PSPs and Microsoft does that with XBoxes - but mostly for anti-cheat reasons. To put it in a car analogy, DOT prohibits illegal modifications from driving on public roads since they would hinder the safety of other drivers.
Your evaluation period for Productivity 1.0 has ended. Please purchase more coffee to continue using this product.
Audi puts that limiter on because their shitty front wheel / half-assed transverse 4wd cars (TT, A3) would be unhand-able.
Hatin' on products I don't like and getting modded up talking about tech I totally don't understand like it was 2005!
Same here in Australia.
If your DVD drive breaks in your Mac, they just replace the drive.
Or you HD, or LCD panel, or any component.
The reason the battery exchange exists for the iPod is that it's quick to just send out a new iPod/iPhone while yours returns to them in the mail in a prepaid box that they send you. It's convenience. You can get your own iPhone changed it you like - it just takes a little longer since you have to send it in, have them swap the battery and send it back, unless you want to buy a third party iPhone battery and change it yourself - it does have a regular friction fit connector on the PCB, it's not soldered in).
"Case closed"? - I told you, my iPhone has tethering for free out of the box. It is a carrier decision, not an Apple decision. AT&T chose not to allow it for free on the iPhone - take it up with them. Apple didn't tell them to have that policy, AT&T are just being crap there.
Turn by turn apps? I don't know if I can link to the US itunes store, but they include TomTom, one from Garmin and one from another supplier. Here is the UK iTunes Store:
(in fact, in the App Store quick links on the home page the 4th one down is "Turn by Turn Navigation"). There are several apps of varied price, including TomTom, Navigon, CoPilot, Navmii etc. I can't link directly to the store, but they are there.
For 3, you don't have to take the new phone - you can have them send you back your original phone, it just takes longer since they have to swap out the battery for you. If you go for the exchange they send you a new or a refurb phone (and the refurbs are as new, and get more extensive QA than new phones) while your phone goes back to them in a pre-paid box. It's a convenience thing. You may even get a newer and better condition phone than your original (but in the same model type - 3G, 3GS etc).
The hard boot does work, I have used it a few times. The iPhone OS software *does* crash sometimes, and does do odd crap that requires a forced boot. I also had a failed update on the phone that left it in a bricked state (iTunes not seeing it, phone not usable) but I was able to force restart it this way and enable iTunes to begin the update again from scratch.
As an update to my above reply.
The free Turn by Turn from Google may in fact be a major selling point for an Android phone being a future purchase of mine - I wouldn't be surprised if we *didn't* see it on the iPhone for that very reason. Until then, I had not seen anything compelling enough to make me consider switching, this may be it. The TomTom app, that I was so desperately waiting for (and willing to buy!) was demoed at an Apple keynote, and when finally released was *absurdly* overpriced - might as well have bought a standalone sat nav device, so as yet I have not bought the app for my iPhone.
Quick is my being able to replace the battery in 10 seconds by swapping out. Tolerable is going into a shop and their taking 10 minutes to swap it out using a special tool. Last resort is sending my equipment off to be fixed within 48 hours. There is nothing less convenient than having to wait for the post then having to backup and restore including all modifications to a new machine which will have different characteristics.
Do you have a link for the "replace the battery in your own phone" service?
Yes, it's "don't buy a device with a built in battery.com"
If the lack of the battery door (and the reduced capacity or increased physical size of the device) is a dealbreaker for you, then it's not the right phone for you.
The convenience of the built in battery with the much smaller size and bigger capacity per size (I realise there are longer batteries) outweighs the fact that when it does need replacing I need to go to an Apple store and swap it out, or send it off for a few days for replacement.
YMMV.
I'm not going to argue about tethering. The IPhone can't do it, unless you Jailbreak it. And I spoke already about Jailbreaking.
As for nav apps, I just looked. TomTom is $70!!! Holy crap. Nominal fee my butt. Which brings me back to my original premise about Google providing *free* nav.
For 3, are you reading what you are writing? You have to wait a few days for them to *mail* you your phone to get a simply battery? It keep getting worse! You mean I can't get it done that day at the store? And to your refurb point, no, I don't trust a refurb *anything* to be better than new, or a device I take care of and keep in good condition. Just like those "certified pre-owned" cars right off lease, have you seen what people do to leases? (Hint: put regular in a car that requires super for the *life* of the car. Wow).
You can get it done in the store if you like - but the mail in option is also there. They'll send you a prepay box if you don;t have a store near you or you don;t want to make the trip. The options are there, but it is clearly a more compromised setup than a user-removable battery - it's the compromise you pay for the smaller form factor.
The iPhone can't tether (without fees) *in the US* - everywhere else the iPhone is sold, it does. I can tether with mine *right now* and have been able to since I bought it with no fees and no jailbreaking. So, saying that "it cannot tether" is simply false.
The TomTom app is crazily expensive - I was so looking forward to it being released after the demo during the keynote, but then (after a much longer wait that suggested) they revealed the price, and the cost of the in-car mount, which is a further £90. The price for the app + car mount (which you really need since it charges your phone) is £150 in the UK, which is just stupid - it's more expensive than an actual TomTom satnav device and has drawn some serious ire from users expecting it to be more sensibly priced.
There are other turn by turn apps on the iPhone that are much cheaper - TomTom is the most expensive by far, but no free ones. The google one on Android looks excellent, and is the first compelling app I have seen that is making me consider a change of phone when my contract is up. It's an excellent selling point, which is why we're unlikely to see it on the iPhone from Google.
Incidentally, Apple refurbs are a little different - they are all either product returns, repaired units or unsold stock. Every refurb goes through an intensive test and QA process - they are better tested and checked than their new stock (the bulk of which are not tested before sale). You are not limited to taking a refurb though, you can keep your original phone, but have to deal with the extra time it takes for them to send it back to you, or have to wait in store/collect later depending on hours. Apple's refurbs are not "rental cars" - anything that isn't as good as new is simply discarded.
(also, in the UK there is no "regular" and "super" - only super)
I have never heard of zoolib before, does it support printing in a platform independent manner? That is a biggie for me.
GL is short for Graphics Library. It's what we call an abbreviation.
DirectX or Directx; IPhone or Iphone - both are fine, and I don't really care between them. But both are proper nouns, and the first letter of proper nouns in English is capitalised. Not that I even said "Iphone" in my post, so I guess I've got some sad stalker.
I don't follow my own rules, I follow the rules of basic English. Nowhere have I claimed that proper nouns "have no other capital letters", so you can take your straw man elsewhere.
But as I say, that argument applies to DirectX at least as much as OpenGL.
And sure, the latest versions of OpenGL and DirectX won't be suited to almost decade old hardware ... I'm not sure that's really a problem though.