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!
Saturday, July 24, 2010
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!
Subscribe to:
Posts (Atom)