I'm lead developer for an OpenGL-based 3D engine, and I can tell you first hand...
24-bit textures remain 24-bit textures on the video card.
Texture lookups are still done in 24-bit, but the final pixel written to the framebuffer may be dithered. In fact, that is the default behaviour in OpenGL.
While almost no one runs games at 16-bit color anymore, I have our engine set to turn dithering on when the framebuffer's not full 32-bit precision and off when it is. It makes everything look a lot nicer.
Seems, to me anyway, that BitTorrent is more or less a new means of distributing illegal pirated software. I've heard of at least 3 piracy "rings" or what not who use BitTorrent as their primary means of transport.
I'm happy to hear companies like Id and Blizzard are embracing the new protocol. But by the same token, I'm concerned that promoting its use even more will expose even more people to the darker side of BitTorrent.
Of course one could argue that HTTP and FTP are also protocols used for software piracy, however, files coming over those protocols are from a SINGLE source (or potentially a mirror, but not the multitude of "mirrors" you get with a P2P protocol). It's much easier to shut those down than it is to find every single user who's sending chunks of a particular file on a P2P network.
Also, I'm not really sure BitTorrent will succede for online MMORPG BETA distribution. The problem I see is mostly, when people are done downloading their BETA installer and install the BETA they'll typically do two things...
... 1) Close BitTorrent ... 2) Delete the installer
In that scenerio, you're running low on peers to actually distribute the file after the initial surge of download activity. Anyone who misses the initial hyped download will have a hard time finding any peers to fetch from.
The actual "C" language may be declining in use. However, every single one of the "replacement" languages I've seen mentioned are simply "[subjectively] improved" modifications of C.
Personally, I rarely use the higher level versions of C like C# or Java, because my line of work requires me to interface with OpenGL and do very CPU intensive calculations. Pointer math is absolutely required to effectively utilize OpenGL's more advanced extensions such as vertex buffer objects. And you can just forget about optimizing your vector math for CPU vectorization and parallelization, etc... in languages like Java or C#.
This is not to say, however, Java and C# do not have their own benefits. When you need to write a small application (perhaps a frontend, or what not) and performance is not important, it's often faster to develop them in a higher level language. It's another instance of "the right tool for the right job".
But the low level versions of C won't be dying for a very long time, because there will always be a need for portable, high performance APIs. The APIs that your high level C languages may interface with to perform tasks you simply can't practically accomplish otherwise. And of course the actual system kernel that everything runs would never be practical in a high level language.
What's the deal with that? 1080i, 720i, 525i (what the hell is that anyway?!)... 1080i's pretty common, but I can't remember the last time
I've ever seen a 720i source or 525i for that matter.
I'd really like to see a device with DVI/Component INPUTS so you can use the tuner most cable companies provide with their HDTV service.
It's a cold day in hell when you can pick up a decent HDTV signal with just an antenna around here.
If I recall at CES this year there were at least 2 HDTV sets with built-in PVR capabilities, and they could record HDTV content.
Now that really tickles my fancy, unfortunately your options for getting the recorded content off your TV's PVR are limited:-\
$999 for an HDTV-VHS recorder (i.e. JVC HM-DH30000 ) is a little high. Seems the PC hardware approach might not be a bad idea,
ATI has new HDTV tuner hardware on the horizon. If you couple that with a huge hard drive, I'm sure you could potentially beat the over-priced JVC product by a long shot.
I know I'd certainly jump at the opportunity to buy such a device.
Unfortunately, this device isn't quite there yet. But it looks like a step in the right direction (given a decent non-proprietary PVR software environment).
But how long do we really have before TiVo and Replay embrace HDTV recording? Replay already has S/PDIF and Component OUTPUTs (even though they only have analog inputs)...
No, this comes directly from the back of my Lunar Legend instruction manual...
IMPORTANT:
WARNING: Copying of any Nintendo game is illegal and is strictly prohibited by domestic and international intellectual property laws. "Back-up" or "archival" copies are not authorized and are not necessary to protect your software. Violators will be prosecuted.
This Nintendo game is not designed for use with any unauthorized copying device or any unlicensed accessory. Use of any such device will invalidate your Nintendo product warranty. Nintendo (and/or any Nintendo licensee or distributor) is not responsible for any damage or loss caused by the use of any such device. If use of such device causes your game to stop operating, disconnect the device carefully to avoid damage and resume normal game play. If your game ceases to operate and you have no device attached please contact Nintendo Customer Service (see below).
....
Interestingly, and unrelated, I noticed Nintendo recently dropped the "quality" from the old "Nintendo Seal of Quality" emblem:)
I don't imagine the console would rasterize only even scanlines in one main loop iteration, then do the odd in the next (because you don't want anything to move around inbetween both half-frames)... The Sega Genesis for example is only capable of 320x224, which leads me to believe they use scanline doubling and simply send the front buffer contents out in two passes. If that operation is blocking you're left with only 25 and 30 updates a second respectively, because it takes 2 scans to draw a full frame.
John Carmack released a document YEARS ago explaining to hardware vendors how to optimize their OpenGL implementation for the Quake 3 engine. Such things as Vertex Array Client States (i.e. GL_VERTEX_ARRAY) never changing (always enabled), specifics for multi-texturing, vertex structure size, etc...
Given that anyone who cares to search Google for a minute or two can pull up this document (The original doc is gone:-\ - Still fun reading material though:)), I'd hardly call using it cheating. The performance DOES relate to real-world situations, as the majority of people playing Q3 Engine games don't change the name of their executable:)
What would be nice, however, is if developers had some access to this driver layer. I'm not saying anything as major as Q3's optimizations, but if a developer could tell the drivers that it won't be making any state changes to a particular attrib stack subset (i.e. GL_ALL_ATTRIB_BITS wouldn't actually push the entire stack), it'd increase render-time without any fancy 1st party vendor magic.
Also, using languages such as Cg, shader optimization is possible at run-time. I've never used it myself, I'm biased to hardware specific ASM at the moment.
Slashdot Mirror
I'm lead developer for an OpenGL-based 3D engine, and I can tell you first hand...
24-bit textures remain 24-bit textures on the video card.
Texture lookups are still done in 24-bit, but the final pixel written to the framebuffer may be dithered. In fact, that is the default behaviour in OpenGL.
While almost no one runs games at 16-bit color anymore, I have our engine set to turn dithering on when the framebuffer's not full 32-bit precision and off when it is. It makes everything look a lot nicer.
1. ATI Catalyst 2. Visual C++ 3. Intel C++ 4. VTune 5. Source Offsite 6. RenderMonkey 7. gvim 8. Mozilla 9. WinRAR 10. Pretty much in that order... :)
Seems, to me anyway, that BitTorrent is more or less a new means of distributing illegal pirated software. I've heard of at least 3 piracy "rings" or what not who use BitTorrent as their primary means of transport.
... 1) Close BitTorrent
... 2) Delete the installer
I'm happy to hear companies like Id and Blizzard are embracing the new protocol. But by the same token, I'm concerned that promoting its use even more will expose even more people to the darker side of BitTorrent.
Of course one could argue that HTTP and FTP are also protocols used for software piracy, however, files coming over those protocols are from a SINGLE source (or potentially a mirror, but not the multitude of "mirrors" you get with a P2P protocol). It's much easier to shut those down than it is to find every single user who's sending chunks of a particular file on a P2P network.
Also, I'm not really sure BitTorrent will succede for online MMORPG BETA distribution. The problem I see is mostly, when people are done downloading their BETA installer and install the BETA they'll typically do two things...
In that scenerio, you're running low on peers to actually distribute the file after the initial surge of download activity. Anyone who misses the initial hyped download will have a hard time finding any peers to fetch from.
The actual "C" language may be declining in use. However, every single one of the "replacement" languages I've seen mentioned are simply "[subjectively] improved" modifications of C. Personally, I rarely use the higher level versions of C like C# or Java, because my line of work requires me to interface with OpenGL and do very CPU intensive calculations. Pointer math is absolutely required to effectively utilize OpenGL's more advanced extensions such as vertex buffer objects. And you can just forget about optimizing your vector math for CPU vectorization and parallelization, etc... in languages like Java or C#. This is not to say, however, Java and C# do not have their own benefits. When you need to write a small application (perhaps a frontend, or what not) and performance is not important, it's often faster to develop them in a higher level language. It's another instance of "the right tool for the right job". But the low level versions of C won't be dying for a very long time, because there will always be a need for portable, high performance APIs. The APIs that your high level C languages may interface with to perform tasks you simply can't practically accomplish otherwise. And of course the actual system kernel that everything runs would never be practical in a high level language.
What's the deal with that? 1080i, 720i, 525i (what the hell is that anyway?!)... 1080i's pretty common, but I can't remember the last time
:-\
I've ever seen a 720i source or 525i for that matter.
I'd really like to see a device with DVI/Component INPUTS so you can use the tuner most cable companies provide with their HDTV service.
It's a cold day in hell when you can pick up a decent HDTV signal with just an antenna around here.
If I recall at CES this year there were at least 2 HDTV sets with built-in PVR capabilities, and they could record HDTV content.
Now that really tickles my fancy, unfortunately your options for getting the recorded content off your TV's PVR are limited
$999 for an HDTV-VHS recorder (i.e. JVC HM-DH30000 ) is a little high. Seems the PC hardware approach might not be a bad idea,
ATI has new HDTV tuner hardware on the horizon. If you couple that with a huge hard drive, I'm sure you could potentially beat the over-priced JVC product by a long shot.
I know I'd certainly jump at the opportunity to buy such a device.
Unfortunately, this device isn't quite there yet. But it looks like a step in the right direction (given a decent non-proprietary PVR software environment).
But how long do we really have before TiVo and Replay embrace HDTV recording? Replay already has S/PDIF and Component OUTPUTs (even though they only have analog inputs)...
WARNING: Copying of any Nintendo game is illegal and is strictly prohibited by domestic and international intellectual property laws. "Back-up" or "archival" copies are not authorized and are not necessary to protect your software. Violators will be prosecuted.
This Nintendo game is not designed for use with any unauthorized copying device or any unlicensed accessory. Use of any such device will invalidate your Nintendo product warranty. Nintendo (and/or any Nintendo licensee or distributor) is not responsible for any damage or loss caused by the use of any such device. If use of such device causes your game to stop operating, disconnect the device carefully to avoid damage and resume normal game play. If your game ceases to operate and you have no device attached please contact Nintendo Customer Service (see below).
Interestingly, and unrelated, I noticed Nintendo recently dropped the "quality" from the old "Nintendo Seal of Quality" emblem
I don't imagine the console would rasterize only even scanlines in one main loop iteration, then do the odd in the next (because you don't want anything to move around inbetween both half-frames)... The Sega Genesis for example is only capable of 320x224, which leads me to believe they use scanline doubling and simply send the front buffer contents out in two passes. If that operation is blocking you're left with only 25 and 30 updates a second respectively, because it takes 2 scans to draw a full frame.
Actually... This is easily explainable.
:-\ - Still fun reading material though :)), I'd hardly call using it cheating. The performance DOES relate to real-world situations, as the majority of people playing Q3 Engine games don't change the name of their executable :)
John Carmack released a document YEARS ago explaining to hardware vendors how to optimize their OpenGL implementation for the Quake 3 engine. Such things as Vertex Array Client States (i.e. GL_VERTEX_ARRAY) never changing (always enabled), specifics for multi-texturing, vertex structure size, etc...
Given that anyone who cares to search Google for a minute or two can pull up this document (The original doc is gone
What would be nice, however, is if developers had some access to this driver layer. I'm not saying anything as major as Q3's optimizations, but if a developer could tell the drivers that it won't be making any state changes to a particular attrib stack subset (i.e. GL_ALL_ATTRIB_BITS wouldn't actually push the entire stack), it'd increase render-time without any fancy 1st party vendor magic.
Also, using languages such as Cg, shader optimization is possible at run-time. I've never used it myself, I'm biased to hardware specific ASM at the moment.