This article seems to confuse computers in the classroom with web browsing in the classroom, which is a ridiculous assumption. The article quotes Theorore Roszak: "Computers download information, he says. They do not teach children to think." Perhaps its hard for children to learn by browsing the web since web research is impeded by the low signal to noise ratio. But when I was in school we had computers with Logo and lots of students learned to combine creativity with math and logic to create very nice geometric images.
A lot of people have been saying this is a bad example because in such cases you should just choose an approriately wide type to store variables which you would like stored in smaller registers. Actually, I think this is a very good example of when a human programmer can outperform a compiler. It may be the case that a variable is declared to be of a certain type because durring most of its lifetime it can occupy the file range of that type, but a certain specific points durring execution it can be known to fit within at particiular smaller range, say 0 to 255. At this point on an x86 the upper byte of the register holding this value could be used for other purposes, until the full range of the register is required again. It may be possible to get the compiler to produce code like this with a cast, but I suspect you would end up with some ugly conversion code slowing you down. Joseph Kain
If you read the story about this on The Register it seems to indicate that this isn't the same old layering technology. The laser doesn't have to change wavelength. In fact all layers can be read at the same time.
What changed after 3dfx Open Sourced glide for V3 (its not GPL, its kinda close)? That question is complicated because a lot happened on Monday.
Here's what happened. 3dfx offered a prerelease of XFree86 4.0 with DRI support for Mesa using glide3x. All of this is new. XFree86 4.0 and DRI allow better support for Mesa rendering. Glide3x is a newer version of the Glide library. Previously only Glide2x was availiable for Linux. Glide3x is a bit different from Glide2x and they are not binarily compatible (like libc5 and glibc2.0 and glibc2.1 are not compatbile). They also aren't source compatbile but a porting job can usually be done pretty quickly.
Now for the open source. Within the same prerelease 3dfx also released the complete Glide3x source code for Voodoo3. This can be built for DRI or as a standalone API. What happened after this source release? Not much yet, its only been availiable for a few days and it took some time for people to notice it.
The new DRI release does work on Banshee. Last weekend durring testing I had some trouble with the video signal being very wiggly. However other have had a lot of success with DRI on Banshee. I invite you to try it out and see how it works. Then give us some feedback on the results in the newsgroup (3dfx.glide.linux)
For playing quake3 the currrent drivers are wonderful. This new DRI release provides several things in addition to quake3 support. The first is stability. If a glide program (and hence a program running on Mesa3D through glide) crashes it usually will not restore the 2D desktop. The DRI solutions is much better about this: it is much better at cleaning up after itself. The second new feature is rendering in a window. Now quake3 in a windows is nice but not necessary However windowed rendering is necessary for applications like Blender, or Maya. So for proper GLX support for 3D applications DRI is wonderful thing.
I helped to prepare the release, mostly packaging glide, testing the release, and updating the webpage. I have not forgotten what I tarball is, I grew up using Slackware. However, as the instructions clearly state this is a prerelease and it is targetted at RedHat 6.1. If had to test on all eleven distributions on my test machine this release won't have made it out this early.
Despite all that I know several people that have this running on Debian, using alien to convert the packages to debs. I've converted the packages to tgz files using alien as well. I've also built the entire thing from source on Slackware 7.0. Given all that I think this prerelease is in very good shape. The only major problem I've seen so far is that it won't run on Suse (The provided binaries or a build on Suse) I'll be looking into that today.
All source RPMS (Well most) have tarballs inside them. Thats how RPM works. The build systems untars your source and follows your build instructions. In fact the DRI.spec would help you figure out how to build the stuff.
This is not true. The source is a full implementation of Glide3.x fully compatibile with the windows API (Its missing a few extensions). The source will even build on Windows if you grab a couple of Windows DDK/SDK files. If you take a look at the source you'll notice that you can even adjust a few symlinks to builds a fully functional non-DRI standalone version of Glide3x. However as this is the first release of Glide3x for linux there are no Glide3x programs to run. However the Glide3x documentation is provided so you can write your own Glide3x programs. Joseph Kain
Your fingers don't move less if you are typing C code. I started learning to use a Dvorak key layout because I thought it would be cool. I began by typing text from books. I started thinking, hey this is great, it felt like I would be able to type faster and it seemed more comfortable. Then I tried writing code with it. It sucked hard. The '{' and '}' keys are too hard to get to.
I don't think we'll be dropping Linux support.
Joseph Kain
There's no C in any of that.
A lot of people have been saying this is a bad example because in such cases you should just choose an approriately wide type to store variables which you would like stored in smaller registers. Actually, I think this is a very good example of when a human programmer can outperform a compiler. It may be the case that a variable is declared to be of a certain type because durring most of its lifetime it can occupy the file range of that type, but a certain specific points durring execution it can be known to fit within at particiular smaller range, say 0 to 255. At this point on an x86 the upper byte of the register holding this value could be used for other purposes, until the full range of the register is required again. It may be possible to get the compiler to produce code like this with a cast, but I suspect you would end up with some ugly conversion code slowing you down. Joseph Kain
Joseph Kain
If you read the story about this on The Register it seems to indicate that this isn't the same old layering technology. The laser doesn't have to change wavelength. In fact all layers can be read at the same time.
http://www.lokigames.com/press/archive.php3?101119 99
Here's what happened. 3dfx offered a prerelease of XFree86 4.0 with DRI support for Mesa using glide3x. All of this is new. XFree86 4.0 and DRI allow better support for Mesa rendering. Glide3x is a newer version of the Glide library. Previously only Glide2x was availiable for Linux. Glide3x is a bit different from Glide2x and they are not binarily compatible (like libc5 and glibc2.0 and glibc2.1 are not compatbile). They also aren't source compatbile but a porting job can usually be done pretty quickly.
Now for the open source. Within the same prerelease 3dfx also released the complete Glide3x source code for Voodoo3. This can be built for DRI or as a standalone API. What happened after this source release? Not much yet, its only been availiable for a few days and it took some time for people to notice it.
Joseph Kain
The new DRI release does work on Banshee. Last weekend durring testing I had some trouble with the video signal being very wiggly. However other have had a lot of success with DRI on Banshee. I invite you to try it out and see how it works. Then give us some feedback on the results in the newsgroup (3dfx.glide.linux)
Joseph Kain
Despite all that I know several people that have this running on Debian, using alien to convert the packages to debs. I've converted the packages to tgz files using alien as well. I've also built the entire thing from source on Slackware 7.0. Given all that I think this prerelease is in very good shape. The only major problem I've seen so far is that it won't run on Suse (The provided binaries or a build on Suse) I'll be looking into that today.
Joseph Kain
All source RPMS (Well most) have tarballs inside them. Thats how RPM works. The build systems untars your source and follows your build instructions. In fact the DRI.spec would help you figure out how to build the stuff.
This is not true. The source is a full implementation of Glide3.x fully compatibile with the windows API (Its missing a few extensions). The source will even build on Windows if you grab a couple of Windows DDK/SDK files. If you take a look at the source you'll notice that you can even adjust a few symlinks to builds a fully functional non-DRI standalone version of Glide3x. However as this is the first release of Glide3x for linux there are no Glide3x programs to run. However the Glide3x documentation is provided so you can write your own Glide3x programs. Joseph Kain
Correction 3dfx is a little bit open. The specs for the 2D part on Banshee and Voodoo3 were released along with an XServer with source.
Joseph Kain