Most of this information seems cut-and-pasted from MSDN or from one of the reference books the author cites at the end of the article.
I have read too many of these types of articles, and they frustrate me for several reasons.
All of the MSDN documentation would have you believe that making "portable" code (the author's word, not mine) is as simple as using TCHAR and _T macros. Reality is much different from this.
Nearly all of the localization facilities provided by MSVC are only interesting if you are willing to produce a different executable for WinNT/2K/XP than from Win95/98/ME.
In my line of work (game development) it has not been acceptable for us to have different versions of the game that try to play together on-line running on different versions of Windows, especially when they are exchanging chat traffic.
This solution to localization also presupposed that you want to use UTF-16 for Unicode encoding, and also use the UTF-16-savvy versions of the standard C-library functions to operate on UTF-16 strings.
On my most recent project, I did extensive work with Unicode, but did not use UTF-16! The only time my text was UTF-16 was in a temporary buffer because windows only provides certain APIs for converting from MBCS strings into UTF-16, which I then converted to UTF-8.
For our purposes, the TCHAR macros were completely useless: we always wanted char strings, unless we were explicitly using a UTF-16 buffer. In either case, the "size" of the characters was determined a priori, and it was never considered to "flip the switch" and compile with UNICODE defined.
If you are looking to build a single executable for all versions of Windows, I strongly recommend that you investigate using UTF-8 encoding, and throw all of the TCHAR/_T/_tcs* stuff overboard. With some careful work, you can build a single version that works on all Windows OSes, and avoid the confusion of having multiple versions of the program to support "normal" strings and "wide" strings.
I live in a heavily broadband saturated area in Southern California, and I cannot find one truth about the usage patterns in this report.
The bandwidth *does* matter; I use the broadband to download linux isos, the Cg toolkit, America's Army, anything. So does everybody I know and everybody I work with. (We're a large, well-known videogame development company)
The speed *does* matter; I use it to watch hi-quality movie trailers, news clips, and listen to music on-line.
The availability *does* matter; I leave my PC on all the time so I can have rapid access to maps, weather, geocache locations, IMDb. My wife uses the instant availability to do our banking anytime. The always-on aspect makes IM worthwhile.
We use the 'net more than ever because of the broadband. I don't think the users studied in the report reflect the majority of broadband users.
The Mac Team mostly runs 9.1, because some of the development tools we use don't run under 10 yet.
The 10.0 GUI was pretty slow, and our game ran much slower under 10.0 than under 9.1, but 10.1 seems to be much better (so they tell me; I'm working on PCs myself)
Not too off...
on
Mac Rants
·
· Score: 5, Interesting
We write video games for PCs and Macs...
The Mac Team's machines run our game noticably slower than the guys running hard-hitting Athlons, but I have a (dual) 800Mhz P3, and the G4 450's seem to keep pace with it reasonably on our game builds.
One thing I will say it this: the Mac GUI feels faster to me than the Explorer Shell on Win2K...
We use a tool called an E6B, invented originally (I think) by the army, which has a circular slide rule on one side of it.
The circular slide rule is pre-marked with conversions that are interested to pilots, such as gallons/gas->pounds and gallons/oil->pounds, and it it frequently used (in flight, with one hand) for computing distance covered.
There's a tons of other conversions, and of course, you can do any other mathematical operation that a slide rule can do.
Aviators are the only people I know who still use these slide rules -- but every student pilot where I flew was issued one and had to use it for the examinations.
I've been writing Unicode code lately (using UTF-8 encoding) and I've been reading the 3.0 standard.
The Unicode standard supports surrogates, which are pairs of 16-bit code points. These pairs defines about an additional 1 million code points within the standard. A "code point" is a unique value for some character.
There is plenty of room in the Unicode space for all the characters.
Blending on-chip is still overdraw, even if it is faster because it's on-chip. The transparent polygons also need to do all the texture lookups and lighting computations to generate the fragments that are blended into the framebuffer, so you're still hitting memory multiple times for the transparent layers. Cards that have less fill-rate bandwidth are going to do worse on scenes with more depth complexity.
The PowerVR2 chips empirically choke on large transparent textures (House of the Dead 2 on the Naomi arcade hardware, which is PowerVR2-based, is a good example), so you can draw your own conclusions as to whether or not they implemented that optimization.
Tile-based rendering only outperforms other types of rendering on certain types of tests.
Tile-based rendering's big benefit it that is reduces overdraw to 0; that is, each opaque pixel on the screen is drawn exactly once. Performance for certain types of scenes is spectacular.
Dreamcast uses this, as well as many of Sega's arcade systems (HOTD2, for instance), which use the same PowerVR2 rendering system.
Where tile-based rendering falls down, however, is for scenes that contain a large amount of alpha-blended areas. Alpha-blended areas in today's hardware are necessarily drawn multiple times, from back-to-front, to accomplish transparency effects. Having to draw the pixel several times nullifies the zero-overdraw benefit of tile rendering. Since most tile-rendering systems trade fill-rate for zero overdraw, cards with insufficient fill rate for large alpha areas (read: all of them) fall down on large, alpha blended polygons. You can see this in House of the Dead 2 when fighting the Hierophant; if you get enough water splash effects on the screen, the frame rate chokes.
Tile rendering works extremely well for areas that are opaque, or use only small alpha-blended areas. It's getting better; it's just not perfect yet.
Slashdot Mirror
This article is bupkis. ChromeOS is based on Chrome, which is based on WebKit. Seems to work just fine.
Most of this information seems cut-and-pasted from MSDN or from one of the reference books the author cites at the end of the article.
I have read too many of these types of articles, and they frustrate me for several reasons.
All of the MSDN documentation would have you believe that making "portable" code (the author's word, not mine) is as simple as using TCHAR and _T macros. Reality is much different from this.
Nearly all of the localization facilities provided by MSVC are only interesting if you are willing to produce a different executable for WinNT/2K/XP than from Win95/98/ME.
In my line of work (game development) it has not been acceptable for us to have different versions of the game that try to play together on-line running on different versions of Windows, especially when they are exchanging chat traffic.
This solution to localization also presupposed that you want to use UTF-16 for Unicode encoding, and also use the UTF-16-savvy versions of the standard C-library functions to operate on UTF-16 strings.
On my most recent project, I did extensive work with Unicode, but did not use UTF-16! The only time my text was UTF-16 was in a temporary buffer because windows only provides certain APIs for converting from MBCS strings into UTF-16, which I then converted to UTF-8.
For our purposes, the TCHAR macros were completely useless: we always wanted char strings, unless we were explicitly using a UTF-16 buffer. In either case, the "size" of the characters was determined a priori, and it was never considered to "flip the switch" and compile with UNICODE defined.
If you are looking to build a single executable for all versions of Windows, I strongly recommend that you investigate using UTF-8 encoding, and throw all of the TCHAR/_T/_tcs* stuff overboard. With some careful work, you can build a single version that works on all Windows OSes, and avoid the confusion of having multiple versions of the program to support "normal" strings and "wide" strings.
The bandwidth *does* matter; I use the broadband to download linux isos, the Cg toolkit, America's Army, anything. So does everybody I know and everybody I work with. (We're a large, well-known videogame development company)
The speed *does* matter; I use it to watch hi-quality movie trailers, news clips, and listen to music on-line.
The availability *does* matter; I leave my PC on all the time so I can have rapid access to maps, weather, geocache locations, IMDb. My wife uses the instant availability to do our banking anytime. The always-on aspect makes IM worthwhile.
We use the 'net more than ever because of the broadband. I don't think the users studied in the report reflect the majority of broadband users.
I have friends who were studying Urban Planning who were assigned homework in SimCity -- back in 1993!
The Mac Team mostly runs 9.1, because some of the development tools we use don't run under 10 yet.
The 10.0 GUI was pretty slow, and our game ran much slower under 10.0 than under 9.1, but 10.1 seems to be much better (so they tell me; I'm working on PCs myself)
The Mac Team's machines run our game noticably slower than the guys running hard-hitting Athlons, but I have a (dual) 800Mhz P3, and the G4 450's seem to keep pace with it reasonably on our game builds.
One thing I will say it this: the Mac GUI feels faster to me than the Explorer Shell on Win2K...
We use a tool called an E6B, invented originally (I think) by the army, which has a circular slide rule on one side of it.
The circular slide rule is pre-marked with conversions that are interested to pilots, such as gallons/gas->pounds and gallons/oil->pounds, and it it frequently used (in flight, with one hand) for computing distance covered.
There's a tons of other conversions, and of course, you can do any other mathematical operation that a slide rule can do.
Aviators are the only people I know who still use these slide rules -- but every student pilot where I flew was issued one and had to use it for the examinations.
Mumbly Joe
The Unicode standard supports surrogates, which are pairs of 16-bit code points. These pairs defines about an additional 1 million code points within the standard. A "code point" is a unique value for some character.
There is plenty of room in the Unicode space for all the characters.
The PowerVR2 chips empirically choke on large transparent textures (House of the Dead 2 on the Naomi arcade hardware, which is PowerVR2-based, is a good example), so you can draw your own conclusions as to whether or not they implemented that optimization.
Tile-based rendering's big benefit it that is reduces overdraw to 0; that is, each opaque pixel on the screen is drawn exactly once. Performance for certain types of scenes is spectacular.
Dreamcast uses this, as well as many of Sega's arcade systems (HOTD2, for instance), which use the same PowerVR2 rendering system.
Where tile-based rendering falls down, however, is for scenes that contain a large amount of alpha-blended areas. Alpha-blended areas in today's hardware are necessarily drawn multiple times, from back-to-front, to accomplish transparency effects. Having to draw the pixel several times nullifies the zero-overdraw benefit of tile rendering. Since most tile-rendering systems trade fill-rate for zero overdraw, cards with insufficient fill rate for large alpha areas (read: all of them) fall down on large, alpha blended polygons. You can see this in House of the Dead 2 when fighting the Hierophant; if you get enough water splash effects on the screen, the frame rate chokes.
Tile rendering works extremely well for areas that are opaque, or use only small alpha-blended areas. It's getting better; it's just not perfect yet.
Mumbly Joe