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?"
do we want to start holding a Microsoft OS up as an example of something done *right*?
yes
otherwise you're blind.
Smile, don't click...
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.
Do you mean JAWS? Because that would make sense.
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
Who is JWZ?
John William Zoidberg?
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.
Indeed you are right, LOL at glBegin !
Just like with the Jews.
And why should we care?
See title
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
DirectX 2 was released in 1996. Which is kind of 15 years ago except it's only 14 and that it's DirectX but not OpenGL.
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]
Their list of applications that use zoolib is suspiciously short - only three links, of which two are broken, and the third is a web app.
As far as I can remember from when I did some Windows CE hacking, that's actually worse than the difference between Windows CE and standard Windows.
Wow.
Gentoo Sucks
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.
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).
"I'm all for criticising the iPhone's genuine faults"
No you're not, you're one of the biggest fanboys going. You couldn't see an iPhone fault if your iPhone blew up in your face.
Which is a possibility I suppose, thanks to Apple's crappy engineers ensuring that has actually happened to some people.
You're one of those idiots who owes a company nothing but would gladly support the DRM, child labour, and other general rapery that the company is heavily involved in simply because their fancy little UI animations give you a hard on.
To give you an example of why you are wrong, take a look at the likes of the .NET compact framework to see that an API for mobile devices doesn't have to be so horrendously different from the desktop API that you have to pretty much re-write large swathes of your application.
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?
You are 100% correct. So let's end the Apple myth. I see all these planted and biased reviews, and I can't take it. They're just garbage and they're feeding the Apple image, which frankly isn't true. I recently used both phones for a month (not 2 days like most reviewers). Let me precede that both are pretty darn good. But the IPhone isn't better. All the good stuff, and that which is moving ideas forward is on Android. Here are my findings as to what is better about each over the other:
IPhone
1. Appearance of "smoothness." Notice I said "appearance." They're both just as quick, it's just that the IPhone has better visual animations in the interim to distract you to make you think that's its immediate. It's really not as quick as you think between actions.
2. Touch screen works the way you think. This feature isn't better, only different. Once you get used to either phone, it doesn't matter. With the IPhone, when you press something, adjusts to where you really think you're pointing, whereas in Android, it's where your finger actually rests and makes contact with the capacitive screen.
Android
1. Probably the most amazing and useful feature ever in a phone--auto synchronization between Gmail, Google calendar, contacts, and photos. Yes blah blah Mobile Me. Well Google is free--Apple is $100/yr. 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.
2. Free turn-by-turn GPS. Killer feature here. Saves you like $15/mo for navigation. That's big. And I could never justify 15/mo when I could navigate myself with Mapquest. Well now that I use it, it's amazing, and I still can't justify the 15/mo for it, but I can justify getting an Android phone over Apple for it.
3. Free tethering. This feature is huge. You're paying for a data plan either way, but at least with Android you don't need to shell out another 60 per month for a wireless cell service just because Apple says "Because I say so."
4. Higher resolution. Makes text to much more readable and the difference in image quality is like night and day between the two.
5. The ability to use it as a mass storage device, with a removable Micro SD card. Droid has 16gb worth to store.
6. User-replaceable battery. No $60 rip-off price and driving to an Apple store to get a new battery installed. And tell me this, one day your IPhone will freeze. Not if, but when (all software does). Do you want to be out a few days just to gain use of your phone when it won't restart via software? When with Android, all you have to do is pull the battery out? This one is a scary demerit for Apple.
7. I can install what I want. I'm not told I can't use tethering. Killer features then the IPhone doesn't have: tethering and VoIP (and I mean on a cell network, NOT over wifi--wifi is useless if you're out of your house, and NO I'm not going to travel to Starbucks to use VoIP, no matter how plentiful they are).
8. Finally, the last game changer and killer feature Android has over the competition: voice to text translation, in all fields (especially text messages). I've never seen a voice-to-text program since the early 90s that actually worked well. I can't believe it, but Google's does. I barely even use the keyboard when sending texts anymore.
And to address all the "b-b-but !", no, Jailbreaking is NOT a solution. It just isn't. The average person doesn't know how to do it, the average person technically inclined who actually has a job can't be bothered, and I'm not voiding my warranty or preventing myself from getting updates for it.
As you can see, the baseline of each phone is pretty equal. But the only features that the IPhone excels at are weak. Androids superior features are pretty much game changers. I only hope that at least some people read this to know how the products REALLY compare.
Go ahead now, mod me down into oblivion.
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".
This is true of Windows desktop as well.
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.
Your analogy only holds up if you assume that there are no public roads, and that Audi/BMW has a contract with the owners of the roads which prohibits you from using the car on the roads if you've made any un-approved aftermarket changes.
"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!"
Of course, Apple's new policy (which everyone assumes is aimed at Flash, which God Help Us is the new Java) is to ban any app from their store not written using Apple's own iPhone development toolkit, so this would theoretically be disallowed.
"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
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
no shit, have two views (one for the old number, one for the new number), create an animation transaction, remove the old view, add the new view, and commit the transaction. That's it. If you need more control, you can use Core Animation (it might require 20 lines instead of 10).
If you disagree, post a rebuttal instead of wasting your mod points.
I speak as someone who develops for windows platforms on a daily basis at work and yet I choose to run a mac at home and I own an iPhone. Some of my co-workers that work in QA also own macs at home.
Jesus was a compassionate social conservative who called individuals to sin no more.
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.
// This creates a bitmap
CGContextRef CGBitmapContextCreate (
void *data,
size_t width,
size_t height,
size_t bitsPerComponent,
size_t bytesPerRow,
CGColorSpaceRef colorspace,
CGBitmapInfo bitmapInfo
);
This creates an image from the bitmap.
CGImageRef CGBitmapContextCreateImage (
CGContextRef c
);
This draws the image to the what ever context (ie: Screen, PDF, another bitmap, etc...) you want.
void CGContextDrawImage (
CGContextRef c,
CGRect rect,
CGImageRef image
);
All three of these are on both the iPhone and Mac OS X
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.
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
or you suddenly loose control on the car
Most cars exist for the very purpose of the driver loosing his control upon the vehicle.
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.
He originated that brilliantly insightful quote, leading the wave of Linux users who dumped that piece of shit operating system for OS X, which *just works*. Thank god for JWZ!
He was the first to vocalize what we all knew, that "free" software is not really worth the time and effort put into it. "Open Source" and "free software" are an outdated and dying development model that really does not reflect the way a real developer such as JWZ works. This is why the only people still using Linux are those that have bought into the Richard Stallman religion known as "freetardism".
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.
So basically the author of the post was using old APIs, and got burned?
He was whining on about PICT data types! PICT!!!!
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!
Hrm... It looks like ZooLib hasn't moved forward in some time. I'd looked at it a while back, but there are no menus under Linux, so ended up passing on it for wxWidgets instead.
I had a quick look at it today. No screenshots on the site, and the x86 samples refused to unzip.
"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.
"In 1991, I (Jamie Zawinski) re-implemented it from scratch for X Windows on Unix."
"X Windows"???
Seriously WTF!?
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.
BMW allows you to buy aftermarket parts which don't void the warranty a la DINAN, HARTKE, etc. Most high performance vehicles have a way that you can modify them to exceed normal operating limits without voiding the warranty.
It's even better if you imagine they're both wearing monocles.
Looks like this (my) comment in this form is invisible to anyone but me, unless you already know the exact comment URL.
and they don't claim cross platform comparability either.
It's an UI
Wow... do you actually say "ooey" when verbally referring to "you-eyes"? Because, that's, like, kinda weird. :)
I have a bitmap. I want to put it on the screen, fast, using two whole colors. And the colors change some times. This should be fucking trivial, right? Oh, ho ho ho.)
You know what? It is fucking trivial. And it is fucking cross platform. Use a CGImageMask. All the CG* code I've written works on iPhone and OS X with no changes (other than OS X being flipped).
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.
Correction:
Directx and Opengl
Consistency, my dear. If it's Iphone because proper nouns always begin with a capital letter and have no other capital letters, then follow your own rules.
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.
I have never heard of zoolib before, does it support printing in a platform independent manner? That is a biggie for me.
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".
Citation, please. Pulling bullshit imaginary scenarios out of your anus isn't evidence.
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.
GL is short for Graphics Library. It's what we call an abbreviation.
The rules of English don't allow for abbreviations mid-word.
DirectX or Directx; IPhone or Iphone - both are fine, and I don't really care between them.
But you do. You write DirectX consistently, because oddly enough, you know its name. The rules of English permit capital letters only at the beginning of words or in proper names, which are written as officially named.
But both are proper nouns, and the first letter of proper nouns in English is capitalised.
No. Proper nouns are usually capitalized. Proper names are always written in their official form. MacAllister is an invalid English word, but it's a proper name, so it is written 'MacAllister'. When you see "de Haviland" you write it exactly like that, because it's a proper name. It's not 'De Haviland' The official name in English of the Netherlands is 'the Netherlands' and not "The Netherlands".
I don't follow my own rules, I follow the rules of basic English
No you don't. You follow your made-up rules and apply them exclusively to products from a single source, in some sad act of derision no more tolerable than asshats who write M$.
Nowhere have I claimed that proper nouns "have no other capital letters",
You claim to follow the rules of basic English. Basic English designates a single place for capital letters: position one in the word. Basic English requires that words be separated by spaces. OpenGL, which you have no problem writing, violates this rule. It must be Open GL. But you don't write that, because you're stupid, but you're not stupid.
you can take your straw man elsewhere.
The only straw man is that proper usage of English ever requires an intentional misspelling of a formal name.