Wow, I can see I've been away for a LONG time, and to add to that, I'm going to be away for a couple of more weeks! It was a busy term with all sort of new things (and a lot of usual stuff) happening at professional and personal fronts, so I didn't get to do much writing, and not much testing and exploring with my MBP. I have been using it regularly and comparing it with PCs but not much of new things to report.
I'm going away for holidays to Australia so that means again not blogging until I'm back but I have some plans for new year which includes more OS and apps comparison and also talking about other operating systems (Linux and Android) and devices (tablets, phones, etc). So stay tued and you'll hear from me soon in new year.
For now, here is a super cool tool I found for Mac:
http://www.ommwriter.com
It's a "zen" tool for text editing ;-)
Sunday, December 12, 2010
Tuesday, October 19, 2010
#27 and #28
I'm not really sure when I can get to do some work on the article management systems I so want to compare. They are particularly important to me as a researcher/scientist but this term is so busy with a lot of projects that I don't get to work on anything other than the school stuff.
Anyway, some friends sent me these links (reviews for Windows and Mac OSX) which I thought I'd share here:
21st century guide to platform trolling: Apple
21st century guide to platform trolling: Windows
I'LL BE BACK!
Anyway, some friends sent me these links (reviews for Windows and Mac OSX) which I thought I'd share here:
21st century guide to platform trolling: Apple
21st century guide to platform trolling: Windows
I'LL BE BACK!
Sunday, October 3, 2010
#25 and #26
There hasn't been much going on these days to report. I haven't had the chance to work on my latest project (paper/article management tools). I did try to run a couple of tools on VMWare Fusion though and had trouble. Web.alive is a web-based tool for virtual environments based on Unreal engine. It's not available for Mac and won't work well on VMWare. Also, I use Allegro for graphics programming in C and it doesn't work with VMWare (but it has Mac version).
On another note, I'm starting to hate OpenOffice. It certainly isn't 100% compatible with MS Office. Somethings like comments and change tracking won't work, paragraph settings and even bullets/numbers are annoying, and it doesn't open some Office files!
Anyway, that's it for now.
I'LL BE BACK!
On another note, I'm starting to hate OpenOffice. It certainly isn't 100% compatible with MS Office. Somethings like comments and change tracking won't work, paragraph settings and even bullets/numbers are annoying, and it doesn't open some Office files!
Anyway, that's it for now.
I'LL BE BACK!
Monday, September 20, 2010
Sunday, September 12, 2010
Sunday, September 5, 2010
#22
I'm working on some document/paper management tools for Mac and PC but no report yet. It'll be the topic for next week.
I'LL BE BACK!
I'LL BE BACK!
Sunday, August 29, 2010
#21, The Ultimate Geek Guide to NYC
I love New York! I know it probably sounds kinda corny or cliche but it's true. I was there from Aug 21st to 29th (with a 2-day excursion to Boston in the middle). It wasn't my first time in NYC and I had done some of the typical tourist things, so when thinking about my plans I said to myself that I should check out some "other" sides of the city. After all, the "city that never sleeps" has something to offer for anyone. I read some of the travel guides online but found most of them very "touristy". Being kind of a geek (and proud of that :-) I wanted to see things that would particularly interest me, like techie stuff, games, comics, etc. So I looked for that type of info online and tried to collect them and make my own geeky itinerary. And I ended up with The Ultimate Geek Guide to NYC (or at least the version 0.9 of it).
You may ask what's that got to do with the PC User in the Mac World. Short answer: nothing. A little longer answer: it'll mention Apple store! But the real answer is that I wanted to diversify the blog and make it more than just a comparison list of features. It's a conversation and I'm not going to limit it as long as it stays within the general topic of information technology and culture.
One quick point: NYC includes five boroughs: Manhattan, Bronx, Brooklyn, Queens, and Staten Island. But when people say "the city" they mean Manhattan and that's what I'm talking about here. One night I went to a German-style pub/restaurant in Brooklyn (in a recently popular area called Williamsburg), and that was my only off-Manhattan experience (and of course trips to Boston and Newark airport in New Jersey).
Anyway, here is what I have to say to fellow geeks going to NYC:
NYC is the model for Gotham City. The head offices for DC and Marvel comics are there and many comic artists call it home. In a way it's one of the best places on earth for comic lovers. And the comics are the origin of many other interactive and non-interactive types of art and entertainment, including of course video games. So that's where I started. You will find plenty of places in NYC to explore if you like comics. I'm going to mention only a few that I visited and are probably the best in town.
* Forbidden Planet on Broadway and 13th Street is one of the most famous ones. It is a rather fancy place with all sort of collectibles, T-shirts and toys, and new publications. You may not find many old and non-mainstream stuff there, though. Still it's a must see.
* Midtown Comics on 200 West 40th, just off 7th Avenue and close to Times Square is probably the biggest comic shop in NYC. It has a very good collection of all sort of stuff (even some "adult" titles), also toys and collectibles on two floors. Since everybody visiting NYC should and will go to Times Square, a trip to MC is easy and necessary. They have other branches too but I didn't go.
* Jim Hanley’s Universe on 33rd Street, across from the Empire State Building is a less-known but worth-visiting place, especially if you are looking for older items, but not toys and collectibles. For the pervert in you, the adult section will be interesting as well ;-)
* Time Machine on 207 West 14th Street (14th & 7th Avenue) is the place for older comics, both buying and trading.
* St. Marks Comics on 11 St. Mark’s Place in the East Village (between 2nd and 3rd Avenue) is a small and typical comic shop but you should go there because it is in the heart of East Village and that is the place to go if you want to have fun! St. Mark's Place is basically East 8th Street east of 3rd Avenue. The neighbourhood used to be for junkies in the old days, but it's the party place right now. It still has a hippie funky atmosphere that makes it different from West Village, another party place but more traditional and typical North American, and of course fancier. I like East Village more but West Village is cool too
* Museum of Comic & Cartoon Art located on the fourth floor at 594 Broadway, between Houston and Prince Streets is a rather unknown gem. It's small but has a good set of examples from comics to comic strips and New Yorker style cartoons. Absolute must see!
After comics, the next category of places to check out is game-related.
* Nintendo Store at Rockefeller Plaza is the obvious first. From life-size game characters to collection of old Nintendo consoles, you'll find a lot to see. You may buy some T-shirts too. I did!
* Video Games New York on 206 E. 6th Street, off Cooper Square and close to St. Mark's Place, is another small but great place. Another reason why you should go to East Village. You will find all sort of old hardware and games in this little place, sure to make you feel good and a little nostalgic.
* Dave & Buster’s, 234 West 42nd Street (between 7th and 8th Avenue), is a pub by Times Square right in the middle of theatres. It has a big game section and supposedly not bad food (I didn't try). After seeing a show or film, you can go there, eat and drink, and play some games.
* GameStop is probably the biggest chain of game stores in NYC. They are everywhere and nothing special about them!
Some of the other geeky stores you need to check out are:
* Apple Store in Upper West Side, 1981 Broadway (at West 67th Street) and the one midtown on 5th Avenue (at East 58th). The glass cube is the big attraction obviously, so the downtown location is less recommended as it's just an Apple Store. I recommend the 5th Avenue location as it is just south of Central Park which itself is a must see (even if you have seen it, the park is a great hang-out place).
* The Wired Store on 15 West 18th Street (in Soho) is supposed to be a great place for all sort of electronic gadgets. Unfortunately it was closed when I went there. It's in Soho which is another great neighbourhood you must check out. South of Houston Street downtown, it used to be a low-class artzy area but now is full of fancy boutiques and stores and so expensive that young artists cannot afford it.
* Evolution Nature is a really cool store in Soho, 120 Spring Street, full of "evolution-themed" items, from fossils to skulls. If you like Darwin and make fun of Intelligent Design theory, you gotta go there :-)
* Hayden Planetarium in Rose Centre for Earth and Space, Central Park West at 81st Street, is another great place you should go. No need to say what you should expect to see there! It is part of the same complex as American Museum of Natural History with all the dinosaurs! Check them out both but expect a long line of kids in tourist seasons.
* Robot Village on 252 West 81 Street was another interesting store for electronics (and robots) but it's out of business now :-(
* If you can manage to go to Boston while staying in NYC, check out the MIT Museum. Boston is 3-4 hours from NYC by bus or train. It's a beautiful city with a rich history and an amazing mix of old and new architecture. Massachusetts Institute of Technology (MIT) is in Cambridge, part of Greater Boston and separated from the City of Boston by Charles River. MIT Museum is not big but has a nice collection of research done in MIT, such as robotics and holography (the ones that were the main exhibitions when I visited).
Last but not least, here are some less geeky and more traditional places that even a geek want to see:
* Museum of Modern Art (MOMA), 11 West 53rd Street (between 6th and 7th Avenue), is the number one art museum you need to go, if you want to learn about modern art. Be sure to check out MOMA Design Store, across the street or in Soho, for amazing products with great modern design, from kitchenware to lamps, etc.
* Guggenheim Museum, 1071 5th Avenue (at 89th Street), also has a focus on modern art and includes more recent and less famous works by contemporary artists.
* Metropolitan Museum probably doesn't need any introduction as every visitor to NYC is likely to have it on the itinerary. It has examples of artworks from almost any civilization that ever existed!
* Carnegie Hall, on 7th Avenue and West 56th Street, has high-class musical performances if you are into that kind of stuff.
* Max Brenner is probably the best chocolate shop in NYC (now is full restaurant). It is located at 841 Broadway (between 13th St & 14th St) in Union Square area. Try going there in the afternoons or other less-busy times as it can be very crowded.
This was my preliminary version of the Ultimate Geek Guide to NYC. Hopefully I can make it better soon. To make this post a little more related to the whole PC-Mac discussion, I'd like to add one thing: I really don't like iPhoto which is a very inconvenient photo gallery software with the annoying need to import/export files and lack of ability to structure your albums. On a second thought, I'd like to add another thing: My MBP screwed up some of my photos. I attached my USB card reader and it wasn't detected. I disconnected it and got a message saying I'd better eject first! Well there was nothing to eject. To make things worse, I checked my photos and many of them were damaged (I know they were ok because I had checked them on the camera before).
Well, it's enough for this week. Stay tuned for more.
I'LL BE BACK!
You may ask what's that got to do with the PC User in the Mac World. Short answer: nothing. A little longer answer: it'll mention Apple store! But the real answer is that I wanted to diversify the blog and make it more than just a comparison list of features. It's a conversation and I'm not going to limit it as long as it stays within the general topic of information technology and culture.
One quick point: NYC includes five boroughs: Manhattan, Bronx, Brooklyn, Queens, and Staten Island. But when people say "the city" they mean Manhattan and that's what I'm talking about here. One night I went to a German-style pub/restaurant in Brooklyn (in a recently popular area called Williamsburg), and that was my only off-Manhattan experience (and of course trips to Boston and Newark airport in New Jersey).
Anyway, here is what I have to say to fellow geeks going to NYC:
NYC is the model for Gotham City. The head offices for DC and Marvel comics are there and many comic artists call it home. In a way it's one of the best places on earth for comic lovers. And the comics are the origin of many other interactive and non-interactive types of art and entertainment, including of course video games. So that's where I started. You will find plenty of places in NYC to explore if you like comics. I'm going to mention only a few that I visited and are probably the best in town.
* Forbidden Planet on Broadway and 13th Street is one of the most famous ones. It is a rather fancy place with all sort of collectibles, T-shirts and toys, and new publications. You may not find many old and non-mainstream stuff there, though. Still it's a must see.
* Midtown Comics on 200 West 40th, just off 7th Avenue and close to Times Square is probably the biggest comic shop in NYC. It has a very good collection of all sort of stuff (even some "adult" titles), also toys and collectibles on two floors. Since everybody visiting NYC should and will go to Times Square, a trip to MC is easy and necessary. They have other branches too but I didn't go.
* Jim Hanley’s Universe on 33rd Street, across from the Empire State Building is a less-known but worth-visiting place, especially if you are looking for older items, but not toys and collectibles. For the pervert in you, the adult section will be interesting as well ;-)
* Time Machine on 207 West 14th Street (14th & 7th Avenue) is the place for older comics, both buying and trading.
* St. Marks Comics on 11 St. Mark’s Place in the East Village (between 2nd and 3rd Avenue) is a small and typical comic shop but you should go there because it is in the heart of East Village and that is the place to go if you want to have fun! St. Mark's Place is basically East 8th Street east of 3rd Avenue. The neighbourhood used to be for junkies in the old days, but it's the party place right now. It still has a hippie funky atmosphere that makes it different from West Village, another party place but more traditional and typical North American, and of course fancier. I like East Village more but West Village is cool too
* Museum of Comic & Cartoon Art located on the fourth floor at 594 Broadway, between Houston and Prince Streets is a rather unknown gem. It's small but has a good set of examples from comics to comic strips and New Yorker style cartoons. Absolute must see!
After comics, the next category of places to check out is game-related.
* Nintendo Store at Rockefeller Plaza is the obvious first. From life-size game characters to collection of old Nintendo consoles, you'll find a lot to see. You may buy some T-shirts too. I did!
* Video Games New York on 206 E. 6th Street, off Cooper Square and close to St. Mark's Place, is another small but great place. Another reason why you should go to East Village. You will find all sort of old hardware and games in this little place, sure to make you feel good and a little nostalgic.
* Dave & Buster’s, 234 West 42nd Street (between 7th and 8th Avenue), is a pub by Times Square right in the middle of theatres. It has a big game section and supposedly not bad food (I didn't try). After seeing a show or film, you can go there, eat and drink, and play some games.
* GameStop is probably the biggest chain of game stores in NYC. They are everywhere and nothing special about them!
Some of the other geeky stores you need to check out are:
* Apple Store in Upper West Side, 1981 Broadway (at West 67th Street) and the one midtown on 5th Avenue (at East 58th). The glass cube is the big attraction obviously, so the downtown location is less recommended as it's just an Apple Store. I recommend the 5th Avenue location as it is just south of Central Park which itself is a must see (even if you have seen it, the park is a great hang-out place).
* The Wired Store on 15 West 18th Street (in Soho) is supposed to be a great place for all sort of electronic gadgets. Unfortunately it was closed when I went there. It's in Soho which is another great neighbourhood you must check out. South of Houston Street downtown, it used to be a low-class artzy area but now is full of fancy boutiques and stores and so expensive that young artists cannot afford it.
* Evolution Nature is a really cool store in Soho, 120 Spring Street, full of "evolution-themed" items, from fossils to skulls. If you like Darwin and make fun of Intelligent Design theory, you gotta go there :-)
* Hayden Planetarium in Rose Centre for Earth and Space, Central Park West at 81st Street, is another great place you should go. No need to say what you should expect to see there! It is part of the same complex as American Museum of Natural History with all the dinosaurs! Check them out both but expect a long line of kids in tourist seasons.
* Robot Village on 252 West 81 Street was another interesting store for electronics (and robots) but it's out of business now :-(
* If you can manage to go to Boston while staying in NYC, check out the MIT Museum. Boston is 3-4 hours from NYC by bus or train. It's a beautiful city with a rich history and an amazing mix of old and new architecture. Massachusetts Institute of Technology (MIT) is in Cambridge, part of Greater Boston and separated from the City of Boston by Charles River. MIT Museum is not big but has a nice collection of research done in MIT, such as robotics and holography (the ones that were the main exhibitions when I visited).
Last but not least, here are some less geeky and more traditional places that even a geek want to see:
* Museum of Modern Art (MOMA), 11 West 53rd Street (between 6th and 7th Avenue), is the number one art museum you need to go, if you want to learn about modern art. Be sure to check out MOMA Design Store, across the street or in Soho, for amazing products with great modern design, from kitchenware to lamps, etc.
* Guggenheim Museum, 1071 5th Avenue (at 89th Street), also has a focus on modern art and includes more recent and less famous works by contemporary artists.
* Metropolitan Museum probably doesn't need any introduction as every visitor to NYC is likely to have it on the itinerary. It has examples of artworks from almost any civilization that ever existed!
* Carnegie Hall, on 7th Avenue and West 56th Street, has high-class musical performances if you are into that kind of stuff.
* Max Brenner is probably the best chocolate shop in NYC (now is full restaurant). It is located at 841 Broadway (between 13th St & 14th St) in Union Square area. Try going there in the afternoons or other less-busy times as it can be very crowded.
This was my preliminary version of the Ultimate Geek Guide to NYC. Hopefully I can make it better soon. To make this post a little more related to the whole PC-Mac discussion, I'd like to add one thing: I really don't like iPhoto which is a very inconvenient photo gallery software with the annoying need to import/export files and lack of ability to structure your albums. On a second thought, I'd like to add another thing: My MBP screwed up some of my photos. I attached my USB card reader and it wasn't detected. I disconnected it and got a message saying I'd better eject first! Well there was nothing to eject. To make things worse, I checked my photos and many of them were damaged (I know they were ok because I had checked them on the camera before).
Well, it's enough for this week. Stay tuned for more.
I'LL BE BACK!
Monday, August 23, 2010
Sunday, August 15, 2010
Sunday, August 8, 2010
#18, Customization
Let me start by telling you what was the reason behind the topic for this week. First, when I discussed the games for Mac last week, I mentioned the lack of choices for graphics card and we had some discussions on Facebook about that and also audio devices. Second reason was related to Centretown Movies Outdoor Film Festival (centretownmovies.org) that I help organize. Last Friday was our first night this year. Our DVD player failed. I brought my Linux laptop and it couldn't play the encrypted DVD (later I installed VLC and got rid of Totem player which didn't work well even after I installed the decryption stuff). I tried to use my MacBookPro but I had forgotten my DisplayPort-to-VGA adaptor and couldn't connect to the projector. Together, these made me think about the whole issue of customization for hardware and software on Mac. But before I go ahead, that night we borrowed a Windows laptop and showed our film, and the next day when I had the adaptor I couldn't get my MBP to detect the projector and so used the Windows on my MBP to show the movie!
Now let's see what exactly I mean by customization. Simply said, it is the user's ability to change hardware and software features. Customization comes with choices and flexibility, and usually goes against simplicity as it can cause different ways of doing things and a more complex experience. Being able to customize, i.e. changing your computer from its default factory setting, also can affect the stability and performance as the system is no longer optimized for a certain configuration known to the manufacturer and OS designer. PCs were originally made by IBM. At that time, IBM PC was kinda like Mac computers because everything was designed (or at least put together) by the same company. But IBM clones changed everything so PCs became very different. This meant cheaper and more customizable hardware and software but at the same time less reliable and stable. This trend has continued to this day, although with some changes.
Macs claim to be very easy to use and stable. To some degrees, this is correct. If the hardware is good enough for what you want to do, and you do typical stuff the way Apple people have in mind, then things are pretty straight-forward. But when you get to changing things, you'll see the problems. PCs on the other hand were on the other side of the spectrum. You could change any hardware component and OS was more customizable, from installing drivers to changing system settings. But that made them harder to work with. Both systems have tried to get closer to a middle ground. Macs allow you to have some limited hardware options and do let you configure your computers (especially if you are a little geeky and can use Unix-based text commands at a terminal window), and Windows is trying to become more friendly by "guessing" things for you. A simple example of this trend in Windows can be seen by comparing Windows Explorer from XP to Win7. It used to have the options of customizing toolbar, and all sort of folder options. Now it sets them based on the types of files in the folder which can be good for less techie users but I find annoying as I like to customize them the way I want.
Anyway, here is a quick look at hardware and software customization issues for Mac and OSX.
Hardware
========
There is really not much to say about this, as it's pretty clear. Some things to note are:
1- You have very limited choices for hardware component. This has become less of a problem considering that Apple is using high-end components like NVIDIA graphics and fast HDDs, but still you face problems such as need for a professional graphics card or audio system, updating your removable disk drive or other parts when new technology comes, adding/changing RAM modules, and CPU upgrade.
2- It is difficult, if not impossible, to use specialized hardware like Analog-to-Digital or other peripheral cards unless designed specifically for Mac.
3- The video out is DisplayPort (not VGA or even DVI or HDMI) and you need an adaptor to connect to common monitors and projectors. Apple claims that this is because VGA is an old standard and DisplayPort is much better. What they don't talk about is "what if you don't want it?" Nobody else seems to be using it, even DVI and HDMI are not that popular yet, and you are stuck with no ability to change.
Software
========
It is true that you can customize a lot of things on a Mac. If you go to System Preferences, you'll see a lot of options. There are also good amount of tricks to change things that are not directly visible there. Here are a few good websites that discuss such tricks:
Apple: Mac101
MacWorld: Customize your Mac
MacGeekery: Customization
Custom Mac
Does this mean OSX is customizable enough, or customizable without much difficulty? No. Here are some things I don't like about OSX when it comes to system configuration:
* My most disliked part of OSX, the Finder. There is not enough customization for the way you view your files and folders. If you go to Get Info for a file, you can set some options like Icon and Showing Extension for that file or files of the same type. But not much more. Things like customizing toolbar and adding/removing the separate tree view pane don't exist. Folder Options are non-existent or hard to set.
* System sounds have more restricted options compared to Windows that allows you to set all the sounds even with your own audio files.
* Display details are hard to change. Advanced settings on Windows, especially the control panel provided by hardware manufacturer, allow you to control much more such as colour setting, 3D parameters, etc.
* Firewall and internet settings are limited in System Preferences, for example allowing or denying access for specific programs.
* Disk Utility doesn't seem to have tools like defragmentation and optimization.
* Last but not least, as we can expect, there is no Device Manager as we have in Windows that allows you to control your devices at low level.
On the other hand, the Unix-based nature of OSX allows you to use typical text commands at terminal to control a lot of things but I haven't really tried that yet. So there are more to say.
I'LL BE BACK!
Now let's see what exactly I mean by customization. Simply said, it is the user's ability to change hardware and software features. Customization comes with choices and flexibility, and usually goes against simplicity as it can cause different ways of doing things and a more complex experience. Being able to customize, i.e. changing your computer from its default factory setting, also can affect the stability and performance as the system is no longer optimized for a certain configuration known to the manufacturer and OS designer. PCs were originally made by IBM. At that time, IBM PC was kinda like Mac computers because everything was designed (or at least put together) by the same company. But IBM clones changed everything so PCs became very different. This meant cheaper and more customizable hardware and software but at the same time less reliable and stable. This trend has continued to this day, although with some changes.
Macs claim to be very easy to use and stable. To some degrees, this is correct. If the hardware is good enough for what you want to do, and you do typical stuff the way Apple people have in mind, then things are pretty straight-forward. But when you get to changing things, you'll see the problems. PCs on the other hand were on the other side of the spectrum. You could change any hardware component and OS was more customizable, from installing drivers to changing system settings. But that made them harder to work with. Both systems have tried to get closer to a middle ground. Macs allow you to have some limited hardware options and do let you configure your computers (especially if you are a little geeky and can use Unix-based text commands at a terminal window), and Windows is trying to become more friendly by "guessing" things for you. A simple example of this trend in Windows can be seen by comparing Windows Explorer from XP to Win7. It used to have the options of customizing toolbar, and all sort of folder options. Now it sets them based on the types of files in the folder which can be good for less techie users but I find annoying as I like to customize them the way I want.
Anyway, here is a quick look at hardware and software customization issues for Mac and OSX.
Hardware
========
There is really not much to say about this, as it's pretty clear. Some things to note are:
1- You have very limited choices for hardware component. This has become less of a problem considering that Apple is using high-end components like NVIDIA graphics and fast HDDs, but still you face problems such as need for a professional graphics card or audio system, updating your removable disk drive or other parts when new technology comes, adding/changing RAM modules, and CPU upgrade.
2- It is difficult, if not impossible, to use specialized hardware like Analog-to-Digital or other peripheral cards unless designed specifically for Mac.
3- The video out is DisplayPort (not VGA or even DVI or HDMI) and you need an adaptor to connect to common monitors and projectors. Apple claims that this is because VGA is an old standard and DisplayPort is much better. What they don't talk about is "what if you don't want it?" Nobody else seems to be using it, even DVI and HDMI are not that popular yet, and you are stuck with no ability to change.
Software
========
It is true that you can customize a lot of things on a Mac. If you go to System Preferences, you'll see a lot of options. There are also good amount of tricks to change things that are not directly visible there. Here are a few good websites that discuss such tricks:
Apple: Mac101
MacWorld: Customize your Mac
MacGeekery: Customization
Custom Mac
Does this mean OSX is customizable enough, or customizable without much difficulty? No. Here are some things I don't like about OSX when it comes to system configuration:
* My most disliked part of OSX, the Finder. There is not enough customization for the way you view your files and folders. If you go to Get Info for a file, you can set some options like Icon and Showing Extension for that file or files of the same type. But not much more. Things like customizing toolbar and adding/removing the separate tree view pane don't exist. Folder Options are non-existent or hard to set.
* System sounds have more restricted options compared to Windows that allows you to set all the sounds even with your own audio files.
* Display details are hard to change. Advanced settings on Windows, especially the control panel provided by hardware manufacturer, allow you to control much more such as colour setting, 3D parameters, etc.
* Firewall and internet settings are limited in System Preferences, for example allowing or denying access for specific programs.
* Disk Utility doesn't seem to have tools like defragmentation and optimization.
* Last but not least, as we can expect, there is no Device Manager as we have in Windows that allows you to control your devices at low level.
On the other hand, the Unix-based nature of OSX allows you to use typical text commands at terminal to control a lot of things but I haven't really tried that yet. So there are more to say.
I'LL BE BACK!
Sunday, August 1, 2010
#17, Myths about Macs & Games
Last week StarCraft 2, the latest RTS game from Blizzard, was released. I naturally bought it and installed it on both Windows and OSX. I said "naturally" because I teach game design and am quite passionate about game technology. I think what we call "video game" is the foundation of a lot of other things in near future, including storytelling, education, simulation, and of course entertainment. I try to get people, particularly my students, interested in games and how they can be designed better and be used for various purposes. My academic research is mostly about how to make games more intelligent and immersive. But as much as I like to read about games and try new ones, I have to admit I'm not a big game player myself. I used to play more but these days I usually play a new game only enough to know what's new in it. That's one of the reasons I like game nights. I get to see levels that I usually don't explore myself!
Anyway, with that background one of my main concerns when starting to use a Mac was to see how good it was for playing games. If you are like me and have anything to do with Macs and games, you've probably heard two important things, or maybe I should say myths:
1- Macs and OSX are not powerful or graphically optimized enough to run high-end 3D games
2- There are very few games (especially among popular titles) available for Mac users
Until a short while ago, I did believe in both these myths. I no longer do. Well, not entirely.
(1) Game Performance
It cannot be denied that Macs have never been the ideal gaming platform. So there is some reality in that myth. There are different reasons for this performance problem, among them I'm sure are (a) inferior development tools and APIs, and (b) graphic cards that may not be ideal for 3D games. There is an interesting fact about Macs: Users are limited to certain hardware choices. There are some advantages to this such as relatively high-quality (but expensive) hardware, and an operating system that is optimized for the known hardware. Windows on the other hand is written for "unknown" hardware. This makes it less optimized and more unstable, but gives the users the chance to upgrade to high-end components such as better graphic cards.
Having mentioned those reasons, I have to say that probably the major reason for lower 3D graphics performance on Macs is the drivers. OpenGL is the core 3D technology on Mac and OpenGL drivers for Mac are less optimized than OpenGL and Direct3D drivers on Windows. See this review for some interesting comparisons that show Windows and even Ubuntu can outperform OSX in 3D graphics:
* Phoronix Graphics Comparison
So does this mean the myth #1 is correct? Maybe it was at some point but it's not anymore (lower performance doesn't mean unacceptable performance), or at least it's changing in favour of Macs. There are a few things causing this change:
1- Better hardware on newer Macs
2- Better OpenGL drivers and support as for example mentioned here:
ArsTechnica: Apple Moves to Improve OpenGL
3- Game developers efforts motivated by growing market, for example the release of Steam for Mac.
My own experience of playing Half-Life 2 and StarCraft 2 on Mac (both Windows and OSX) was generally positive. I did notice lower FPS but nothing too annoying. Here are some user reports confirming my observations:
* EveryMac
* ArsTechnica
* MacRumors: Windows Games On Mac
* MacRumors: Native Mac Games
One interesting point to consider is running Windows version of the games on Mac (using Bootcamp) as opposed to running native Mac version. As expected, the performance can be a little better on Windows in terms of quality and FPS, although better stability is being reported for Mac versions which goes back to general stability of OS due to its optimized nature for a known hardware. Here is another good article:
* ArsTechnica: Gaming Performance and Stability
So what's the verdict? As I said, I no longer think that Macs are too weak for high-end 3D games and apps. The myth is less true for hardware and closer to truth for native Mac software, but certainly not true, and in both cases the situation is improving in favour of Macs.
(2) Available Games
Many Windows users think that Mac games are limited to casual games like 2D puzzles, etc. This myth is completely wrong. There is no denying the fact that Windows gamers have a wider selection of games, but many popular 3D titles have Mac versions. Developers like Blizzard and Valve seem to be committed to releasing Mac version of their games, and we can be sure that the growing number of Mac users will mean more Mac games. Here are a couple of good sites to check out for Mac games:
* http://www.apple.com/games/
* http://en.wikipedia.org/wiki/Mac_games
* http://www.insidemacgames.com
And here is a very short list of some popular games that have Mac versions:
Age of Empires 1-3
Age of Mythology
BioShock
Black & White 1-2
Call of Duty 1-4
Civilization 3-4
Command and Conquer: Generals
Counter-Strike
Darwinia
Diablo and Diablo 2
Dragon Age: Origins
EVE Online
EverQuest
Fallout and Fallout 2
Guitar Hero (Aerosmith and Legends of Rock)
Half-life (series)
Halo: Combat Evolved
Harry Potter (some titles from the series)
Left 4 Dead
Max Payne
Medal of Honor: Allied Assault
Myst (some titles from the series)
Need for Speed: Carbon
Portal
Prince of Persia (2008 and some others)
Quake (series)
SimCity (series)
Sims (series)
StarCraft and StarCraft 2
Star Wars (various games)
Monkey Island (series)
Team Fortress 2
Tomb Raider: Anniversary
Toy Story 3
TRON 2
Unreal Tournament (series)
World of Goo
World of Warcraft
I'LL BE BACK!
Anyway, with that background one of my main concerns when starting to use a Mac was to see how good it was for playing games. If you are like me and have anything to do with Macs and games, you've probably heard two important things, or maybe I should say myths:
1- Macs and OSX are not powerful or graphically optimized enough to run high-end 3D games
2- There are very few games (especially among popular titles) available for Mac users
Until a short while ago, I did believe in both these myths. I no longer do. Well, not entirely.
(1) Game Performance
It cannot be denied that Macs have never been the ideal gaming platform. So there is some reality in that myth. There are different reasons for this performance problem, among them I'm sure are (a) inferior development tools and APIs, and (b) graphic cards that may not be ideal for 3D games. There is an interesting fact about Macs: Users are limited to certain hardware choices. There are some advantages to this such as relatively high-quality (but expensive) hardware, and an operating system that is optimized for the known hardware. Windows on the other hand is written for "unknown" hardware. This makes it less optimized and more unstable, but gives the users the chance to upgrade to high-end components such as better graphic cards.
Having mentioned those reasons, I have to say that probably the major reason for lower 3D graphics performance on Macs is the drivers. OpenGL is the core 3D technology on Mac and OpenGL drivers for Mac are less optimized than OpenGL and Direct3D drivers on Windows. See this review for some interesting comparisons that show Windows and even Ubuntu can outperform OSX in 3D graphics:
* Phoronix Graphics Comparison
So does this mean the myth #1 is correct? Maybe it was at some point but it's not anymore (lower performance doesn't mean unacceptable performance), or at least it's changing in favour of Macs. There are a few things causing this change:
1- Better hardware on newer Macs
2- Better OpenGL drivers and support as for example mentioned here:
ArsTechnica: Apple Moves to Improve OpenGL
3- Game developers efforts motivated by growing market, for example the release of Steam for Mac.
My own experience of playing Half-Life 2 and StarCraft 2 on Mac (both Windows and OSX) was generally positive. I did notice lower FPS but nothing too annoying. Here are some user reports confirming my observations:
* EveryMac
* ArsTechnica
* MacRumors: Windows Games On Mac
* MacRumors: Native Mac Games
One interesting point to consider is running Windows version of the games on Mac (using Bootcamp) as opposed to running native Mac version. As expected, the performance can be a little better on Windows in terms of quality and FPS, although better stability is being reported for Mac versions which goes back to general stability of OS due to its optimized nature for a known hardware. Here is another good article:
* ArsTechnica: Gaming Performance and Stability
So what's the verdict? As I said, I no longer think that Macs are too weak for high-end 3D games and apps. The myth is less true for hardware and closer to truth for native Mac software, but certainly not true, and in both cases the situation is improving in favour of Macs.
(2) Available Games
Many Windows users think that Mac games are limited to casual games like 2D puzzles, etc. This myth is completely wrong. There is no denying the fact that Windows gamers have a wider selection of games, but many popular 3D titles have Mac versions. Developers like Blizzard and Valve seem to be committed to releasing Mac version of their games, and we can be sure that the growing number of Mac users will mean more Mac games. Here are a couple of good sites to check out for Mac games:
* http://www.apple.com/games/
* http://en.wikipedia.org/wiki/Mac_games
* http://www.insidemacgames.com
And here is a very short list of some popular games that have Mac versions:
Age of Empires 1-3
Age of Mythology
BioShock
Black & White 1-2
Call of Duty 1-4
Civilization 3-4
Command and Conquer: Generals
Counter-Strike
Darwinia
Diablo and Diablo 2
Dragon Age: Origins
EVE Online
EverQuest
Fallout and Fallout 2
Guitar Hero (Aerosmith and Legends of Rock)
Half-life (series)
Halo: Combat Evolved
Harry Potter (some titles from the series)
Left 4 Dead
Max Payne
Medal of Honor: Allied Assault
Myst (some titles from the series)
Need for Speed: Carbon
Portal
Prince of Persia (2008 and some others)
Quake (series)
SimCity (series)
Sims (series)
StarCraft and StarCraft 2
Star Wars (various games)
Monkey Island (series)
Team Fortress 2
Tomb Raider: Anniversary
Toy Story 3
TRON 2
Unreal Tournament (series)
World of Goo
World of Warcraft
I'LL BE BACK!
Saturday, July 24, 2010
#16
This week's post is going to be relatively short. I didn't do a lot of testing but I've been using my MBP constantly and for doing non-professional everyday stuff, I find it pretty good especially because it boots, shuts down and starts applications faster than Windows. I've mentioned this before but I'd like to add some details.
When I first started using the MBP with fresh install of OSX and Windows, the OSX side would boot faster (about 40 seconds) while the Windows side was not much slower (about 70 seconds boot time). After a lot of apps and usage, my OSX still boots at the same time, but my Windows boot time is now more than 2 minutes!
The delay in Windows start-up may be related to another issue. When installing VMWare virtual machine, I was told that it may damage the Windows Activation files and vase the need to re-activate. It didn't happen immediately but did happen after a while. Windows detected non-genuine copy (incorrectly) and asked me to re-register using a license key. I was lucky that at school we have academic licenses and I could get a new one for free. But the problem happened for a second time last week and I did the same thing. This by itself is a problem but I also noticed that my Windows start-up is slower since the first time that error happened.
The next set of things I did last week was to install a bunch of apps for OSX. They are quite good and I thought it'd be a good idea to let readers know about them.
TotalFinder is an add-on to Finder. I really dislike Finder as I've said before. It is one of the main drawbacks of using OSX for even casual stuff. TotalFinder gives you tabbed mode and also listing folders at the top! It doesn't make Finder a good tool but it's an improvement. See post #14 for my complaints against Finder.
Miro Video Converter
Handbrake DVD Ripper
Seashore, simple Photoshop-like app
UnArchiver for RAR, ZIP, etc
Xee, a nice image viewer that is much better than Preview, kinda like Windows Image Viewer. If you open a file, you can browse through the next images in that directory. For Preview you have to select them all and then open with Preview.
Sixty Force and Nestopia are Nintendo64 and NES simulators.
For more see: http://bestmacsoftware.org/
I'LL BE BACK!
When I first started using the MBP with fresh install of OSX and Windows, the OSX side would boot faster (about 40 seconds) while the Windows side was not much slower (about 70 seconds boot time). After a lot of apps and usage, my OSX still boots at the same time, but my Windows boot time is now more than 2 minutes!
The delay in Windows start-up may be related to another issue. When installing VMWare virtual machine, I was told that it may damage the Windows Activation files and vase the need to re-activate. It didn't happen immediately but did happen after a while. Windows detected non-genuine copy (incorrectly) and asked me to re-register using a license key. I was lucky that at school we have academic licenses and I could get a new one for free. But the problem happened for a second time last week and I did the same thing. This by itself is a problem but I also noticed that my Windows start-up is slower since the first time that error happened.
The next set of things I did last week was to install a bunch of apps for OSX. They are quite good and I thought it'd be a good idea to let readers know about them.
TotalFinder is an add-on to Finder. I really dislike Finder as I've said before. It is one of the main drawbacks of using OSX for even casual stuff. TotalFinder gives you tabbed mode and also listing folders at the top! It doesn't make Finder a good tool but it's an improvement. See post #14 for my complaints against Finder.
Miro Video Converter
Handbrake DVD Ripper
Seashore, simple Photoshop-like app
UnArchiver for RAR, ZIP, etc
Xee, a nice image viewer that is much better than Preview, kinda like Windows Image Viewer. If you open a file, you can browse through the next images in that directory. For Preview you have to select them all and then open with Preview.
Sixty Force and Nestopia are Nintendo64 and NES simulators.
For more see: http://bestmacsoftware.org/
I'LL BE BACK!
Monday, July 19, 2010
Tuesday, July 13, 2010
#14, Summary 1
So I'm finally back home and can get to do my promised summary #1. But in case you are curious, let me tell what I was up to in the last two weeks. I went to Barcelona for a conference on educational technologies and methods to present our work on virtual educational environments (http://img.csit.carleton.ca/vcher). Barcelona without a doubt is one of my favourite destinations (see my Facebook album). The conference was also an interesting multidisciplinary forum. One thing that I found particularly interesting was that it's not just us in North America who try to make education "fun", and it reminded me of this thought I've been having for a while that we are probably going too far with this "do what you like" "try to have fun" idea for students (from kindergarten all the way up). That's not real life. It's good to have some fun when learning but it's not an educational requirement. What happened to joy of learning and achieving? Well, I'm going to post something on this topic some time soon. My next stop was Vancouver where I moved from 4 years ago, to attend a friend's wedding. I don't want to sound sad but nothing makes you remember you are alone and far from family more than going back for a wedding no matter how fun it is! Not to mention another unfortunate thing in such out-of-town weddings and that is meeting people you like who live far far away from you!
Anyway, I think I'm in situation to have an overall (maybe still preliminary) opinion of the whole Mac vs. PC topic. I'm going to write my #1 summary of evaluations grouped into 5 categories: Hardware, User Interface, General OS Operation, Applications, and Software Development. As we all could expect Mac and OSX don't get the same results on all categories and of course for all types of users, and I try to consider this "user type" matter in all categories.
Overall, I have to say I'm happy with my MacBook Pro. Except for playing Windows-only games, using Visual Studio (Windows development) and sometimes MS Office (because OpenOffice doesn't do all the Office functions), I hardly had to go to my Windows side. I have Photoshop only for Windows but I have Corel Painter on OSX and that usually does the typical jobs I have for Photoshop. There are all sorts of free apps for Mac. But we will talk about all these in details. One thing I can say now is that considering everything, I didn't find the computing experience superior in Mac, especially when we remember the price. Here is the tricky part though, because the experience "may" be superior for some types of users. Of course in some categories, particularly programming, the OSX experience has been without a doubt inferior. Let's go over categories before I try to make some conclusions. In each category, I group items into P (positive for OSX), N (negative for OSX), and X (just different).
========
Hardware (MBP but more or less applies to other Macs too)
========
P
* MBP is a high-quality piece of hardware. You are paying for it, of course, but anyway you'll get high-resolution screen, good graphics card, nice back-lit keyboard, and fast HDD. MBP has all major peripherals like wireless, USB, external monitor, bluetooth, etc.
* MBP had an attractive design. It's relatively thin and light.
N
* MBP has sharp edges! You kinda get used to it but the annoyance never goes away completely when you rest your hands under keyboard.
* The keyboard has missing keys like separate Delete/Backspace, and Page Up/Down. You can use Function key and other combinations for those purposes but it's not convenient, especially when writing text.
* Hardware modules like speaker and CD/DVD drive have software-based controls, meaning that you have to have the OS up and running properly in order to control those devices. Now this may seem like a trivial thing but it's not. Here are my two experiences:
1- I had a CD stuck in the drive but not mounted (i.e. not recognized by the OS). I had no way of getting it out. I rebooted with Windows and used right-click/eject on the drive name. The Eject key is not like the eject button on other drives. It is not directly connected to the hardware.
2- I started my laptop during someone's talk in Barcelona and had no way of stopping the log-in sound because the OS was still booting. My last laptop had a volume knob directly connected to hardware.
It seems that designers have given a higher priority to "looking good" than "being usable".
========
User Interface
========
This category is the most difficult one for me to evaluate, as it clearly depends on "user". There are two key points:
1- OSX hides details which can make it easier to use especially for less technical users. I personally like to customize things and do things the way I want. The "ease of use" thing has no value for me if not being a negative. Window is kinda going toward that direction too.
2- OSX has a different UI style compared to Windows, such the common top menu, window resizing/closing, etc. I don't find either one better, just takes getting used to, but some users may think differently.
If there is one thing that I do find inferior in OSX compared to Windows is Finder vs. Windows Explorer. The Explorer in XP was my favourite. Vista and Win7 changed it for worse in my opinion (for example by removing customizable toolbars) but it still has the typical 2-pane view with tree structure on the left and content on the right. Finder has two options none of them like Explorer. Some difficulties with Finder are moving a file to another directory. In Windows Explorer you simply drag and drop in the same window (to the tree pane) but with Finder you need a second window because there is no tree pane. It is also difficult to create a new folder or paste from clipboard when the window is full and there's no space for right-clicking (you can use keyboard commands though). And why the hell the Cut command is always disabled in Finder?
========
General OS Operation
========
OSX is faster in booting up, shutting down and starting applications. That is the only certain positive I've seen so far.
OSX seems a little more stable but it does crash too (or some apps). When I had a damaged CD stuck in my CD/DVD drive (see the Hardware section), my OSX took forever to load and the keyboard stopped working! Windows doesn't really crash much on me either. The stability issues are usually for applications not OS.
Having to deal with a known standard hardware (the Mac case) allows OS to be a lot more optimized. Windows need to be open to all sorts of hardware and software configuration (some really cheap and low-quality ones) and so it's a lot more likely to suffer from problems. In a way, Mac is faster and more stable and we pay for it!
Because most online threats are for Windows, you are less likely to have that sort of problem on Mac. Does it mean OSX is more secure? I'm not sure.
========
Applications
========
There are more applications (especially games) available for Windows but it's not as bad as I thought before. You can find pretty much everything for Mac maybe except games. I didn't find applications any of the two operating systems particularly better than the other. As I mentioned in my 3D Graphics post, the performance of Maya 2010 and Half-Life 2 were not that different on Windows and OSX.
========
Software Development
========
This is the easiest category for evaluation, and I'm sure anybody who has read my previous posts already knows what I think.
N
- OSX has a weaker 3D API
- ObjectiveC and Cocoa are confusing and harder to use compared to.NET and C#.
- Xcode is an embarrassingly bad IDE.
===========
So what is the conclusion? If you have the money, and are doing the "typical" tasks, and don't want to bother with customizing things, then Mac can be a good option. In other cases, I haven't been convinced that Mac is a better choice worth paying a lot more. Of course if you can afford it and are a technical person doing more complex stuff, then it can still be a good idea especially because you can have Windows on it too.
There's more to do for testing and seeing how things work over time.
I'LL BE BACK!
Anyway, I think I'm in situation to have an overall (maybe still preliminary) opinion of the whole Mac vs. PC topic. I'm going to write my #1 summary of evaluations grouped into 5 categories: Hardware, User Interface, General OS Operation, Applications, and Software Development. As we all could expect Mac and OSX don't get the same results on all categories and of course for all types of users, and I try to consider this "user type" matter in all categories.
Overall, I have to say I'm happy with my MacBook Pro. Except for playing Windows-only games, using Visual Studio (Windows development) and sometimes MS Office (because OpenOffice doesn't do all the Office functions), I hardly had to go to my Windows side. I have Photoshop only for Windows but I have Corel Painter on OSX and that usually does the typical jobs I have for Photoshop. There are all sorts of free apps for Mac. But we will talk about all these in details. One thing I can say now is that considering everything, I didn't find the computing experience superior in Mac, especially when we remember the price. Here is the tricky part though, because the experience "may" be superior for some types of users. Of course in some categories, particularly programming, the OSX experience has been without a doubt inferior. Let's go over categories before I try to make some conclusions. In each category, I group items into P (positive for OSX), N (negative for OSX), and X (just different).
========
Hardware (MBP but more or less applies to other Macs too)
========
P
* MBP is a high-quality piece of hardware. You are paying for it, of course, but anyway you'll get high-resolution screen, good graphics card, nice back-lit keyboard, and fast HDD. MBP has all major peripherals like wireless, USB, external monitor, bluetooth, etc.
* MBP had an attractive design. It's relatively thin and light.
N
* MBP has sharp edges! You kinda get used to it but the annoyance never goes away completely when you rest your hands under keyboard.
* The keyboard has missing keys like separate Delete/Backspace, and Page Up/Down. You can use Function key and other combinations for those purposes but it's not convenient, especially when writing text.
* Hardware modules like speaker and CD/DVD drive have software-based controls, meaning that you have to have the OS up and running properly in order to control those devices. Now this may seem like a trivial thing but it's not. Here are my two experiences:
1- I had a CD stuck in the drive but not mounted (i.e. not recognized by the OS). I had no way of getting it out. I rebooted with Windows and used right-click/eject on the drive name. The Eject key is not like the eject button on other drives. It is not directly connected to the hardware.
2- I started my laptop during someone's talk in Barcelona and had no way of stopping the log-in sound because the OS was still booting. My last laptop had a volume knob directly connected to hardware.
It seems that designers have given a higher priority to "looking good" than "being usable".
========
User Interface
========
This category is the most difficult one for me to evaluate, as it clearly depends on "user". There are two key points:
1- OSX hides details which can make it easier to use especially for less technical users. I personally like to customize things and do things the way I want. The "ease of use" thing has no value for me if not being a negative. Window is kinda going toward that direction too.
2- OSX has a different UI style compared to Windows, such the common top menu, window resizing/closing, etc. I don't find either one better, just takes getting used to, but some users may think differently.
If there is one thing that I do find inferior in OSX compared to Windows is Finder vs. Windows Explorer. The Explorer in XP was my favourite. Vista and Win7 changed it for worse in my opinion (for example by removing customizable toolbars) but it still has the typical 2-pane view with tree structure on the left and content on the right. Finder has two options none of them like Explorer. Some difficulties with Finder are moving a file to another directory. In Windows Explorer you simply drag and drop in the same window (to the tree pane) but with Finder you need a second window because there is no tree pane. It is also difficult to create a new folder or paste from clipboard when the window is full and there's no space for right-clicking (you can use keyboard commands though). And why the hell the Cut command is always disabled in Finder?
========
General OS Operation
========
OSX is faster in booting up, shutting down and starting applications. That is the only certain positive I've seen so far.
OSX seems a little more stable but it does crash too (or some apps). When I had a damaged CD stuck in my CD/DVD drive (see the Hardware section), my OSX took forever to load and the keyboard stopped working! Windows doesn't really crash much on me either. The stability issues are usually for applications not OS.
Having to deal with a known standard hardware (the Mac case) allows OS to be a lot more optimized. Windows need to be open to all sorts of hardware and software configuration (some really cheap and low-quality ones) and so it's a lot more likely to suffer from problems. In a way, Mac is faster and more stable and we pay for it!
Because most online threats are for Windows, you are less likely to have that sort of problem on Mac. Does it mean OSX is more secure? I'm not sure.
========
Applications
========
There are more applications (especially games) available for Windows but it's not as bad as I thought before. You can find pretty much everything for Mac maybe except games. I didn't find applications any of the two operating systems particularly better than the other. As I mentioned in my 3D Graphics post, the performance of Maya 2010 and Half-Life 2 were not that different on Windows and OSX.
========
Software Development
========
This is the easiest category for evaluation, and I'm sure anybody who has read my previous posts already knows what I think.
N
- OSX has a weaker 3D API
- ObjectiveC and Cocoa are confusing and harder to use compared to.NET and C#.
- Xcode is an embarrassingly bad IDE.
===========
So what is the conclusion? If you have the money, and are doing the "typical" tasks, and don't want to bother with customizing things, then Mac can be a good option. In other cases, I haven't been convinced that Mac is a better choice worth paying a lot more. Of course if you can afford it and are a technical person doing more complex stuff, then it can still be a good idea especially because you can have Windows on it too.
There's more to do for testing and seeing how things work over time.
I'LL BE BACK!
Thursday, July 8, 2010
#13
I just came back from Barcelona and will be off to Vancouver tomorrow. So the overall summary has to wait.
I'LL BE BACK!
I'LL BE BACK!
Tuesday, July 6, 2010
#12
I'm in the beautiful city of Barcelona for a conference, and planning my first summarized report for next week.
I'LL BE BACK!
I'LL BE BACK!
Monday, June 28, 2010
#11, 3D Graphics, Part 1
This week I'm going to talk about 3D graphics on Mac. Please refer to previous posts on graphics and programming for some background info. What I did in the past few days was (1) testing some sample 3D applications and (2) writing some basic 3D programs. Short version of the result is that Mac hardware and software don't seem to be particularly weaker than PC, in some cases they even do slightly better, but in some other cases especially for real-time rendering using hardware accelerators they may not be as efficient which can be due to less efficient drivers. The basic 3D API on Mac is OpenGL which is not as good as Direct3D on Windows but is pretty much portable, at least for basic stuff.
Before I get to some details, let's make sure we all know the basics of 3D graphics.
==========
Very Very Quick Intro to 3D Graphics
==========
2D computer graphics is all about images, i.e. two-dimensional arrays of points with different colour values (a.k.a pixels or picture elements). 3D computer graphics on the other hand is about points in three-dimensional space. We call these points vertices. Each vertex has three location values (XYZ) and a colour value. But things are more complicated than this for a couple of reasons.
3D points form 3D objects when connected. The simplest type of 3D objects are polygons, i.e. a set of usually 3 or 4 connected vertices that are on the same plane (surface). Polygons are then connected to form a mesh that is the base for complex 3D objects. A mesh can then have a material (properties like colour and reflection) and/or a texture (a 2D image covering the surface of the 3D object). Materials and textures define the colour of vertices and also the colour of points inside the polygons.
Now here's the second complication. 3D scenes have light sources. This means that the colour of a point in 3D is a function of its material/texture and also the light sources.
Finally we have another new concept and that is viewpoint. A 2D image has no notion of viewpoint. Although physically you can look at it from different points and potentially see it differently, this has nothing to do with how your computer is generating the image. 3D scenes on the other hand need to be transformed to a 2D image before they can be shown on screen (let's not talk about real 3D displays). In order to decide what your 3D world will look like, you need to decide where your eyes are.
The process of creating a 3D world is called modelling. Making the objects in this 3D space move is animation. Transforming your 3D world to a 2D image is called rendering, sometimes called shading. Rendering process is controlled by a series of parameters and is usually done in two steps:
** Vertex Shading transforms all your vertices to points in 2D. This depends on the location/scale/orientation of your objects in 3D world and the location/orientation and properties of your camera (e.g. field of view).
** Pixel Shading is the second step and decides what colour to be used for each pixel based on material and texture of the objects and also the light sources.
Rendering used to be (and still can be) done in software. Graphic Accelerators allowed this to be done in specialized hardware with fixed functions. They then evolved into programmable GPU's with their own programming languages called Shaders. High Level Shader Language (HLSL) is the shader language supported by Direct3D. OpenGl Shading Language (GLSL) is an alternative for OpenGL. These languages have their own versions and different graphics cards are compatible with different versions, or Shader Models.
When you watch a 3D animated film each single frame has been rendered separately. When you play a 3D game each single frame is being rendered in real time.
==========
Application Tests
==========
The first 3D application I tested was Maya 2011.
512x512 render using Mental Ray
Windows, Maya 32-bit, 3.48 sec
Windows, Maya 64-bit, 3.08 sec
OSX, Maya 64-bit, 3.02 sec
For comparison, I tried the same file on my desktop PC (Quad Core, 3GHz, 6GM RAM, Performance Index 5.9) and it took 2.07 sec. FYI, the Performance Index for my Windows 7 installed on Mac is 5.2.
1024x768 render of another scene without Mental Ray and using Maya Software
Windows, Maya 64-bit, 0.07 sec
Mac, Maya 64-bit, 0.10 sec
When I used Maya Hardware both had less than 0.01 sec and I couldn't see any difference. I will try longer tests later for better comparison when using Maya Hardware.
Next I tried a 3D game. I chose Half-Life 2 which is now available for Mac. Valve has released Steam for Mac, and some of their games including Orange Box are now available for Mac. One good thing is that if you have the Windows version, you don't need to buy the Mac version and can download it for free. I tested the Windows and Mac version at default settings (1280x800 for Windows and 1152x720 for OSX). I only tried HL2 on OSX for a short period. It seems to be working fine but even at a lower resolution a slight performance problem could be noticed. The rendering seemed a little slower as you could see the screen being refreshed with a little delay. This was not a big issue at all and hardly noticeable but I'm guessing when we get to more complex scenes it could get worse. Needs more testing.
Overall, Mac (or I'd better say OSX since my Windows is running on Mac hardware too) doesn't seem to have a major issue with 3D. My guess is that OpenGL drivers for Mac are not as efficient as Direct3D drivers on Windows. This can be due to slight inferiority of OpenGl itself, drivers, general difficulty of programming for Mac, and popularity of Windows platform that makes programmers work harder and better for it.
The next step of my test was to compare OpenGL on OSX and Windows.
==========
3D Programming
==========
OpenGL is the basic 3D API for Mac. Even other API's like CL are created on top of it. So to test 3D programming it seems that we should focus on OpenGL. For comparison, we can use Direct3D or OpenGL, and I started with OpenGL on both platforms. Windows and Visual Studio don't come with all the libraries for OpenGL programming but they are easily available. This includes OpenGl itself and GLUT (utility functions for OpenGL). There is also GLAUX which is only available for Windows and I won't use. On the other hand, OSX is completely OpenGL-based and Xcode comes with GL and GLUT frameworks. Here are the basic steps to write a simple OpenGL program on OSX:
1- Start a new project of type Command Line tool with C. Unfortunately this is the only non-Cocoa C-based option. Don't worry you can do graphics with it using OpenGL.
2- Right-click on the project name and select Add and then Existing Framework. Select GLUT and OpenGL.
3- Add the following code:
#include
#include
#include
void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_POLYGON);
glVertex2f(-0.5, -0.5);
glVertex2f(-0.5, 0.5);
glVertex2f(0.5, 0.5);
glVertex2f(0.5, -0.5);
glEnd();
glFlush();
}
int main(int argc, char** argv)
{
glutInit(&argc,argv);
glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(500,500);
glutInitWindowPosition(0,0);
glutCreateWindow("simple");
glutDisplayFunc(display);
glutMainLoop();
return 0;
}
Let me explain this code a little bit for those who are not familiar with OpenGL:
** The #include lines allow you to use OpenGL and GLUT. Remember that in C/C++ you need #include for compiler to use libraries. The linker then links your program to actual library code (here the frameworks you added).
** The main() function is the entry point of your C program that initializes OpenGL, creates a window, sets a Display Function and calls OpenGL Main Loop. Display Function draws the graphics on your window. You need to provide a function and pass its name to glutDisplayFunc(). Main Loop processes user commands. If you don't provide your own Main Loop, the default doesn't really do anything special.
** The display() function is what you pass to glutDisplayFunc() and you basically have to have one (it can be called anything). In this simple example, our display function only creates a polygon by defining four vertices in 2D. You notice that OpenGL can be used for 2D graphics as well as 3D. This function will be called every time the window needs to be redrawn.
To run this on Windows, you create a Win32 empty console application, add OpenGL libraries to linker and add a new file with these headers:
#include
#include
#include
You notice that you will need windows.h, and also that OpenGL header files/directories have different names. The rest of the code is the same.
The next step is to add some 3D code. I used a simple Camera class that allows moving camera, I added a Main Loop that allows user to control the camera, and modified the Display Function to create and draw some simple 3D objects. You can find the full code here:
http://www.csit.carleton.ca/~arya/b2cc/opengl/
My Display Function looks like this:
void Display(void)
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Don't forget the depth buffer!
glLoadIdentity(); //Load a new modelview matrix -> we can apply new transformations
Camera.Render();
glLightfv(GL_LIGHT0, GL_POSITION, LightPos);
glutSolidSphere(1.0,20,20);
glTranslatef(2.0,0.0,0.0);
glutSolidSphere(1.0,20,20);
glPushMatrix();
glTranslatef(0.0,2.0,0.0);
glutSolidSphere(1.0,20,20);
glPopMatrix();
glTranslatef(0.0,0.0,2.0);
glutSolidSphere(1.0,20,20);
glTranslatef(-4.0,0.0,0.0);
glRotatef(TorusRotated, 0.0,1.0,0.0);
glutSolidTorus(0.3,1.0,8,16);
glFlush(); //Finish rendering
glutSwapBuffers(); //Swap the buffers ->make the result of rendering visible
}
You can see that simple 3D object are being created and then placed in 3D world. Everything is static except a Torus whose rotation value depends on the variable TorusRotated. I used two methods for changing this variable. Look at the main() in the code and locate these lines (we should use only one of them):
glutIdleFunc(Idle);
glutTimerFunc(400,Timer,0);
Both are similar to the one that defined our Display Function but they are defining an Idle function (to be called when the application is doing nothing) and a Timer function (to be called at certain time intervals). Each one of these methods simply changes the TorusRotated variable so the next time the scene is rendered you see the Torus with a different orientation. The timer method is prefered when you want to control how many frames per second you want to have.
For your quick reference here are the Idle and Timer functions:
void Idle(void)
{
TorusRotated += 2.0;
Display();
}
void Timer( int value )
{
TorusRotated += 2.0;
Display();
glutTimerFunc(400,Timer,value); //need to call the timer again
}
It is not very efficient to do actual drawing in Idle and Timer functions but optimization is not an issue here. The code will work with no change on Windows.
For this simple example I didn't notice any particular performance difference for rendering but the Idle and Timer functions don't work the same on OSX and Windows. More specifically, the Idle function on OSX is called a lot more frequently and the Timer function intervals can go as short as 1 millisecond. In Windows you won't get anything less than 10 milliseconds. In Direct3D there are other ways to get higher time resolutions but apparently the OpenGL implementation on Windows doesn't use it and stops at 10 millisecond which is the default for Windows timer.
This week tests don't seem to be very conclusive but hopefully it is a good starting point for understanding how things work and performing more advanced tests, both with existing applications and games, and also developing 3D programs.
I'm off to Barcelona and then Vancouver in a few days, so expect some delays but no worries.
I'LL BE BACK!
Before I get to some details, let's make sure we all know the basics of 3D graphics.
==========
Very Very Quick Intro to 3D Graphics
==========
2D computer graphics is all about images, i.e. two-dimensional arrays of points with different colour values (a.k.a pixels or picture elements). 3D computer graphics on the other hand is about points in three-dimensional space. We call these points vertices. Each vertex has three location values (XYZ) and a colour value. But things are more complicated than this for a couple of reasons.
3D points form 3D objects when connected. The simplest type of 3D objects are polygons, i.e. a set of usually 3 or 4 connected vertices that are on the same plane (surface). Polygons are then connected to form a mesh that is the base for complex 3D objects. A mesh can then have a material (properties like colour and reflection) and/or a texture (a 2D image covering the surface of the 3D object). Materials and textures define the colour of vertices and also the colour of points inside the polygons.
Now here's the second complication. 3D scenes have light sources. This means that the colour of a point in 3D is a function of its material/texture and also the light sources.
Finally we have another new concept and that is viewpoint. A 2D image has no notion of viewpoint. Although physically you can look at it from different points and potentially see it differently, this has nothing to do with how your computer is generating the image. 3D scenes on the other hand need to be transformed to a 2D image before they can be shown on screen (let's not talk about real 3D displays). In order to decide what your 3D world will look like, you need to decide where your eyes are.
The process of creating a 3D world is called modelling. Making the objects in this 3D space move is animation. Transforming your 3D world to a 2D image is called rendering, sometimes called shading. Rendering process is controlled by a series of parameters and is usually done in two steps:
** Vertex Shading transforms all your vertices to points in 2D. This depends on the location/scale/orientation of your objects in 3D world and the location/orientation and properties of your camera (e.g. field of view).
** Pixel Shading is the second step and decides what colour to be used for each pixel based on material and texture of the objects and also the light sources.
Rendering used to be (and still can be) done in software. Graphic Accelerators allowed this to be done in specialized hardware with fixed functions. They then evolved into programmable GPU's with their own programming languages called Shaders. High Level Shader Language (HLSL) is the shader language supported by Direct3D. OpenGl Shading Language (GLSL) is an alternative for OpenGL. These languages have their own versions and different graphics cards are compatible with different versions, or Shader Models.
When you watch a 3D animated film each single frame has been rendered separately. When you play a 3D game each single frame is being rendered in real time.
==========
Application Tests
==========
The first 3D application I tested was Maya 2011.
512x512 render using Mental Ray
Windows, Maya 32-bit, 3.48 sec
Windows, Maya 64-bit, 3.08 sec
OSX, Maya 64-bit, 3.02 sec
For comparison, I tried the same file on my desktop PC (Quad Core, 3GHz, 6GM RAM, Performance Index 5.9) and it took 2.07 sec. FYI, the Performance Index for my Windows 7 installed on Mac is 5.2.
1024x768 render of another scene without Mental Ray and using Maya Software
Windows, Maya 64-bit, 0.07 sec
Mac, Maya 64-bit, 0.10 sec
When I used Maya Hardware both had less than 0.01 sec and I couldn't see any difference. I will try longer tests later for better comparison when using Maya Hardware.
Next I tried a 3D game. I chose Half-Life 2 which is now available for Mac. Valve has released Steam for Mac, and some of their games including Orange Box are now available for Mac. One good thing is that if you have the Windows version, you don't need to buy the Mac version and can download it for free. I tested the Windows and Mac version at default settings (1280x800 for Windows and 1152x720 for OSX). I only tried HL2 on OSX for a short period. It seems to be working fine but even at a lower resolution a slight performance problem could be noticed. The rendering seemed a little slower as you could see the screen being refreshed with a little delay. This was not a big issue at all and hardly noticeable but I'm guessing when we get to more complex scenes it could get worse. Needs more testing.
Overall, Mac (or I'd better say OSX since my Windows is running on Mac hardware too) doesn't seem to have a major issue with 3D. My guess is that OpenGL drivers for Mac are not as efficient as Direct3D drivers on Windows. This can be due to slight inferiority of OpenGl itself, drivers, general difficulty of programming for Mac, and popularity of Windows platform that makes programmers work harder and better for it.
The next step of my test was to compare OpenGL on OSX and Windows.
==========
3D Programming
==========
OpenGL is the basic 3D API for Mac. Even other API's like CL are created on top of it. So to test 3D programming it seems that we should focus on OpenGL. For comparison, we can use Direct3D or OpenGL, and I started with OpenGL on both platforms. Windows and Visual Studio don't come with all the libraries for OpenGL programming but they are easily available. This includes OpenGl itself and GLUT (utility functions for OpenGL). There is also GLAUX which is only available for Windows and I won't use. On the other hand, OSX is completely OpenGL-based and Xcode comes with GL and GLUT frameworks. Here are the basic steps to write a simple OpenGL program on OSX:
1- Start a new project of type Command Line tool with C. Unfortunately this is the only non-Cocoa C-based option. Don't worry you can do graphics with it using OpenGL.
2- Right-click on the project name and select Add and then Existing Framework. Select GLUT and OpenGL.
3- Add the following code:
#include
#include
#include
void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_POLYGON);
glVertex2f(-0.5, -0.5);
glVertex2f(-0.5, 0.5);
glVertex2f(0.5, 0.5);
glVertex2f(0.5, -0.5);
glEnd();
glFlush();
}
int main(int argc, char** argv)
{
glutInit(&argc,argv);
glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(500,500);
glutInitWindowPosition(0,0);
glutCreateWindow("simple");
glutDisplayFunc(display);
glutMainLoop();
return 0;
}
Let me explain this code a little bit for those who are not familiar with OpenGL:
** The #include lines allow you to use OpenGL and GLUT. Remember that in C/C++ you need #include for compiler to use libraries. The linker then links your program to actual library code (here the frameworks you added).
** The main() function is the entry point of your C program that initializes OpenGL, creates a window, sets a Display Function and calls OpenGL Main Loop. Display Function draws the graphics on your window. You need to provide a function and pass its name to glutDisplayFunc(). Main Loop processes user commands. If you don't provide your own Main Loop, the default doesn't really do anything special.
** The display() function is what you pass to glutDisplayFunc() and you basically have to have one (it can be called anything). In this simple example, our display function only creates a polygon by defining four vertices in 2D. You notice that OpenGL can be used for 2D graphics as well as 3D. This function will be called every time the window needs to be redrawn.
To run this on Windows, you create a Win32 empty console application, add OpenGL libraries to linker and add a new file with these headers:
#include
#include
#include
You notice that you will need windows.h, and also that OpenGL header files/directories have different names. The rest of the code is the same.
The next step is to add some 3D code. I used a simple Camera class that allows moving camera, I added a Main Loop that allows user to control the camera, and modified the Display Function to create and draw some simple 3D objects. You can find the full code here:
http://www.csit.carleton.ca/~arya/b2cc/opengl/
My Display Function looks like this:
void Display(void)
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Don't forget the depth buffer!
glLoadIdentity(); //Load a new modelview matrix -> we can apply new transformations
Camera.Render();
glLightfv(GL_LIGHT0, GL_POSITION, LightPos);
glutSolidSphere(1.0,20,20);
glTranslatef(2.0,0.0,0.0);
glutSolidSphere(1.0,20,20);
glPushMatrix();
glTranslatef(0.0,2.0,0.0);
glutSolidSphere(1.0,20,20);
glPopMatrix();
glTranslatef(0.0,0.0,2.0);
glutSolidSphere(1.0,20,20);
glTranslatef(-4.0,0.0,0.0);
glRotatef(TorusRotated, 0.0,1.0,0.0);
glutSolidTorus(0.3,1.0,8,16);
glFlush(); //Finish rendering
glutSwapBuffers(); //Swap the buffers ->make the result of rendering visible
}
You can see that simple 3D object are being created and then placed in 3D world. Everything is static except a Torus whose rotation value depends on the variable TorusRotated. I used two methods for changing this variable. Look at the main() in the code and locate these lines (we should use only one of them):
glutIdleFunc(Idle);
glutTimerFunc(400,Timer,0);
Both are similar to the one that defined our Display Function but they are defining an Idle function (to be called when the application is doing nothing) and a Timer function (to be called at certain time intervals). Each one of these methods simply changes the TorusRotated variable so the next time the scene is rendered you see the Torus with a different orientation. The timer method is prefered when you want to control how many frames per second you want to have.
For your quick reference here are the Idle and Timer functions:
void Idle(void)
{
TorusRotated += 2.0;
Display();
}
void Timer( int value )
{
TorusRotated += 2.0;
Display();
glutTimerFunc(400,Timer,value); //need to call the timer again
}
It is not very efficient to do actual drawing in Idle and Timer functions but optimization is not an issue here. The code will work with no change on Windows.
For this simple example I didn't notice any particular performance difference for rendering but the Idle and Timer functions don't work the same on OSX and Windows. More specifically, the Idle function on OSX is called a lot more frequently and the Timer function intervals can go as short as 1 millisecond. In Windows you won't get anything less than 10 milliseconds. In Direct3D there are other ways to get higher time resolutions but apparently the OpenGL implementation on Windows doesn't use it and stops at 10 millisecond which is the default for Windows timer.
This week tests don't seem to be very conclusive but hopefully it is a good starting point for understanding how things work and performing more advanced tests, both with existing applications and games, and also developing 3D programs.
I'm off to Barcelona and then Vancouver in a few days, so expect some delays but no worries.
I'LL BE BACK!
Monday, June 21, 2010
#10, 2D Graphics and GUI Programming Summary
I heard last week that Xcode 4 is being released and it has Interface Builder integrated. I found it interesting that Apple calls this (and other Xcode features) "revolutionary" while they are still way behind industry standards for an IDE, but anyway it's good to see this change. I look forward to see some other changes related to problems I have mentioned here. Anyway, today I want to wrap up my quick review of basic Cocoa programming and creating simple GUI and 2D graphics applications. But first let me mention something that I didn't discuss.
Back in the old days (1990's) when I was using Microsoft Foundation Classes (MFC) in Visual C++, I was introduced to the concept of document-based vs. form-based applications. MFC had (and still has) three types of applications: Multiple Document, Single Document, and Dialog-based. The first two types are variation of what in general is called document-based application where you can open an existing document or create a new one. The framework provides programmers with base classes for Document (application data) and View (user interface). Dialog-based or form-based applications on the other hand have a dialog box (or a form) as their main interface although they still may open files, and there is no framework imposed separation between data and UI. In MFC dialog-based application where easier to make than document-based ones, especially because it was easier to define the program in terms of a series of event-handlers responding to UI objects on the form. Visual C# made creation of dialog-based (now called forms) even easier and got rid of document-based application style (you can still make them if you want but have to create the document class yourself). Cocoa does provide similar option. Default application in Xcode is a "form-based" one, but you may select the document-based option and some classes will be added to your code to support document-based architecture.
Just like I didn't like document-based applications in Visual C++, I didn't like them in Xcode. In fact I disliked them even more because they are harder to use and more confusing than their VC++ version). After a short try, I decided to not work with the document-based applications. If you are interested in learning about them, check this page as your starting point:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Documents/Tasks/ImplementingDocApp.html
Now let's focus on the form-based applications and basic GUI and 2D graphics programming with Cocoa. Here are the basic things you need to know:
1- Cocoa and .NET provide more or less similar functionality for creating basic GUI and 2D graphics apps, but Cocoa classes are slightly more complicated to use. As for the IDE, Xcode is A LOT more complicated to use than Visual Studio. Also Objective-C as the programming language is not as convenient as C# for typical C/C++ programmers.
2- Once you create a default form-based Cocoa application, you have a NSApplicationDelegate class made for you. This can be your starting point to add variables and event-handlers. It already has a member that points to your application window.
3- You design your form (user interface) in Interface Builder that can be launched by double-clicking on your xib or nib file in Xcode. In IB, from the Library add the UI objects to your form. Save and go back to Xcode.
4- You add two important things to your AppDelegate class: member variables representing UI objects and methods for UI event handlers. variables representing a UI objet have the type IBOutlet and the method IBAction. You don't need to specify the exact type of the object. Cocoa uses dynamic types. Here is an example:
=======
//TestAppDelegate.h
=======
#import
@interface TestAppDelegate : NSObject {
NSWindow *window; //added automatically
IBOutlet id textView; //outlet for text view
IBOutlet id customView; //outlet for custom view showing images
IBOutlet id textfield; //outlet for a simple text field
}
- (IBAction) clearText: sender; //method for clearing the text view
- (IBAction) setView: sender; //set custom view properties
@property (assign) IBOutlet NSWindow *window;
@end
=======
//TestAppDelegate.m
=======
#import "TestAppDelegate.h"
@implementation TestAppDelegate
@synthesize window;
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Insert code here to initialize your application
}
//////////
// This is the part where we implement the methods we added
//
- (IBAction) clearText: sender
{
[textView setString: @" "];
}
- (IBAction) setView: sender
{
//some code here
}
@end
5- Once you add the code in Xcode and UI objects in IB, you go back to IB and link the UI objects to the code. This is done by holding down the Control key and dragging item A (source) to item B (target). For member variables, source is the AppDelegate object in the IB Documents window, and taget is the UI object on the form. For event handlers, source is the UI object and target is the AppDelegate. In both case, once you drop, you get a list of options (class members that you want to use).
6- Instead of using the automatically-added AppDelegate class, you may create a new class based on NSObject and do the exact same thing with that.
7- Another thing that you can do is to add classes to extend existing Cocoa classes. For example we created a new class derived from NSView to control our custom views and make them draw images. It already had some default methods and we added our code to the drawRect method (see previous postings). We can also add member variables and new methods:
=======
TstView.h
=======
#import
@interface TstView : NSView
{
int x; //new variables
}
- (id) setx; //new method
@end
8- Once you have added a new class, you need to go back to IB, select the UI object, and select the new class for it.
9- Finally you use classes like NSPoint, NSColor, and NSImage to do 2D graphics as discussed before and generally in your drawRect method. See previous posts for details.
Hopefully this quick review gave you the chance to learn a little bit about Cocoa programming. It was a good learning experience for me. Although I didn't find any of the two systems significantly superior to the other in terms of functionality, I found the Windows programming frameworks and tools more convenient and effective. Of course I'm not done yet. My next step is to try 3D programming and also test and compare some operations in common 3D programs.
I'LL BE BACK!
Back in the old days (1990's) when I was using Microsoft Foundation Classes (MFC) in Visual C++, I was introduced to the concept of document-based vs. form-based applications. MFC had (and still has) three types of applications: Multiple Document, Single Document, and Dialog-based. The first two types are variation of what in general is called document-based application where you can open an existing document or create a new one. The framework provides programmers with base classes for Document (application data) and View (user interface). Dialog-based or form-based applications on the other hand have a dialog box (or a form) as their main interface although they still may open files, and there is no framework imposed separation between data and UI. In MFC dialog-based application where easier to make than document-based ones, especially because it was easier to define the program in terms of a series of event-handlers responding to UI objects on the form. Visual C# made creation of dialog-based (now called forms) even easier and got rid of document-based application style (you can still make them if you want but have to create the document class yourself). Cocoa does provide similar option. Default application in Xcode is a "form-based" one, but you may select the document-based option and some classes will be added to your code to support document-based architecture.
Just like I didn't like document-based applications in Visual C++, I didn't like them in Xcode. In fact I disliked them even more because they are harder to use and more confusing than their VC++ version). After a short try, I decided to not work with the document-based applications. If you are interested in learning about them, check this page as your starting point:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Documents/Tasks/ImplementingDocApp.html
Now let's focus on the form-based applications and basic GUI and 2D graphics programming with Cocoa. Here are the basic things you need to know:
1- Cocoa and .NET provide more or less similar functionality for creating basic GUI and 2D graphics apps, but Cocoa classes are slightly more complicated to use. As for the IDE, Xcode is A LOT more complicated to use than Visual Studio. Also Objective-C as the programming language is not as convenient as C# for typical C/C++ programmers.
2- Once you create a default form-based Cocoa application, you have a NSApplicationDelegate class made for you. This can be your starting point to add variables and event-handlers. It already has a member that points to your application window.
3- You design your form (user interface) in Interface Builder that can be launched by double-clicking on your xib or nib file in Xcode. In IB, from the Library add the UI objects to your form. Save and go back to Xcode.
4- You add two important things to your AppDelegate class: member variables representing UI objects and methods for UI event handlers. variables representing a UI objet have the type IBOutlet and the method IBAction. You don't need to specify the exact type of the object. Cocoa uses dynamic types. Here is an example:
=======
//TestAppDelegate.h
=======
#import
@interface TestAppDelegate : NSObject
NSWindow *window; //added automatically
IBOutlet id textView; //outlet for text view
IBOutlet id customView; //outlet for custom view showing images
IBOutlet id textfield; //outlet for a simple text field
}
- (IBAction) clearText: sender; //method for clearing the text view
- (IBAction) setView: sender; //set custom view properties
@property (assign) IBOutlet NSWindow *window;
@end
=======
//TestAppDelegate.m
=======
#import "TestAppDelegate.h"
@implementation TestAppDelegate
@synthesize window;
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Insert code here to initialize your application
}
//////////
// This is the part where we implement the methods we added
//
- (IBAction) clearText: sender
{
[textView setString: @" "];
}
- (IBAction) setView: sender
{
//some code here
}
@end
5- Once you add the code in Xcode and UI objects in IB, you go back to IB and link the UI objects to the code. This is done by holding down the Control key and dragging item A (source) to item B (target). For member variables, source is the AppDelegate object in the IB Documents window, and taget is the UI object on the form. For event handlers, source is the UI object and target is the AppDelegate. In both case, once you drop, you get a list of options (class members that you want to use).
6- Instead of using the automatically-added AppDelegate class, you may create a new class based on NSObject and do the exact same thing with that.
7- Another thing that you can do is to add classes to extend existing Cocoa classes. For example we created a new class derived from NSView to control our custom views and make them draw images. It already had some default methods and we added our code to the drawRect method (see previous postings). We can also add member variables and new methods:
=======
TstView.h
=======
#import
@interface TstView : NSView
{
int x; //new variables
}
- (id) setx; //new method
@end
8- Once you have added a new class, you need to go back to IB, select the UI object, and select the new class for it.
9- Finally you use classes like NSPoint, NSColor, and NSImage to do 2D graphics as discussed before and generally in your drawRect method. See previous posts for details.
Hopefully this quick review gave you the chance to learn a little bit about Cocoa programming. It was a good learning experience for me. Although I didn't find any of the two systems significantly superior to the other in terms of functionality, I found the Windows programming frameworks and tools more convenient and effective. Of course I'm not done yet. My next step is to try 3D programming and also test and compare some operations in common 3D programs.
I'LL BE BACK!
Monday, June 14, 2010
#9, Graphics Programming, Part 3
It's summer and from sunny days to travel plans to tons of projects that you have left for summer to do, there's not much time to explore OSX, although I've been using my MBP all the time. But anyway, I'm following the plan, and this week I'll continue with graphics programming by trying some basic image functions; things such as displaying an image and drawing on it.
We learned about some basic concepts in graphics programming last week. They were Rect, Point, and Color. This week, I introduce two new ones which are as fundamental as those: Path and Image. We will see which Cocoa (and in fact Quartz) classes control them and how.
==========
Path
==========
A Path is a line (including straight and curved lines, arcs, rectangles, etc) that is defined by points and some math to connect them. Paths can draw themselves to a view (see last week post to remember what a view is) and they can be changed or combined. NSBezierPath is the Cocoa class that represents these lines, or in general Bezier Curves (parametric curves with control points, http://en.wikipedia.org/wiki/Bezier_curve). Let's look at some examples of creating and drawing Path objects. The code can go inside the drawRect method of your view class from last week.
The first example draws a straight line between two points with a gray color:
//create start and end points
NSPoint startPoint = { 21, 21 };
NSPoint endPoint = { 128,128 };
//create the path object
//the bezierPath static method in NSBezierPath class returns a new and empty object
NSBezierPath * path = [NSBezierPath bezierPath];
//define the path's start and end, and the path type (a straight line)
[path moveToPoint: startPoint];
[path lineToPoint: endPoint];
//set the line width for drawing
[path setLineWidth: 4];
//define the current colour
[[NSColor grayColor] set];
//draw the path
[path stroke];
Now let's make things a little more complicated and draw a curved line with two control points. All we need to do is to replace the call to lineToPoint with a call to curveToPoint which requires two parameters. These parameters are Bezier control points and we use NSMakePoint function to create them:
[path curveToPoint: endPoint
controlPoint1: NSMakePoint ( 128, 21 )
controlPoint2: NSMakePoint ( 21,128 )];
Just like we could fill a Rect with a colour, we can fill a Path with a colour. Simply call the method fill before your call to method stroke:
[[NSColor whiteColor] set];
[path fill];
//draw the path
[path stroke];
And here is the code for creating a rectangular Path:
//create a Rect
NSPoint origin = { 21,21 };
NSRect rect;
rect.origin = origin;
rect.size.width = 128;
rect.size.height = 128;
//create the Path using a call to bezierPathWithRect method
NSBezierPath * path;
path = [NSBezierPath bezierPathWithRect:rect];
Or a circular Path:
NSBezierPath * path = [NSBezierPath bezierPath];
NSPoint center = { 128,128 };
[path moveToPoint: center];
[path appendBezierPathWithArcWithCenter: center
radius: 64
startAngle: 0
endAngle: 321];
.NET framework provides similar functionality through Point, Color and Pen classes and also families of Draw and Fill methods in the Graphics class. Here is an example in C#:
System.Drawing.Pen myPen = new System.Drawing.Pen(System.Drawing.Color.Red);
System.Drawing.Graphics formGraphics = this.CreateGraphics();
//draw line by specifying X and Y for start and end
formGraphics.DrawLine(myPen, 0, 0, 200, 200); //from (0,0) to (200,200)
//we could also use a Point object
//draw a Bezier curve using four points
formGraphics.DrawBezier(myPen, startPoint, controlPoint1, controlPoint2, endPoint);
==========
Image
==========
Next stop is the Image which probably is the most used object in 2D graphics. The NSImage class represents 2D images and handles drawing at different sizes and opacity levels, and also disk read/write. Here is how we do the two basic operations, reading from file and drawing:
//create a Rect to draw the image in
NSPoint imageOrigin = NSMakePoint(0,0);
NSSize imageSize = {100,100};
NSRect destRect;
destRect.origin = imageOrigin;
destRect.size = imageSize;
//load the image
NSString * file = @"/Library/Desktop Pictures/Plants/Leaf Curl.jpg";
NSImage * image = [[NSImage alloc] initWithContentsOfFile:file];
//draw the image into the Rect
[image drawInRect: destRect
fromRect: NSZeroRect
operation: NSCompositeSourceOver
fraction: 1.0];
One interesting part of this process is the fraction in drawInRect method which controls the opacity.
Before we draw we can "flip" the image:
[image setFlipped:YES];
This is due to the fact that views can be standard or flipped (i.e. the origin being bottom-left or top-left).
We can combine images and paths to for example draw a frame around the object. Simply add the path code after the image code.
In .NET, the Image class and DrawImage method in Graphics class provide similar functionality. For example the following code draws an image into a parallelogram (doesn't need to be a rectangle):
// Create image.
Image newImage = Image.FromFile("SampImag.jpg");
// Create parallelogram for drawing image.
Point tlCorner = new Point(100, 100); //top-left
Point trCorner = new Point(550, 100); //top-right
Point blCorner = new Point(150, 250); //bottom-left
Point[] destPara = {tlCorner, trCorner, blCorner}; //bottom-right can be calculated
// Draw image to screen.
e.Graphics.DrawImage(newImage, destPara);
For drawing, .NET support opacity levels through alpha-blending (alpha being the fourth part of a given colour after red, green, and blue). DrawImage has other versions that support image attributes (including opacity).
As we can see Cocoa and .NET provide similar functionality through similar (and sometimes a little different) ways. I'm not sure about you, but I didn't see any particular advantage in either method. There are some details in both that again are a little easier or more powerful in one or another, but for basic 2D graphics programming, so far there is no winner!
I'LL BE BACK!
We learned about some basic concepts in graphics programming last week. They were Rect, Point, and Color. This week, I introduce two new ones which are as fundamental as those: Path and Image. We will see which Cocoa (and in fact Quartz) classes control them and how.
==========
Path
==========
A Path is a line (including straight and curved lines, arcs, rectangles, etc) that is defined by points and some math to connect them. Paths can draw themselves to a view (see last week post to remember what a view is) and they can be changed or combined. NSBezierPath is the Cocoa class that represents these lines, or in general Bezier Curves (parametric curves with control points, http://en.wikipedia.org/wiki/Bezier_curve). Let's look at some examples of creating and drawing Path objects. The code can go inside the drawRect method of your view class from last week.
The first example draws a straight line between two points with a gray color:
//create start and end points
NSPoint startPoint = { 21, 21 };
NSPoint endPoint = { 128,128 };
//create the path object
//the bezierPath static method in NSBezierPath class returns a new and empty object
NSBezierPath * path = [NSBezierPath bezierPath];
//define the path's start and end, and the path type (a straight line)
[path moveToPoint: startPoint];
[path lineToPoint: endPoint];
//set the line width for drawing
[path setLineWidth: 4];
//define the current colour
[[NSColor grayColor] set];
//draw the path
[path stroke];
Now let's make things a little more complicated and draw a curved line with two control points. All we need to do is to replace the call to lineToPoint with a call to curveToPoint which requires two parameters. These parameters are Bezier control points and we use NSMakePoint function to create them:
[path curveToPoint: endPoint
controlPoint1: NSMakePoint ( 128, 21 )
controlPoint2: NSMakePoint ( 21,128 )];
Just like we could fill a Rect with a colour, we can fill a Path with a colour. Simply call the method fill before your call to method stroke:
[[NSColor whiteColor] set];
[path fill];
//draw the path
[path stroke];
And here is the code for creating a rectangular Path:
//create a Rect
NSPoint origin = { 21,21 };
NSRect rect;
rect.origin = origin;
rect.size.width = 128;
rect.size.height = 128;
//create the Path using a call to bezierPathWithRect method
NSBezierPath * path;
path = [NSBezierPath bezierPathWithRect:rect];
Or a circular Path:
NSBezierPath * path = [NSBezierPath bezierPath];
NSPoint center = { 128,128 };
[path moveToPoint: center];
[path appendBezierPathWithArcWithCenter: center
radius: 64
startAngle: 0
endAngle: 321];
.NET framework provides similar functionality through Point, Color and Pen classes and also families of Draw and Fill methods in the Graphics class. Here is an example in C#:
System.Drawing.Pen myPen = new System.Drawing.Pen(System.Drawing.Color.Red);
System.Drawing.Graphics formGraphics = this.CreateGraphics();
//draw line by specifying X and Y for start and end
formGraphics.DrawLine(myPen, 0, 0, 200, 200); //from (0,0) to (200,200)
//we could also use a Point object
//draw a Bezier curve using four points
formGraphics.DrawBezier(myPen, startPoint, controlPoint1, controlPoint2, endPoint);
==========
Image
==========
Next stop is the Image which probably is the most used object in 2D graphics. The NSImage class represents 2D images and handles drawing at different sizes and opacity levels, and also disk read/write. Here is how we do the two basic operations, reading from file and drawing:
//create a Rect to draw the image in
NSPoint imageOrigin = NSMakePoint(0,0);
NSSize imageSize = {100,100};
NSRect destRect;
destRect.origin = imageOrigin;
destRect.size = imageSize;
//load the image
NSString * file = @"/Library/Desktop Pictures/Plants/Leaf Curl.jpg";
NSImage * image = [[NSImage alloc] initWithContentsOfFile:file];
//draw the image into the Rect
[image drawInRect: destRect
fromRect: NSZeroRect
operation: NSCompositeSourceOver
fraction: 1.0];
One interesting part of this process is the fraction in drawInRect method which controls the opacity.
Before we draw we can "flip" the image:
[image setFlipped:YES];
This is due to the fact that views can be standard or flipped (i.e. the origin being bottom-left or top-left).
We can combine images and paths to for example draw a frame around the object. Simply add the path code after the image code.
In .NET, the Image class and DrawImage method in Graphics class provide similar functionality. For example the following code draws an image into a parallelogram (doesn't need to be a rectangle):
// Create image.
Image newImage = Image.FromFile("SampImag.jpg");
// Create parallelogram for drawing image.
Point tlCorner = new Point(100, 100); //top-left
Point trCorner = new Point(550, 100); //top-right
Point blCorner = new Point(150, 250); //bottom-left
Point[] destPara = {tlCorner, trCorner, blCorner}; //bottom-right can be calculated
// Draw image to screen.
e.Graphics.DrawImage(newImage, destPara);
For drawing, .NET support opacity levels through alpha-blending (alpha being the fourth part of a given colour after red, green, and blue). DrawImage has other versions that support image attributes (including opacity).
As we can see Cocoa and .NET provide similar functionality through similar (and sometimes a little different) ways. I'm not sure about you, but I didn't see any particular advantage in either method. There are some details in both that again are a little easier or more powerful in one or another, but for basic 2D graphics programming, so far there is no winner!
I'LL BE BACK!
Monday, June 7, 2010
#8, Graphics Programming, Part 2
My objective this week is to explore the basic concepts in graphics programming on OSX. I continue to use Objective-C and Cocoa framework but this time using one of the underlying APIs, Quartz. In previous posts I talked about making a simple Notepad application using Cocoa, and introduced some fundamentals such as xCode and Interface Builder. Our Notepad used an existing library object that could take care of all the text operations and the application didn't really need to do anything except some simple UI like button-click to clear the view. For our simple graphics programming example, we use another library object, Custom View that allows us to do "custom" graphics. For the simple example I only draw coloured rectangles. But first let's review some basic concepts in Quartz.
Rectangle, presented by NSRect structure (remember that Cocoa classes and structs start with NS), is an area in which 2D graphics operations are performed. It has four basic members that are x, y, width, and height. The standard coordinate system in Quartz assumes bottom-left is the origin. Many other systems (including web and Windows) consider top-left as the origin. This is called "flipped" coordinate system in Quartz and can be set if preferred. Point, presented by NSPoint, is a set of x and y values and NSColor object is a system colour.
Here are some code examples:
// make a point at coordinate 20,20
NSPoint newPoint = NSMakePoint ( 20, 20 );
// use the previous point and size to make a rect
NSRect newRect = NSMakeRect ( newPoint.x,
newPoint.y,
newSize.width,
newSize.height );
// also can just do this
NSRect newRect = NSMakeRect ( 20, 20, 100, 100 );
//make a red colour object
//create a new object by calling redColor of NSColor class
NSColor * xColor = [NSColor redColor];
Notice how C-style functions like NSMakePoint are used and well as Objective-C method calls for NSColor. This is good and also confusing!
These variables are not objects. If you need an object (and you will in some cases), you can use NSValue:
//create an object by calling valueWithRect method of NSValue class
NSValue * rectObject = [NSValue valueWithRect: newRect];
Once you have a rectangle, you can perform operations on it, such as filling the area with a colour:
//set current colour
NSColor * white = [NSColor whiteColor];
[white set];
// fill a rect
NSRect rect1 = NSMakeRect ( 21,21,210,210 );
NSRectFill ( rect1 );
You see that the NSRectFill is another C-style function that uses a rectangle and "current colour" which has to be set in advance.
Now here is the steps we go through to create our simple application (see previous posts for details of the steps we have covered before):
1- Start Xcode and make an empty Cocoa application
2- Add a new file: Cocoa classes, Objective-C class, NSView
3- Double-click on .sib or .nib file to bring up Interface Builder
4- From Library/Objects find Custom View and add to application window
5- Choose Tools > Identity Inspector and then choose your newly created view class from the menu to associate the custom view to your class
6- Make other changes like size and attributes (optional)
7- Save and exit Interface Builder
8- Back in Xcode, go to your view class and notice three methods that have been created for you. initWithFrame and isFlipped don't need to be changed
9- In drawRect method, add the following code:
NSColor * xColor = [NSColor redColor];
[xColor setFill];
NSRect xRect = NSMakeRect(0,0,100,100);
NSRectFill(xRect);
10- You may add other graphics operation here. It will be done overtime the custom view is drawn.
This is relatively straight-forward. Now let's compare with C#.NET:
1- Create an empty C# project.
2- Add a pictureBox or another view object to your form
3- Add an event handler for Paint event for that object
4- Inside event handler write the following code:
Rectangle srcRect = new Rectangle(0, 0, 100,100);
e.Graphics.FillRectangle(new SolidBrush(Color.Red), srcRect);
As you can see the process is basically the same but the C# version has some advantages:
1- You need less code
2- The view class is more easily customizable if you have meow than one custom view. In Cocoa code, if you add two custom views they both do the same thing. In .NET example, each can have its own variable name and event handler. Of course these are possible in Cocoa too but they are not the default and require extra work which I will disuse in other posts.
So far I'm still feeling the same way as before that Windows programming is more intuitive and straight-forward than OSX. Next week, I'll show some example functionality provided by Quartz which demonstrate some of its advantages. As I mentioned before despite rather cumbersome programming style, Quartz provide programmers with more built-in 2D functions than DirectX or other Windows APIs.
Well, this is it for today.
I'LL BE BACK!
Rectangle, presented by NSRect structure (remember that Cocoa classes and structs start with NS), is an area in which 2D graphics operations are performed. It has four basic members that are x, y, width, and height. The standard coordinate system in Quartz assumes bottom-left is the origin. Many other systems (including web and Windows) consider top-left as the origin. This is called "flipped" coordinate system in Quartz and can be set if preferred. Point, presented by NSPoint, is a set of x and y values and NSColor object is a system colour.
Here are some code examples:
// make a point at coordinate 20,20
NSPoint newPoint = NSMakePoint ( 20, 20 );
// use the previous point and size to make a rect
NSRect newRect = NSMakeRect ( newPoint.x,
newPoint.y,
newSize.width,
newSize.height );
// also can just do this
NSRect newRect = NSMakeRect ( 20, 20, 100, 100 );
//make a red colour object
//create a new object by calling redColor of NSColor class
NSColor * xColor = [NSColor redColor];
Notice how C-style functions like NSMakePoint are used and well as Objective-C method calls for NSColor. This is good and also confusing!
These variables are not objects. If you need an object (and you will in some cases), you can use NSValue:
//create an object by calling valueWithRect method of NSValue class
NSValue * rectObject = [NSValue valueWithRect: newRect];
Once you have a rectangle, you can perform operations on it, such as filling the area with a colour:
//set current colour
NSColor * white = [NSColor whiteColor];
[white set];
// fill a rect
NSRect rect1 = NSMakeRect ( 21,21,210,210 );
NSRectFill ( rect1 );
You see that the NSRectFill is another C-style function that uses a rectangle and "current colour" which has to be set in advance.
Now here is the steps we go through to create our simple application (see previous posts for details of the steps we have covered before):
1- Start Xcode and make an empty Cocoa application
2- Add a new file: Cocoa classes, Objective-C class, NSView
3- Double-click on .sib or .nib file to bring up Interface Builder
4- From Library/Objects find Custom View and add to application window
5- Choose Tools > Identity Inspector and then choose your newly created view class from the menu to associate the custom view to your class
6- Make other changes like size and attributes (optional)
7- Save and exit Interface Builder
8- Back in Xcode, go to your view class and notice three methods that have been created for you. initWithFrame and isFlipped don't need to be changed
9- In drawRect method, add the following code:
NSColor * xColor = [NSColor redColor];
[xColor setFill];
NSRect xRect = NSMakeRect(0,0,100,100);
NSRectFill(xRect);
10- You may add other graphics operation here. It will be done overtime the custom view is drawn.
This is relatively straight-forward. Now let's compare with C#.NET:
1- Create an empty C# project.
2- Add a pictureBox or another view object to your form
3- Add an event handler for Paint event for that object
4- Inside event handler write the following code:
Rectangle srcRect = new Rectangle(0, 0, 100,100);
e.Graphics.FillRectangle(new SolidBrush(Color.Red), srcRect);
As you can see the process is basically the same but the C# version has some advantages:
1- You need less code
2- The view class is more easily customizable if you have meow than one custom view. In Cocoa code, if you add two custom views they both do the same thing. In .NET example, each can have its own variable name and event handler. Of course these are possible in Cocoa too but they are not the default and require extra work which I will disuse in other posts.
So far I'm still feeling the same way as before that Windows programming is more intuitive and straight-forward than OSX. Next week, I'll show some example functionality provided by Quartz which demonstrate some of its advantages. As I mentioned before despite rather cumbersome programming style, Quartz provide programmers with more built-in 2D functions than DirectX or other Windows APIs.
Well, this is it for today.
I'LL BE BACK!
Wednesday, June 2, 2010
#7
Last week I was on vacation and for the first time in ages, I didn't take my laptop with me. No computer, no work, only spending time with family and some people I hadn't seen in 17 years! It was great but the result was nothing to report. So please stay tuned for next week post.
I'LL BE BACK!
I'LL BE BACK!
Thursday, May 20, 2010
#6, Introduction to Objective-C and Cocoa
This post is a couple of days early because I'm off to visit my mom all the way on the other side of the world, after 2+ years (and to see some people after 15+ years!). I'm going to talk about programming again (with you here, not with my mom). What I really wanted to do was jumping into more exciting 3D graphics programming stuff but as any of my IMD-2004 students can tell you, you have to learn to walk before you can run! So let's start with fundamentals of programming for Mac/OSX.
As I told you before, OSX programs are written on top of a set of APIs, from OpenGL to Quartz and Carbon, all the way up to Cocoa. You can write C/C++ code to work with lower level ones, but what Apple is encouraging developers to do is to use the new API, Cocoa, and its programming language, Objective-C. And I thought I'd go through them kinda from top to bottom, starting with the new kids on the block, Cocoa and Objective-C. In a matter of speaking, Apple and Microsoft went through a similar process; they both created new frameworks with new programming languages (for Microsoft it is .NET and C#), but while Cocoa is more like a high-level API on top of others like OpenGL and Quartz (although it can bypass them sometimes), .NET is a completely new application structure, kinda like a virtual machine (i.e. Windows and .NET executables have completely different formats). The differences are even more clear when it comes down to the language. Both Objective-C and C# are new languages which are not theoretically tied to Cocoa or .NET, but in practice you use Cocoa and .NET libraries for them almost always. While C# continues the well-known syntax and notations of C/C++, Objective-C defines its own new object oriented structure and syntax on top of C. To understand OSX programming, we first need to learn the language.
Before I move forward, here are a few useful links:
* http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
This is from Apple Developers' Library. Not a very good easy-to-use thing.
* http://en.wikipedia.org/wiki/Objective-C
Wikipedia is always a good for starting point
* http://cocoadevcentral.com
This is a pretty good place to start actual coding but the description is for older versions of Interface Builder (see AppController in the Cocoa section of this post)
* http://www.otierney.net/objective-c.html
This site is ok
* http://mobileappmastery.com/objective-c-tutorial
And this is not bad either
=========
Objective-C
=========
It all stated with C, the mother of all popular programming languages (in your face, Lisp programmers :-). C uses a well-known syntax and structure that many other languages adapted, such as the way functions and variables are defined. C++ is a superset of C and tries to look like C as much as possible. For example, classes look like C structures, function calls are the same way except they can have the object added before the function name, and C++ continues with the header/implementation file structure. C# and Java use many of these but they both got rid of header files ;-) Objective-C designers on the other hand made a different decision. Similar to C++ and unlike C# and Java, Objective-C is a superset of C. This means you can have C code mixed with your Objective-C code, both in the same file (.m) and as a separate file (.c). Objective-C uses the same idea of header files (.h) for class definition. But the similarity to C++ ends right there. The syntax is almost completely different. Whose brilliant idea was that? Well, if you want to get into more behind-the-scene technical stuff, the SmallTalk style is claimed to have some advantages over Simula style, such as ease of dynamic binding but I'm not buying that.
The first thing to know about Objective-C is how to define classes. Here it is:
@interface classname : baseclassname
{
// instance variables
}
+classMethod1;
+(return_type)classMethod2;
+(return_type)classMethod3:(param1_type)param1_name;
-(return_type)instanceMethod1:(param1_type)param1_name :(param2_type)param2_name;
@end
Objective-C uses the keyword interface for class, class method and instance method are the names for static and normal member functions, and are specified by + and - signs. Finally the type is inside () not the parameters which are listed after : . Here is the same code in C++:
class classname : baseclassname
{
public:
// instance variables
// Class (static) functions
static void* classMethod1();
static return_type classMethod2();
static return_type classMethod3(param1_type param1_name);
// Instance (member) functions
return_type instanceMethod1(param1_type param1_name, param2_type param2_name);
};
Here is an example with the implementation file:
//Integer.h
#import //import is the same as include
@interface Integer : Object
{
int integer;
}
- (int) integer;
- (id) integer: (int) _integer;
- (id) add: (int) _integer;
@end
//Integer.m
#import "Integer.h"
@implementation Integer
- (int) integer
{
return integer;
}
- (id) integer: (int) _integer
{
integer = _integer;
return self;
}
- (id) add: (int) _integer
{
integer += _integer;
return self;
}
- (id) hello
{
printf("hello!\n");
return self;
}
@end
Objects are instances of classes and are created using the "new" keyword:
//Objective-C: classname * objectname = [classname new];
//C++: classname * objectname = new classname;
Integer * x = [Integer new];
And finally, you access members:
//function call
Integer * x = [Integer new];
[x hello]; //calling the method "hello"
[x integer : 8]; //calling method integer with parameter 8
As you can see in the method "hello", you can use standard C (including struct) in Objective-C.
=========
Cocoa
=========
Cocoa is based on NextStep framework, hence the NS in all class names. You can use OpenGL, Quartz and other APIs from within your Cocoa application which are usually made using Xcode and Interface Builder. Now here is another strange design choice: Xcode is supposed to be an Integrated Development Environment, but Interface Builder is a separate program. When you modify your application UI in Interface Builder, you have to save it and go back to Xcode and recompile. Not to mention (again) that they are both suffering from bad UI themselves! But once you get past the UI, creating your first Cocoa application is pretty easy. Here are the steps for a simple NotePad:
1- Start Xcode and go to File/New Project
2- Select Cocoa Application, give it a name and select a location
3- Build and run your program to see an empty form (then quit the program!)
4- In Xcode, under Groups and Files, select Interface Builder Files and double-click on the one with nib extension
5- Now you are in Interface Builder and should be able to see your form (app), its menu, and the Library window, and the Document window (and possibly other things).
6- From Library, select Text View (you can search for it in the search box at the bottom of Library).
7- Drag and drop the Text View to your form and resize it if you want (notice that your menu has a Format item by default that will allow you to format text)
8- Save your Interface Builder file, go back to Xcode, build and run
If you compare this to C# and .NET, the process is pretty much the same, except that the default application in C# doesn't have a menu and formatting needs to be handled by the programmer. Although .NET framework does have classes for showing a Font box but a few lines of code are needed to create the UI objects and handling their event to show the format controls and apply the user selection.
Now let's see how we add more stuff to our simple Cocoa application. For example, we want to add a button that clears the text. Here are the steps:
1- In Xcode, click on Classes in Groups and Files window, then go to File/New File…
2- Select Objective-C Class and name it AppController. Now you have two new files AppController.h and AppController.m. This class will control an Interface Builder object in your application.
3- In AppController.h, add a variable of type IBOutlet to your class. This is a link to Interface Builder. Also add a method that's supposed to clear the text view.
@interface AppController : NSObject {
IBOutlet id textView; //outlet
}
- (IBAction) clearText: sender; //method for clearing
@end
4- In AppController.m, write the implementation of the new method.
@implementation AppController
- (IBAction) clearText: sender
{
[textView setString: @" "];
}
@end
5- Open the Interface Builder by double-clicking on the .nib file (see step 4 in for simple notepad)
6- In the Library window, select Classes, find AppController and drag/drop it to the Document window to create an instance of that class. In previous versions you need to drag AppController.h from the Xcode window and drop it on the Interface Builder document window.
7- Hold the Control key and drag/drop the AppController from Document window to the text view object in your form (design window), and select textView from the list. This was a little different in older versions of Interface Builder so be careful when you read old tutorials.
8- From Library window, under Objects, find Push Button and drag/drop it to the form. In the Attributes change the text for new button to Clear.
9- Hold the Control button and drag/drop to AppController in Document window. Select clearText.
9- Save and run a simulation of the interface (File/Simulate Interface).
10- Go back to Xcode, build and run. You should be able to type text and clear it with the button.
Now if you compare this with C#.NET, you'll see that Cocoa version is more complicated mainly because:
1- Xcode and Interface Builder are not integrated
2- In C#.NET, there is class automatically generated for you to control the form.
3- Adding a member variable for Text View and an event handler for Button are much more intuitive in C#.NET
4- You only add one line of code to the event handler to clear the text view.
To conclude, the IDE for Windows/.NET is clearly better. Cocoa does provide some basic default features that make standard tasks easier but when you get to real coding, it seems to be more complex and difficult to code. My next step is to do some 2D graphics programming. That's again one of the cases where OSX claims to have better built-in features, mostly Quartz functions. We'll see.
My #7 post will be a little late for the reason I explained at the beginning but don't worry,
I'LL BE BACK!
As I told you before, OSX programs are written on top of a set of APIs, from OpenGL to Quartz and Carbon, all the way up to Cocoa. You can write C/C++ code to work with lower level ones, but what Apple is encouraging developers to do is to use the new API, Cocoa, and its programming language, Objective-C. And I thought I'd go through them kinda from top to bottom, starting with the new kids on the block, Cocoa and Objective-C. In a matter of speaking, Apple and Microsoft went through a similar process; they both created new frameworks with new programming languages (for Microsoft it is .NET and C#), but while Cocoa is more like a high-level API on top of others like OpenGL and Quartz (although it can bypass them sometimes), .NET is a completely new application structure, kinda like a virtual machine (i.e. Windows and .NET executables have completely different formats). The differences are even more clear when it comes down to the language. Both Objective-C and C# are new languages which are not theoretically tied to Cocoa or .NET, but in practice you use Cocoa and .NET libraries for them almost always. While C# continues the well-known syntax and notations of C/C++, Objective-C defines its own new object oriented structure and syntax on top of C. To understand OSX programming, we first need to learn the language.
Before I move forward, here are a few useful links:
* http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
This is from Apple Developers' Library. Not a very good easy-to-use thing.
* http://en.wikipedia.org/wiki/Objective-C
Wikipedia is always a good for starting point
* http://cocoadevcentral.com
This is a pretty good place to start actual coding but the description is for older versions of Interface Builder (see AppController in the Cocoa section of this post)
* http://www.otierney.net/objective-c.html
This site is ok
* http://mobileappmastery.com/objective-c-tutorial
And this is not bad either
=========
Objective-C
=========
It all stated with C, the mother of all popular programming languages (in your face, Lisp programmers :-). C uses a well-known syntax and structure that many other languages adapted, such as the way functions and variables are defined. C++ is a superset of C and tries to look like C as much as possible. For example, classes look like C structures, function calls are the same way except they can have the object added before the function name, and C++ continues with the header/implementation file structure. C# and Java use many of these but they both got rid of header files ;-) Objective-C designers on the other hand made a different decision. Similar to C++ and unlike C# and Java, Objective-C is a superset of C. This means you can have C code mixed with your Objective-C code, both in the same file (.m) and as a separate file (.c). Objective-C uses the same idea of header files (.h) for class definition. But the similarity to C++ ends right there. The syntax is almost completely different. Whose brilliant idea was that? Well, if you want to get into more behind-the-scene technical stuff, the SmallTalk style is claimed to have some advantages over Simula style, such as ease of dynamic binding but I'm not buying that.
The first thing to know about Objective-C is how to define classes. Here it is:
@interface classname : baseclassname
{
// instance variables
}
+classMethod1;
+(return_type)classMethod2;
+(return_type)classMethod3:(param1_type)param1_name;
-(return_type)instanceMethod1:(param1_type)param1_name :(param2_type)param2_name;
@end
Objective-C uses the keyword interface for class, class method and instance method are the names for static and normal member functions, and are specified by + and - signs. Finally the type is inside () not the parameters which are listed after : . Here is the same code in C++:
class classname : baseclassname
{
public:
// instance variables
// Class (static) functions
static void* classMethod1();
static return_type classMethod2();
static return_type classMethod3(param1_type param1_name);
// Instance (member) functions
return_type instanceMethod1(param1_type param1_name, param2_type param2_name);
};
Here is an example with the implementation file:
//Integer.h
#import
@interface Integer : Object
{
int integer;
}
- (int) integer;
- (id) integer: (int) _integer;
- (id) add: (int) _integer;
@end
//Integer.m
#import "Integer.h"
@implementation Integer
- (int) integer
{
return integer;
}
- (id) integer: (int) _integer
{
integer = _integer;
return self;
}
- (id) add: (int) _integer
{
integer += _integer;
return self;
}
- (id) hello
{
printf("hello!\n");
return self;
}
@end
Objects are instances of classes and are created using the "new" keyword:
//Objective-C: classname * objectname = [classname new];
//C++: classname * objectname = new classname;
Integer * x = [Integer new];
And finally, you access members:
//function call
Integer * x = [Integer new];
[x hello]; //calling the method "hello"
[x integer : 8]; //calling method integer with parameter 8
As you can see in the method "hello", you can use standard C (including struct) in Objective-C.
=========
Cocoa
=========
Cocoa is based on NextStep framework, hence the NS in all class names. You can use OpenGL, Quartz and other APIs from within your Cocoa application which are usually made using Xcode and Interface Builder. Now here is another strange design choice: Xcode is supposed to be an Integrated Development Environment, but Interface Builder is a separate program. When you modify your application UI in Interface Builder, you have to save it and go back to Xcode and recompile. Not to mention (again) that they are both suffering from bad UI themselves! But once you get past the UI, creating your first Cocoa application is pretty easy. Here are the steps for a simple NotePad:
1- Start Xcode and go to File/New Project
2- Select Cocoa Application, give it a name and select a location
3- Build and run your program to see an empty form (then quit the program!)
4- In Xcode, under Groups and Files, select Interface Builder Files and double-click on the one with nib extension
5- Now you are in Interface Builder and should be able to see your form (app), its menu, and the Library window, and the Document window (and possibly other things).
6- From Library, select Text View (you can search for it in the search box at the bottom of Library).
7- Drag and drop the Text View to your form and resize it if you want (notice that your menu has a Format item by default that will allow you to format text)
8- Save your Interface Builder file, go back to Xcode, build and run
If you compare this to C# and .NET, the process is pretty much the same, except that the default application in C# doesn't have a menu and formatting needs to be handled by the programmer. Although .NET framework does have classes for showing a Font box but a few lines of code are needed to create the UI objects and handling their event to show the format controls and apply the user selection.
Now let's see how we add more stuff to our simple Cocoa application. For example, we want to add a button that clears the text. Here are the steps:
1- In Xcode, click on Classes in Groups and Files window, then go to File/New File…
2- Select Objective-C Class and name it AppController. Now you have two new files AppController.h and AppController.m. This class will control an Interface Builder object in your application.
3- In AppController.h, add a variable of type IBOutlet to your class. This is a link to Interface Builder. Also add a method that's supposed to clear the text view.
@interface AppController : NSObject {
IBOutlet id textView; //outlet
}
- (IBAction) clearText: sender; //method for clearing
@end
4- In AppController.m, write the implementation of the new method.
@implementation AppController
- (IBAction) clearText: sender
{
[textView setString: @" "];
}
@end
5- Open the Interface Builder by double-clicking on the .nib file (see step 4 in for simple notepad)
6- In the Library window, select Classes, find AppController and drag/drop it to the Document window to create an instance of that class. In previous versions you need to drag AppController.h from the Xcode window and drop it on the Interface Builder document window.
7- Hold the Control key and drag/drop the AppController from Document window to the text view object in your form (design window), and select textView from the list. This was a little different in older versions of Interface Builder so be careful when you read old tutorials.
8- From Library window, under Objects, find Push Button and drag/drop it to the form. In the Attributes change the text for new button to Clear.
9- Hold the Control button and drag/drop to AppController in Document window. Select clearText.
9- Save and run a simulation of the interface (File/Simulate Interface).
10- Go back to Xcode, build and run. You should be able to type text and clear it with the button.
Now if you compare this with C#.NET, you'll see that Cocoa version is more complicated mainly because:
1- Xcode and Interface Builder are not integrated
2- In C#.NET, there is class automatically generated for you to control the form.
3- Adding a member variable for Text View and an event handler for Button are much more intuitive in C#.NET
4- You only add one line of code to the event handler to clear the text view.
To conclude, the IDE for Windows/.NET is clearly better. Cocoa does provide some basic default features that make standard tasks easier but when you get to real coding, it seems to be more complex and difficult to code. My next step is to do some 2D graphics programming. That's again one of the cases where OSX claims to have better built-in features, mostly Quartz functions. We'll see.
My #7 post will be a little late for the reason I explained at the beginning but don't worry,
I'LL BE BACK!
Monday, May 17, 2010
#5, Ubuntu
For many people the words PC and Windows always come hand in hand. The reality is a little more complicated than that. Personal computers were smaller simpler alternatives to mainframes and mini-computers that started in 70s by Kenbak-1, Xerox Alto, Apple Macintosh, and finally IBM PC. Since the release of IBM PC (and then PC XT and PC AT), the term Personal Computer (PC) was used not for any "personal computer" but those compatible with IBM PC architecture which itself evolved through time. This hardware architecture generally used Microsoft operating systems, i.e. MS-DOS and later Windows which made the term PC synonymous to a DOS-based (and now Windows-based) personal computer. Such computers use an Intel or Intel-compatible CPU, hence the term Wintel. But even at the old DOS times, this was a rather over-simplification. Back in 80's and early 90's, while PC's were running DOS/Windows, Unix machines were usually servers, mini-computers and high-end workstations such as SUN SPARK station. But due to popularity of PC architecture, Unix community (which had many different versions, BTW) started to release PC version of their operating systems. One of the relatively successful ones was Xenix, licensed by Microsoft from AT&T in the late 70's, and later owned by Santa Cruz Operation (SCO) who released it in early 80's. But the best known version of Unix for PC is Linux, created by Linus Torvalds in early 90's as an open-source project. Linux is now freely available through many sources and companies, one of the most successful ones being Ubuntu.
Although I started my blog to mainly compare Windows and OSX, no comparison of OS choices is complete without considering Linux. That, and the fact that I didn't have time to do much testing this week, made me install Ubuntu 10.04 on a laptop and add that to my evaluation. I chose not to install it on my MBP for a couple of reasons: (1) I'm not sure if I could install it as another boot option, (2) I didn't want to test it in a virtual machine, and (3) I wanted to have a separate laptop with Linux on it (I have Linux on my media centre at home). I will probably install Ubuntu as a virtual machine on my MBP later, though.
So here are a few preliminary observations about Linux/Ubuntu:
1- It's free :-)
2- The installation is pretty straightforward and there was no problem with drivers. I installed it on 3 different machines.
3- The installation is not particularly fast. But the start-up and shutdown are faster than Windows.
4- It doesn't come with popular audio/video codecs and you have to install 3rd party components (that are available through Ubuntu Software Centre, one of the system tools)
5- I installed Eclipse. It came as an empty IDE and you had to install components for different languages. I had problem setting up those through Software Centre. I tried downloading directly but couldn't add them to Applications menu.
6- Customizing desktop (e.g. the Application menu that I just mentioned and adding shortcuts to system tools) is not very clear and easy. I couldn't set a shortcut (Launcher) to My Documents!
7- It comes with a text editor but not a good paint program (just like OSX). It does have sound recorder and video editor though.
8- Games are not good :-( I installed a couple of 3D games from Software Centre but they are rather primitive.
9- Ubuntu comes with OpenOffice which is handy.
10- Ubuntu has built-in OpenGL support.
Next week, I'm going to be on vacation so I don't expect to have any serious post till June. Till then, hope you have fun!
I'LL BE BACK
Although I started my blog to mainly compare Windows and OSX, no comparison of OS choices is complete without considering Linux. That, and the fact that I didn't have time to do much testing this week, made me install Ubuntu 10.04 on a laptop and add that to my evaluation. I chose not to install it on my MBP for a couple of reasons: (1) I'm not sure if I could install it as another boot option, (2) I didn't want to test it in a virtual machine, and (3) I wanted to have a separate laptop with Linux on it (I have Linux on my media centre at home). I will probably install Ubuntu as a virtual machine on my MBP later, though.
So here are a few preliminary observations about Linux/Ubuntu:
1- It's free :-)
2- The installation is pretty straightforward and there was no problem with drivers. I installed it on 3 different machines.
3- The installation is not particularly fast. But the start-up and shutdown are faster than Windows.
4- It doesn't come with popular audio/video codecs and you have to install 3rd party components (that are available through Ubuntu Software Centre, one of the system tools)
5- I installed Eclipse. It came as an empty IDE and you had to install components for different languages. I had problem setting up those through Software Centre. I tried downloading directly but couldn't add them to Applications menu.
6- Customizing desktop (e.g. the Application menu that I just mentioned and adding shortcuts to system tools) is not very clear and easy. I couldn't set a shortcut (Launcher) to My Documents!
7- It comes with a text editor but not a good paint program (just like OSX). It does have sound recorder and video editor though.
8- Games are not good :-( I installed a couple of 3D games from Software Centre but they are rather primitive.
9- Ubuntu comes with OpenOffice which is handy.
10- Ubuntu has built-in OpenGL support.
Next week, I'm going to be on vacation so I don't expect to have any serious post till June. Till then, hope you have fun!
I'LL BE BACK
Sunday, May 9, 2010
#4, Graphics Programming, Part 1
Graphics programming has always been a topic of interest for me as it combines two of my big passions: graphics and programming (duh!). Last week I mentioned the love I had for the miracle of digital electronics, 8051 micro-controller (In fact they were a family: 8051 was an all-in-one controller with RAM and ROM on chip; 8031 had no ROM and 8751 had EPROM). We lived happily together till mid-90s when she passed away (CPU years are even shorter than dog years!). In all that time, the only thing that came close to 8051 in my heart was the VGA card. Video Graphics Array (VGA), coming after CGA and EGA, was the first serious and worthy standard for graphics cards that allowed you to do real graphics. The EGA/VGA Programmer's Guide was my bible. It taught me the beauty of graphics done in hardware rather than software, and that is a key in the series of posts I'm going to have on the topic of graphics programming in OSX and Windows. But first, and most of this week, I have to explain some basics to make sure we are all on the same page. To those of you who already know these, sorry. Just read it as a story but don't you dare skipping ahead.
Back in the late 80s and early 90s, I was working on a real-time signal acquisition system that needed to plot the value of external signals (read through an analog-to-digital card). Kinda like what you see in the labs and hospitals. It would look like a continuously shifting plot where new data comes from one side and old data leaves from the other. This basically involves scrolling the screen. The first solution that comes to the mind of a novice programmer is to set the pixels on screen and with each new data, erase the old ones and put the new ones on, drawing the existing pixels with a shift in position. One of the earliest things you learn as a graphics programmer is that drawing pixels on screen one by one is slow. Your graphics card has a memory that holds the screen data. This memory, usually called video buffer, is not directly accessible to CPU so writing to it is slow and should be avoided as much as possible. The common technique (which my IMD-2004 students should know about) is the infamous double-buffering, i.e. using a secondary buffer in RAM (primary buffer being the one on the graphics card), drawing all pixels for a frame on the secondary buffer, and then copying the whole buffer only once. For normal operations, especially these days, this is fast enough. On our old PCs and with the real-time data we had, it wasn't. Now what this process illustrates is the graphic operation being done in software, meaning by your CPU. My first pleasant surprise with the VGA card was its ability to help you speed this up. Assuming your graphics card had more memory than needed by the screen data, you could define the starting address of the screen. Hopefully some of you can guess what this means. By changing the starting address you could scroll through data and only update the new values. I was amazed by how fast I could shift the plot on screen and it took me a while before I explained this miracle to my clueless colleagues. This was the first example I saw of doing things "in hardware" (VGA card also had the built-in support for split screens, so you could have a shifting and a static part on screen. Now that really made some other programmers jealous).
Those were of course simple examples. But that was the start of thinking about the graphics card as a processor that is capable of processing data rather than just refreshing the screen. Obviously people started to think of more advanced processing done in hardware (so your CPU time didn't have to be spent on it). In 2D graphics one example was copying multiple buffers and sprites to the graphic card and using them intelligently when needed. But the real beauty of "graphics accelerators" came with 3D. When you create a 3D world, you have XYZ values for all the points, and you define lighting, camera location and that sort of things. The image you see on screen is usually 2D though. So there is a need for some processing to map your 3D world to a 2D image. In 3D applications this mapping is called rendering (or sometimes shading although they are not exactly the same). Performing rendering in software is a time-consuming process and that's why it took the computer industry a while to have real 3D (There were cheats like the one in Doom). The real cause of advances in 3D programs was the invention of graphics cards with built-in support for 3D rendering. This support was provided to software through display drivers, the code written by hardware manufacturer that receives data and commands from software and passes them to the hardware. Eventually this resulted in Graphics Processing Unit (GPU) on graphics cards which is a real processor (now with its own programming language) that runs on the graphics card instead of the computer's motherboard.
Hold this thought for a minute.
Operating systems provide a series of software modules and standard methods for applications to use, for example for memory management, disc access, and graphics. We usually call these the Application Programming Interface (API). There are two reasons to use APIs: (1) to make it easier for programmers so they don't have to write all the code, and (2) to make sure access to system resources is done in a safe way (for example two programs don't write to each other's memory or window). In Windows the initial APIs were Win32 and display-related part of it, Graphics Device Interface (GDI). To be safe and general enough, initial graphics APIs had a lot of overhead and were quite slow. Microsoft soon realized that this can cause problem for applications that needed high-performance graphics, e.g. games. They came up with a couple of unsuccessful solutions like GameAPI, and finally developed DirectDraw, a new API that allowed direct and fast access to graphic card. It also supported new graphics accelerators which we were talking about before. DirectDraw later evolved into a set of modules called DirectX including audio, input devices, and Direct3D for 3D graphics (and also 2D in later versions by practically removing DirectDraw and having just one API sometimes called DirectX Graphics). DirectX is obviously a Windows-specific API. People in the open-source and Unix world on the other hand came up with a similar solution for 3D API called OpenGL which is now available for all major platforms and supports 2D graphics as well as 3D. Similar to Direct3D, OpenGL supports graphics accelerators too. After a couple of other approaches, Apple decided to use OpenGL as the foundation for their graphics system in Unix-based OSX. So far this means that comparing professional graphics programming in Windows and OSX comes down to comparing Direct3D and OpenGL. But there are a few complications here:
1- On Windows, you can use OpenGL or Direct3D.
2- On Windows, you can still use GDI (for apps that are not graphics-intensive).
3- On Windows (more exactly .NET framework) you may have extra APIs on top of Direct3D that simplify special things like game programming. Best example is XNA, a cross platform game development API.
4- On both Windows and OSX, you can use 3rd party APIs which in turn use native APIs of the operating system so obviously are not efficient but can be easier.
5- On Mac, OpenGL is just the start. Apple, who like Microsoft is not a big fan of open standards and interoperability (I'll talk about this general issue later), also came up with a whole series of other APIs that are OSX-specific and usually (but not always) run on top of OpenGL. These APIs are recommended methods of programming on OSX, are not portable, and have different features and performance results compared to basic OpenGL. Examples are OpenCL, Core Graphics, Core Video, Core Animation, Quartz, and Cocoa.
6- All of these APIs, as I mentioned before, are "somehow" supported on other platforms by the same company but I'm not going to get into that right now.
So what does this mean? For Windows we have standard Direct3D and Direct3D on .NET framework (I'll explain the difference shortly). For OSX we have OpenGL and all those other Apple APIs. Since OpenGL is a 3rd party add-on for Windows, I won't consider it as an option in Windows for comparison. To compare, I consider the run-time performance, complexity of programming, and available features. Finally here are some initial observations:
1- Standard Direct3D on Windows is basically a C/C++ API. When Microsoft released .NET framework as a basis for interoperability between its different platforms, they developed C# as the native language for it. Direct3D API is available for C# pretty much with the same structure as C/C++. The differences are mainly due to the differences between C# and C/C++ and usually mean the C# version is rather easier. If you go to XNA it gets even easier than that without a huge loss in performance ("huge" being the keyword here).
2- OpenGL is a portable standard. This means if you stick to it, you can compile your code for all major platforms with minimum change. On the other hand, it is more complicated compared to Direct3D and a lot more complicated compared to XNA, and it doesn't give a major performance advantage either. In fact because most hardware manufacturers consider Windows as the major non-console platform for high-performance graphics (a market thing), the Direct3D drivers are usually better than OpenGL ones which means using Direct3D is not only easier but also better performance-wise.
3- 2D Graphics APIs on OSX provide more functionality compared to Windows. Many features in Core Video, Core Animation, and Quartz are not available through Windows APIs and need extra programming and libraries. Although when it comes to 3D (e.g. games) Windows has better performance and more native features (such as XNA if we consider it native).
4- OSX C/C++ APIs are a bit more complex than the Windows ones, and considerably more complex than the .NET version.
5- As I said before, Apple is pushing for its new Cocoa framework that is based on Objective-C. I haven't had the chance to do much with it yet, but it doesn't seem to be better than the C/C++ APIs in terms of complexity or performance.
All of these are still initial observations based on typical examples like displaying an image or accessing bitmap or 3D model data. For now it seems to me that OSX provides more built-in 2D graphics features while Windows APIs have done a better job providing 3D features. In terms of code complexity and performance (specially 3D), Windows is more likely to be the winner.
My next step is focusing on 2D and 3D programming in more details, but before I finish, here are some of the new tools I found for my MBP:
1- iAntiVirus on OSX, free, for Mac-only threats so faster and lighter
2- LimeWire on OSX, free, file-sharing on Gnutella and BitTorent networks (also available on Windows)
3- HFS Explorer on Windows, free, for access to Mac HD when booting with Windows (VMWare Fusion allows such access when using virtual machine)
I'LL BE BACK!
Back in the late 80s and early 90s, I was working on a real-time signal acquisition system that needed to plot the value of external signals (read through an analog-to-digital card). Kinda like what you see in the labs and hospitals. It would look like a continuously shifting plot where new data comes from one side and old data leaves from the other. This basically involves scrolling the screen. The first solution that comes to the mind of a novice programmer is to set the pixels on screen and with each new data, erase the old ones and put the new ones on, drawing the existing pixels with a shift in position. One of the earliest things you learn as a graphics programmer is that drawing pixels on screen one by one is slow. Your graphics card has a memory that holds the screen data. This memory, usually called video buffer, is not directly accessible to CPU so writing to it is slow and should be avoided as much as possible. The common technique (which my IMD-2004 students should know about) is the infamous double-buffering, i.e. using a secondary buffer in RAM (primary buffer being the one on the graphics card), drawing all pixels for a frame on the secondary buffer, and then copying the whole buffer only once. For normal operations, especially these days, this is fast enough. On our old PCs and with the real-time data we had, it wasn't. Now what this process illustrates is the graphic operation being done in software, meaning by your CPU. My first pleasant surprise with the VGA card was its ability to help you speed this up. Assuming your graphics card had more memory than needed by the screen data, you could define the starting address of the screen. Hopefully some of you can guess what this means. By changing the starting address you could scroll through data and only update the new values. I was amazed by how fast I could shift the plot on screen and it took me a while before I explained this miracle to my clueless colleagues. This was the first example I saw of doing things "in hardware" (VGA card also had the built-in support for split screens, so you could have a shifting and a static part on screen. Now that really made some other programmers jealous).
Those were of course simple examples. But that was the start of thinking about the graphics card as a processor that is capable of processing data rather than just refreshing the screen. Obviously people started to think of more advanced processing done in hardware (so your CPU time didn't have to be spent on it). In 2D graphics one example was copying multiple buffers and sprites to the graphic card and using them intelligently when needed. But the real beauty of "graphics accelerators" came with 3D. When you create a 3D world, you have XYZ values for all the points, and you define lighting, camera location and that sort of things. The image you see on screen is usually 2D though. So there is a need for some processing to map your 3D world to a 2D image. In 3D applications this mapping is called rendering (or sometimes shading although they are not exactly the same). Performing rendering in software is a time-consuming process and that's why it took the computer industry a while to have real 3D (There were cheats like the one in Doom). The real cause of advances in 3D programs was the invention of graphics cards with built-in support for 3D rendering. This support was provided to software through display drivers, the code written by hardware manufacturer that receives data and commands from software and passes them to the hardware. Eventually this resulted in Graphics Processing Unit (GPU) on graphics cards which is a real processor (now with its own programming language) that runs on the graphics card instead of the computer's motherboard.
Hold this thought for a minute.
Operating systems provide a series of software modules and standard methods for applications to use, for example for memory management, disc access, and graphics. We usually call these the Application Programming Interface (API). There are two reasons to use APIs: (1) to make it easier for programmers so they don't have to write all the code, and (2) to make sure access to system resources is done in a safe way (for example two programs don't write to each other's memory or window). In Windows the initial APIs were Win32 and display-related part of it, Graphics Device Interface (GDI). To be safe and general enough, initial graphics APIs had a lot of overhead and were quite slow. Microsoft soon realized that this can cause problem for applications that needed high-performance graphics, e.g. games. They came up with a couple of unsuccessful solutions like GameAPI, and finally developed DirectDraw, a new API that allowed direct and fast access to graphic card. It also supported new graphics accelerators which we were talking about before. DirectDraw later evolved into a set of modules called DirectX including audio, input devices, and Direct3D for 3D graphics (and also 2D in later versions by practically removing DirectDraw and having just one API sometimes called DirectX Graphics). DirectX is obviously a Windows-specific API. People in the open-source and Unix world on the other hand came up with a similar solution for 3D API called OpenGL which is now available for all major platforms and supports 2D graphics as well as 3D. Similar to Direct3D, OpenGL supports graphics accelerators too. After a couple of other approaches, Apple decided to use OpenGL as the foundation for their graphics system in Unix-based OSX. So far this means that comparing professional graphics programming in Windows and OSX comes down to comparing Direct3D and OpenGL. But there are a few complications here:
1- On Windows, you can use OpenGL or Direct3D.
2- On Windows, you can still use GDI (for apps that are not graphics-intensive).
3- On Windows (more exactly .NET framework) you may have extra APIs on top of Direct3D that simplify special things like game programming. Best example is XNA, a cross platform game development API.
4- On both Windows and OSX, you can use 3rd party APIs which in turn use native APIs of the operating system so obviously are not efficient but can be easier.
5- On Mac, OpenGL is just the start. Apple, who like Microsoft is not a big fan of open standards and interoperability (I'll talk about this general issue later), also came up with a whole series of other APIs that are OSX-specific and usually (but not always) run on top of OpenGL. These APIs are recommended methods of programming on OSX, are not portable, and have different features and performance results compared to basic OpenGL. Examples are OpenCL, Core Graphics, Core Video, Core Animation, Quartz, and Cocoa.
6- All of these APIs, as I mentioned before, are "somehow" supported on other platforms by the same company but I'm not going to get into that right now.
So what does this mean? For Windows we have standard Direct3D and Direct3D on .NET framework (I'll explain the difference shortly). For OSX we have OpenGL and all those other Apple APIs. Since OpenGL is a 3rd party add-on for Windows, I won't consider it as an option in Windows for comparison. To compare, I consider the run-time performance, complexity of programming, and available features. Finally here are some initial observations:
1- Standard Direct3D on Windows is basically a C/C++ API. When Microsoft released .NET framework as a basis for interoperability between its different platforms, they developed C# as the native language for it. Direct3D API is available for C# pretty much with the same structure as C/C++. The differences are mainly due to the differences between C# and C/C++ and usually mean the C# version is rather easier. If you go to XNA it gets even easier than that without a huge loss in performance ("huge" being the keyword here).
2- OpenGL is a portable standard. This means if you stick to it, you can compile your code for all major platforms with minimum change. On the other hand, it is more complicated compared to Direct3D and a lot more complicated compared to XNA, and it doesn't give a major performance advantage either. In fact because most hardware manufacturers consider Windows as the major non-console platform for high-performance graphics (a market thing), the Direct3D drivers are usually better than OpenGL ones which means using Direct3D is not only easier but also better performance-wise.
3- 2D Graphics APIs on OSX provide more functionality compared to Windows. Many features in Core Video, Core Animation, and Quartz are not available through Windows APIs and need extra programming and libraries. Although when it comes to 3D (e.g. games) Windows has better performance and more native features (such as XNA if we consider it native).
4- OSX C/C++ APIs are a bit more complex than the Windows ones, and considerably more complex than the .NET version.
5- As I said before, Apple is pushing for its new Cocoa framework that is based on Objective-C. I haven't had the chance to do much with it yet, but it doesn't seem to be better than the C/C++ APIs in terms of complexity or performance.
All of these are still initial observations based on typical examples like displaying an image or accessing bitmap or 3D model data. For now it seems to me that OSX provides more built-in 2D graphics features while Windows APIs have done a better job providing 3D features. In terms of code complexity and performance (specially 3D), Windows is more likely to be the winner.
My next step is focusing on 2D and 3D programming in more details, but before I finish, here are some of the new tools I found for my MBP:
1- iAntiVirus on OSX, free, for Mac-only threats so faster and lighter
2- LimeWire on OSX, free, file-sharing on Gnutella and BitTorent networks (also available on Windows)
3- HFS Explorer on Windows, free, for access to Mac HD when booting with Windows (VMWare Fusion allows such access when using virtual machine)
I'LL BE BACK!
Sunday, May 2, 2010
#3, Development Environments
I wrote my first computer program in 1985 when I was a university freshman studying Electrical Engineering. Michael Jackson's Thriller, hair bands and breakdance were the popular things, and girls looked so colourful and had big hairs, shoulder pads, and big belts. The PC era had just started. Our school was still using IBM mainframes primarily. If you were lucky, you'd get to use a dumb terminal, a text-based IO device that connected users to the mainframe computer. The Terminal (or Console or Command Prompt) window in today's computers simulates that experience. For us poor first-years, off-line batch processing was the way. We wrote our code on a punch card machine (http://en.wikipedia.org/wiki/Punch_card). Each line of code had to be written on one card, the set of cards would then go to computer room as a "job". After the batch of jobs was processed, we would get our results as a print-out usually the next day. Imagine our disappointment when we saw a simple syntax error had wasted our whole day! BTW, my first programming language was FORTRAN. Later I moved to simple personal systems like Commodore 64 and ZX Spectrum to write and run BASIC programs in real-time (the joy of that!). By the time I got to my senior year, we were using IBM PC (8-bit XT and 16-bit AT) and I moved to Assembly programming for micro-controllers like Z80 and later my only successful love affair, 8051. MS-DOS had no GUI and we used a simple text editor and then the command-line compiler/assembler and linker. I experienced the pleasure of Integrated Development Environment (IDE) and C/C++ programming when I graduated and started working as a computer engineer. My first IDE was Borland C++. My first PC at work was a 386DX that could actually fly compared to old XT and AT. I did AutoLisp programming on it for AutoCAD. It needed 10 floppy discs to install and had a real setup program that looked so confusing to me I had to call a friend to come to our office and help me without anybody noticing. I was considered AutoCAD pro! (Nobody else knew how to write code for AutoCAD. Neither did I, but I claimed I did and I learned quickly). I saw my first OS GUI on Amiga and then Windows 3 which wasn't really an OS because you still needed DOS to boot. And so started a long journey of coding in DOS, Windows, and Unix.
Considering my history as a software programmer, naturally one of my major curiosities when I started using a Mac was related to application development. This of course was intensified by all the recent talks about Apple and application developers. I've always believed that the popularity of PCs was due to the availability of applications and ease of programming and customization (and of course lower prices). Mac became an iconic graphics workstation because of graphics software made available on it (thanks to Adobe! It seems that history has a sense of irony). It is now becoming more popular because more applications are being developed for it (not to deny other reasons). After all, applications are what we want, not computers by themselves. A smart OS/hardware company makes it as easy as possible for developers to build new applications. What I really find unacceptable about Apple's policies is the way they force developers to use Apple's technologies. I don't believe these restrictions are about, for example, Flash not being a good technology. On iPhone, developers can't use any non-Apple technology, no matter how good or bad. It is Apple's intention to keep their control over the app market, not their care for HTML5 or users. They could support other older technologies while there is no strong alternative, and let users decide for their own what they want to use. On Mac, the situation is not much different from iPhone, and Apple (just like Microsoft) is pushing for it's own proprietary technologies (Objective-C language for example) but in a less restrictive fashion than iPhone case. Anyway, my first impression of native development tools on Mac was what I wanted to talk about this week.
Let me start by giving you a kinda big picture idea first.
1- Although there are 3rd party development tools and languages (especially for web applications) such as Flash/ActionScript, the primary tools for application development are Microsoft Visual Studio and Apple Xcode.
2- Both Windows and OSX provide support for basic console applications written in standard C/C++, and also common technologies such as OpenGL. Windows no longer comes with built-in OpenGL support but the library is easily available. OSX comes with built-in OpenGL but Apple also promotes its own OpenCL.
3- Both Windows and OSX come with their own native API for multimedia and GUI programming in C/C++. These programs won't be compatible with other platforms due to the use of OS-specific libraries such as Win32/GDI and DirectX on Windows, and OpenCL, Carbon and Quartz on OSX.
4- Both Windows and OSX have offered new frameworks with their own native languages and the promise of providing more features and similar development on multiple hardware (e.g. mobile devices from the same company). These are .NET framework on Windows with C# language and Cocoa framework with Objective-C. Compact .NET and Cocoa Touch are the mobile versions of these frameworks.
For comparing Windows and OSX development tools, I use the following criteria:
1- User Interface
2- API Functionality and Complexity
3- Compatibility
4- Documentation
5- Samples
So far my review and comparison seems the easiest when it comes to development tools. Pretty much in all the above criteria, Windows is superior! This may sound too quick an opinion (and probably is). I still have a primitive knowledge of Mac development tools and frameworks, and I expect my judgment to change when I get to know them better. Also many things on Mac seem difficult due to the fact that I'm used to Windows and Visual Studio. So expect some of the following statements to be revised later, but for now here is what I've seen.
Microsoft has definitely done a good job providing easy to use development tools with lots of functionality at your finger tips. Compared to Visual Studio, Xcode looks awkward unintuitive and not integrated properly. For example Interface Builder is a separate program in Xcode. Object Browser, Class/Function/Resource Views, and Debugging tools are limited or non-existing (or well-hidden) in Xcode. Visual Studio provides way more information in the source code editor (e.g. function syntax or object members, go to definition, etc). The interface in Visual Studio is more customizable and toolbars way more effective and manageable (Xcode has only one toolbar). Even things like Find and Replace are harder to use in Xcode and not integrated well with source code editor. Visual Studio's hierarchical view from Solution (non-existing in Xcode) and Project, to File/Class/Function/Resource, and it's arrangement of Output/Find windows, are more practical.
It is too early for me to compare the full functionality and complexity of Windows and OSX APIs. Apple is pushing for Cocoa that is based on Objective-C. The C-based APIs are being removed and not supported by Xcode project wizard (you don't have them as an option for a new project). Unlike that, Visual Studio still supports a variety of applications and APIs based on C/C++. In return of using proprietary .NET and C#, Windows programmers get an easy-to-use class library and GUI for making applications. The least I can say about Cocoa and Objective-C at this time is that programming is certainly not as easy as C#, to some level because of the interface and also complexities inherited from C that don't exist in C#. Relative complexity of Objective-C comes with an advantage: it is easier to combine C and Objective-C code than it is to do so for C and C#.
As far as compatibility is concerned, Xcode and Visual Studio are not that different. Unless you do standard C/C++ or use portable libraries like OpenGL (or my favourite educational tool, Allegro), you will lose compatibility. Porting your code to other devices like smartphones is tricky in both cases. Visual Studio does provide libraries like XNA that are really cross-platform. .NET provides a certain level of code portability between Windows on PC and other Microsoft platforms. I'm not so sure about differences, for example, between Cocoa and Cocoa Touch code and how portable they are.
MSDN library is the central knowledge base for Windows and .NET programming. Compared to MSDN library, Apple's documentations for Xcode and supported APIs are weak, hard-to-use and limited. There are also much more 3rd party online support and documentation for Windows programming. Same thing applies to sample codes.
Finally, two quick general notes:
1- Mac startup is definitely faster. From power-up to successfully opening Chrome: OSX 40 seconds, Windows 80 seconds
2- Why Mac doesn't come with a simple Paint program? There are free tools though. I downloaded a decent one called Paintbrush (old name in Windows before Paint). I found Gimp a little awkward and slow. Another missing simple tool is SoundRecorder which BTW was much better in XP than the Win7/Vista version. On Mac I installed free Audacity which is more than a simple SoundRecorder but is easy to use and does the job.
My next step: working on API functionality
I'LL BE BACK!
Considering my history as a software programmer, naturally one of my major curiosities when I started using a Mac was related to application development. This of course was intensified by all the recent talks about Apple and application developers. I've always believed that the popularity of PCs was due to the availability of applications and ease of programming and customization (and of course lower prices). Mac became an iconic graphics workstation because of graphics software made available on it (thanks to Adobe! It seems that history has a sense of irony). It is now becoming more popular because more applications are being developed for it (not to deny other reasons). After all, applications are what we want, not computers by themselves. A smart OS/hardware company makes it as easy as possible for developers to build new applications. What I really find unacceptable about Apple's policies is the way they force developers to use Apple's technologies. I don't believe these restrictions are about, for example, Flash not being a good technology. On iPhone, developers can't use any non-Apple technology, no matter how good or bad. It is Apple's intention to keep their control over the app market, not their care for HTML5 or users. They could support other older technologies while there is no strong alternative, and let users decide for their own what they want to use. On Mac, the situation is not much different from iPhone, and Apple (just like Microsoft) is pushing for it's own proprietary technologies (Objective-C language for example) but in a less restrictive fashion than iPhone case. Anyway, my first impression of native development tools on Mac was what I wanted to talk about this week.
Let me start by giving you a kinda big picture idea first.
1- Although there are 3rd party development tools and languages (especially for web applications) such as Flash/ActionScript, the primary tools for application development are Microsoft Visual Studio and Apple Xcode.
2- Both Windows and OSX provide support for basic console applications written in standard C/C++, and also common technologies such as OpenGL. Windows no longer comes with built-in OpenGL support but the library is easily available. OSX comes with built-in OpenGL but Apple also promotes its own OpenCL.
3- Both Windows and OSX come with their own native API for multimedia and GUI programming in C/C++. These programs won't be compatible with other platforms due to the use of OS-specific libraries such as Win32/GDI and DirectX on Windows, and OpenCL, Carbon and Quartz on OSX.
4- Both Windows and OSX have offered new frameworks with their own native languages and the promise of providing more features and similar development on multiple hardware (e.g. mobile devices from the same company). These are .NET framework on Windows with C# language and Cocoa framework with Objective-C. Compact .NET and Cocoa Touch are the mobile versions of these frameworks.
For comparing Windows and OSX development tools, I use the following criteria:
1- User Interface
2- API Functionality and Complexity
3- Compatibility
4- Documentation
5- Samples
So far my review and comparison seems the easiest when it comes to development tools. Pretty much in all the above criteria, Windows is superior! This may sound too quick an opinion (and probably is). I still have a primitive knowledge of Mac development tools and frameworks, and I expect my judgment to change when I get to know them better. Also many things on Mac seem difficult due to the fact that I'm used to Windows and Visual Studio. So expect some of the following statements to be revised later, but for now here is what I've seen.
Microsoft has definitely done a good job providing easy to use development tools with lots of functionality at your finger tips. Compared to Visual Studio, Xcode looks awkward unintuitive and not integrated properly. For example Interface Builder is a separate program in Xcode. Object Browser, Class/Function/Resource Views, and Debugging tools are limited or non-existing (or well-hidden) in Xcode. Visual Studio provides way more information in the source code editor (e.g. function syntax or object members, go to definition, etc). The interface in Visual Studio is more customizable and toolbars way more effective and manageable (Xcode has only one toolbar). Even things like Find and Replace are harder to use in Xcode and not integrated well with source code editor. Visual Studio's hierarchical view from Solution (non-existing in Xcode) and Project, to File/Class/Function/Resource, and it's arrangement of Output/Find windows, are more practical.
It is too early for me to compare the full functionality and complexity of Windows and OSX APIs. Apple is pushing for Cocoa that is based on Objective-C. The C-based APIs are being removed and not supported by Xcode project wizard (you don't have them as an option for a new project). Unlike that, Visual Studio still supports a variety of applications and APIs based on C/C++. In return of using proprietary .NET and C#, Windows programmers get an easy-to-use class library and GUI for making applications. The least I can say about Cocoa and Objective-C at this time is that programming is certainly not as easy as C#, to some level because of the interface and also complexities inherited from C that don't exist in C#. Relative complexity of Objective-C comes with an advantage: it is easier to combine C and Objective-C code than it is to do so for C and C#.
As far as compatibility is concerned, Xcode and Visual Studio are not that different. Unless you do standard C/C++ or use portable libraries like OpenGL (or my favourite educational tool, Allegro), you will lose compatibility. Porting your code to other devices like smartphones is tricky in both cases. Visual Studio does provide libraries like XNA that are really cross-platform. .NET provides a certain level of code portability between Windows on PC and other Microsoft platforms. I'm not so sure about differences, for example, between Cocoa and Cocoa Touch code and how portable they are.
MSDN library is the central knowledge base for Windows and .NET programming. Compared to MSDN library, Apple's documentations for Xcode and supported APIs are weak, hard-to-use and limited. There are also much more 3rd party online support and documentation for Windows programming. Same thing applies to sample codes.
Finally, two quick general notes:
1- Mac startup is definitely faster. From power-up to successfully opening Chrome: OSX 40 seconds, Windows 80 seconds
2- Why Mac doesn't come with a simple Paint program? There are free tools though. I downloaded a decent one called Paintbrush (old name in Windows before Paint). I found Gimp a little awkward and slow. Another missing simple tool is SoundRecorder which BTW was much better in XP than the Win7/Vista version. On Mac I installed free Audacity which is more than a simple SoundRecorder but is easy to use and does the job.
My next step: working on API functionality
I'LL BE BACK!
Subscribe to:
Posts (Atom)