I once had to debug a program in an embedded controller - the company I worked for had this as a product that we'd written 10 years earlier - the computer that had the assembler and debugger for that controller had been hauled off for scrap years earlier and the only known copies of the source code for the program was on that machine's hard drive and on a tape backup for which we had no functioning tape drive.
Then a bug was found in a mode of operation that we'd hardly ever used before...just one day before we were planning to demo it to a customer. I had 24 hours to write a disassembler, an assembler and a simulator for the CPU - then disassemble the program, find the bug, fix it, reassemble it, test and burn new EPROM's.
The assembler was essentially just the disassembler run backwards and the disassembler was little more than a lookup table for the opcodes.
Fortunately, the bug was easy to find and I made it with just one all-nighter.
I bet they don't include any of the hilarious out-takes that the Star Wars graphics team showed at SigGraph last week. Things like:
Aniken leaping on his speeder bike (live action) - then being swapped out for a 3D graphic 'stunt double'. When the graphic Aniken zooms off on the bike, a small error in the cloth simulation leaves him naked while his cloak flutters gently (and realistically) to the ground.
So they fixed that problem - but for some reason there is a sign error on the slipstream airflow over the clothing - so his robes flip forward over his head - and he's *still* naked on a speederbike.
Or the shot of Yoda where for some unaccountable reason his clothes appear to be attacking him while he's trying to look fierce for Duku's benefit...
Or the shot of JarJar when an slight oversight caused the cloth simulation on his robes not to be run at all - so his robes are puffed up like a balloon. It looks like he's wearing a crinolin hoop-skirt.
Or the half dozen outtakes of the shot where the big guy in the diner (with four arms) is simultaneously hugging ObiWan and pulling up his pants - but the cloth simulation isn't coping well with the contact forces from his hands or his butt - so his trousers fall down in take after take after take...
Or the animation done by one of the ILM team who is now working on the Incredible Hulk movie - she is doing *ripping* cloth (huh! I wonder why?:-) but since they can't show the 3D Hulk model in public yet, they re-used an existing model. Hence the shot of Yoda ripping his clothes off. Heck, he's green - what more do you want?
Or - well, you get the idea. I guess you had to be there.:-)
The deal here is that we currently have GPU's that simply cannot implement anything like a full-up C compiler. There is no point in wishing for something that the hardware simply cannot support.
Cg doesn't have integers because GeForce chips don't implement integer math operations. There are no pointers because the hardware doesn't implement them.
So, the choice here is either to put up with a C subset that will grow with the hardware until it's not a subset anymore (and live with the consequent lack of compatibility between versions of the hardware and Cg compilers) -- OR you carry on writing GPU-based shaders in machine-code (which *also* changes with hardware versions).
We are at the very beginning of a revolution here and as such, we have to put up with some initial inconveniences.
A better debate for the/. crowd is whether we should embrace Cg now - or wait a year (or more) for the hardware to catch up with something like the OpenGL 2.0 shader language (which is very similar to Cg - but isn't implementable on most hardware...yet).
At the OpenGL Birds-of-a-Feather session at SigGraph last week, nVidia clearly expressed an interest in working with ATI and 3Dlabs on the OpenGL 2.0 standard - but those of us who need to use realtime shader languages simply cannot wait another year. I think we should expect to use Cg until something better shows up - probably in the form of the OpenGL 2.0 shader language.
One should note that the Direct3D DX-9 shader language (called HLSL by Microsoft) is basically the same thing as Cg.
We played it - it wasn't that great.
on
Virtual Sword Fighting
·
· Score: 2, Interesting
My 11 year old son and I tried this exhibit at the 'Emerging Technologies' section of SigGraph.
The headset doesn't fit well and moves around all the time. This would be OK for the usual sitting in a chair looking around" kind of VR, but when you are jumping around and spinning to see where he bad guys are coming from - it's hopeless.
Your field of view is *WAY* to narrow for fighting.
The graphics were very 1995 - it looked like they were almost an afterthought. Hardly any texture, plain green floor, crude enemy animation with red triangles for blood splotches and yellow triangles for sparks when the swords hit.
The spatialised audio didn't help in locating your enemies. People watching the show were forever shouting "He's Behing You!!" to players who couldn't see that they were being chopped to bits by enemies they couldn't see. The narrow field of view wasn't helping any.
The fancy "force feedback" sword was about as effective as a Nintendo 64 rumble-pack in conveying that you had or hadn't hit something - but that was about it.
It was a brave effort - and fun for a short time, but definitely *NOT* earth-shattering VR.
> If the patent has existed since 1986, doesn't > it expire at the end of 2003?
Probably - but that's the point. Just as with the Unisys/GIF thing - the optimum strategy for an unscrupulous company is to wait quietly for as long as they can so that the technology becomes as widespread as possible - then 'reveal' the patent while it has just enough time left to run to ensure that your victims do in fact have to license it.
There really needs to be a 'statute of limitations' on patents so that a company who doesn't enforce an obviously infringed patent can't come back 10 years later and prosecute.
It's inconceivable that these guys didn't *know* that JPEG was infringing their patent. Since they didn't do anything about it 10 years ago, this can only be a case of entrapment - and that should be illegal.
Just as with GIF, we can (presumably) dream up a patent-free lossy image compression scheme - but it'll take *years* to get that into all those browsers, paint programs, cameras and scanners.
What makes the law so iniquitous in these cases is that there is no way for a law-abiding person to abide by the law. When you invent a new file format, there is no way to search all of those billions of patents to see if you are infringing one of them. Then when you have a product out there that the patent holder is fully aware of, he says nothing until the technology is so entrenched that when he finally does pounce, you have no choice but to license it.
> I hope they're not using normal glass, which is > technically a liquid. Look at windows in colonial > houses; their bottom is thicker than their top.
> Software patents tend to very specific. Is there > no one in the open source graphics community who > can discard the MS algorithms and specifically > replace them with patent-free algorithms that are > at least nearly as good?
Not really. What's being debated is the concept of having programmable data paths in the graphics hardware. If that's what the underlying hardware *does*, you pretty much have to expose it through the API - or else you have an API that's forever frozen in about 1999 as hardware bravely advances with an interface that only D3D can use.
Think of it as if M$ had patented compiling floating point numbers. You could write compilers that would use fixed point - but they wouldn't ever run very fast because there would be all that hardware you couldn't get to. Also, your functionality would be severely impaired - you could still (in principle) write whatever programs you wanted - but it would be like being thrown back to the 1960's.
But you couldn't implement D3D under Linux without violating the very same patents that OpenGL would be violating.
Plus, there is no information on which to base these hypothetical 3D drivers. Remember, we only have nVidia drivers because nVidia provide them. Think they'd provide D3D drivers for Linux? I doubt it. ATI don't provide enough information for their hardware to allow Linux drivers that don't completely suck.
When a hardware vendor licenses OpenGL from SGI (this isn't free), he undertakes to run the official OpenGL conformance test suite - which is some humungous software package that (theoretically) tests *everything* in your driver.
Two problems with that: Firstly, no test suite can *ever* test everything - so every implementation will still have bugs. Secondly, SGI don't seem to actively monitor this compliance testing anymore. It's been said that they don't want to discourage hardware vendors from providing OpenGL drivers by being too heavy-handed about it.
It's a thin line to tread. Do you allow bad implementations to pollute the standard and thus make OpenGL unpopular with application programmers? Or do you police the standard with a rod of iron and make it too costly for hardware vendors to write allowable drivers? Either one of those policies could kill OpenGL.
It's not that it kills Xfree - it doesn't. What it does do is to put a very certain end on all hope of having hardware-accellerated 3D graphics under any OS except M$.
That completely and forever makes it possible to run modern games under Linux. We'll have 50 versions of Tetris - and that's that. That wipes out a large fraction of Linux's user-base and makes it impossible for Linux to ever become a mainstream desktop OS.
This is nothing short of a disaster - it's precisely the kind of thing that "Illegal Monopolies" are not supposed to be allowed to do.
I've always been a big time enthusiast of OpenGL - but it has to be said that with the way modern graphics cards are going, there is little to choose between the two API's anymore.
We are rapidly moving to a position where (with all the cool programmability stuff), modern programs will use the graphics API to stuff anonymous data into the graphics card - and it is the programs that run *on* the graphics card that will do the rest. The form of those graphics card programs are *IDENTICAL* for the two API's (which presumably explains how M$ come to think they own the rights to the programmability stuff that's in OpenGL without having contributed anything significant to that API).
The *BIG* issue that slashdotters need to be concerned about is that OpenGL code can be run on every computer on the planet regardless of hardware or OS - and D3D cannot.
The Parhelia's only major 'win' seems to be when it's FAA (Fragment Antialiasing) is enabled and it's competing against the nVidia and ATI's FSAA (Full Screen Antialiasing). However, this isn't an apples-and-apples comparison.
FAA (as I understand it) only antialiases the edges of polygons - hence, if two polygons intersect, the new 'edge' formed by their intersection will be totally jaggy. There are a couple of other 'paranoid' cases where it'll break too. FSAA (as it's name implies) doesn't have those kinds of restrictions.
Since FSAA basically slows the machine in proportion to the number of subsamples you render - and FAA only does that for pixels close to the polygon edges, you can see why this gives the Parhelia such an advantage.
Whether you regard this as a disgusting kludge or a clever optimisation depends a lot on your application.
It's amazing how far Matrox have come - but they needed to get this card out in time for *last* XMAS in order to have a winner.
I gotta second this one. We built our house in Texas where all but about two of the people who actually did the work didn't speak a word of English. My wife took Spanish classes just so she could talk to the workers. Beer, soft drinks, Big Mac's and Pizza were all provided - most on a daily basis. It's *DEFINITELY* worth doing that. We asked the contractor if we could have a fancy herringbone pattern worked into the brickwork under the windows - and he wanted to charge us an extra $1k for doing it...well, about $10 spent at MacDonalds got us it 'for free'.
We'd also visit the site at least daily - often to find the bricklayers sitting around because they'd run out of sand or something...it was our mobile phone that got things moving again by getting the damned contractor to get off his ass and get some delivered. Getting friendly with those guys was *well* worth it.
I designed my house on my PC using a regular CAD package - then wrote some custom 3D visualisers so I could show my wife (who doesn't "grok" 2D plans). I make models of all our furniture and placed them in-situ to verify that everything would fit and not block walkways or anything like that.
We were advised to use a professional architect to turn my plans into something that wouldn't fall down and would meet code. He charged us a small fortune to redraw my plans from scratch, and did very little to them apart from introducing some spelling errors.
The details of construction methods that the architect added to my plans were *ignored* by the contractor - the direction that floor joists run and where the air conditioning ducts go bears *no* resemblance to the plans. We carefully worked out where all the light switches, electrical outlets, phones and 10baseT's would go - and they were right there on all the plans...But on the day the electrician appeared, he just asked us to go round and mark where we wanted things with a spray can - he didn't even *want* a set of plans!
The contractor was similarly a waste of money. I visited the building site daily...sometimes twice daily - and measured *everything* they did. Despite that, two subtle dimensional errors crept in - one of which completely fsck'ed up my ergonomic kitchen layout by forcing me to put the refrigerator somewhere other than where I wanted it. We hadn't noticed until the day we moved in and by then it was far to late to do anything about it. An error of just a couple of inches is enough to do that - so CHECK EVERYTHING CAREFULLY!!
We went with a fixed price contract - which was a good idea because it prevented him from screwing us for every little problem - however it also resulted in some running battles.
Take for example, the driveway. We wanted it to be flat along one section and slope upwards a little later because we knew that in the future, we'd want an extra parking place next to the flat part. However, to do that required moving a lot of dirt - and the plans didn't show where the driveway sloped. The contractor argued that his contract didn't require him to move the dirt - and it would cost us money we didn't have to change that.
So now we have a sloping parking place. (Grrrr!)
On the whole though, the process was rather enjoyable - and our house is pretty damned amazing for the money we paid.
Next time (surely a *LONG* way off!) I'll dump the contractor and the architect. I don't think I could do better than they did - but I think that an intelligent person will do no worse so you might as well save the money and use it to pay for any little mistakes you might happen to make.
You can download the Linux version of Cg now... so at least they appear to be telling the truth about that. There was also a comment somewhere about them OpenSourcing Cg sometime soon.
This doesn't appear to have the long shadow of Microsoft cast over it.
I build all my own PC's too - and I agree that they always come out cheaper than a pre-built box but that's generally because I'm bringing in a lot of parts from my previous-but-one machine.
You never need a new modem or a NIC, you probably don't buy a new keyboard or mouse...who cares whether you have an x24 or x48 CD-ROM?...Stuff like that adds up fast.
I suspect that if you started from *nothing* and had to buy all the cables and all the other junk, it probably would be cheaper to grab a Dell and toss out the M$ software without agreeing to the EULA by turning it on.
Dunno - I've had troubles for the last 15 years - doctors can cure the symptoms and get me back to work after about 10 days of rest...but they can't get rid of the problem permenantly.
Egonomic adjustments? Well, they are certainly important too - but I've had experts come into my work area and measure everything - the conclusion is that I've had it correctly set up for *years* and I'm still having periodic trouble - so it isn't that.
I take frequent breaks - so it isn't that.
The *ONLY* thing which has dramatically lessened the problems was switching to a 'split' style keyboard. Not one of the radically silly ones - just a standard Microsoft or Micro Innovations split board. It hasn't gotten rid of the problem 100% - but I only suffer enough to lose time from work maybe once every couple of years.
So, for one victim at least, going to an ergonomic keyboard has been the only thing that's actually provided some long term help (although it's still not a 100% fix).
However, it's very clear that not everyone shares the exact same symptoms or the exact same causes - and the exact same cure won't work for everyone either.
My advice to victims (and I'm not a doctor) is to do ALL of the following:
1) As soon as you get any symptoms at all. STOP TYPING! You can't "work through the pain" - it'll only get worse and harder to treat.
2) Get a qualified ergonomics expert to look at your work area. Take all of the advice you can - but don't be afraid to ask for explanations for why they are making those recommendations.
3) Get a split keyboard of some kind.
4) If you do get real pain, go to a doctor. Take time off work - veg out in front of a TV for a week.
* It's not legal to copy a $10 bill 'for your
personal use' - so preventing it from being
copied doesn't impinge on peoples rights.
* There is no legal use for a copy of a $10,
where there are plenty of legal uses for a
copy of a CD.
* Adding copy protection to a $10 doesn't
degrade it's worth - adding a watermark
to a CD does degrade it's sound quality.
* If photocopiers had to be modified in order
to prevent them from copying currency, we
might still have qualms about doing that
modification.
* Copying a $10 harms everyone since it devalues
everyone's money. Copying a CD only harms a
small subset of the population. Hence, there
could be an agument of "Greatest good for
greatest number".
* The only function of a $10 bill is to be a
token that's uncopyable. Almost every aspect
of it can be designed for copy protection
without degrading it's usefulness in any way.
A CD has a completely separate function (to
carry audio) - and modifying that to make it
uncopyable is an ancilliary function.
Or pretty much any modern Radio or TV station. Trying to play any watermarked material on-air would almost certainly fail - there must be lots of digital stages in the transmission pathway.
Then inside my TV, my surround-sound home theatre, you name it. This would (in effect) force all devices that accept analog inputs to use *only* analog processing in their internals - and that's just plain silly!
This should do bad things for PVR's too - but I guess that's not considered A Bad Thing by the proponents.
> How hard can it be to simply build a decent converter from scratch? Or, > is this an unusually difficult task?
Take a D-to-A converter - and wire it up to an analog comparator. The comparator outputs (say) a '1' when the incoming analog signal is larger than the output of the D-to-A, '0' when it's smaller.
Now, connect up a counter to the input of the D-to-A. Arrange for the counter to start at zero and gradually increase the voltage coming out of the D-to-A until the comparator says '0'.
Note the value of the counter...that's the measure of the incoming voltage.
Then reset the counter and do it all over again.
...only do it MUCH faster than that!:-)
A counter could be a piece of software and a D-to-A converter could be a bunch of resistors soldered across your parallel port - or it could be the output of your sound card. An analog comparator can be a diode.
This approach works OK for audio signals - but it would be hard to make it work at video frequencies. However, there are plenty of other ways to build an A-to-D, but I rather like the elegance of the one I just described.
You can build an A-to-D converter using a D-to-A converter, a counter, and an analog comparator.
It's hard to see how this law could prevent such devices from being built successfully.
So once again, we have a "solution" that doesn't prevent the *genuine* bad-guy mass-piracy problems - but does take existing rights away from the casual user.
If this gets through it's proof that our lawmakers are either utterly corrupt or terminally stupid - either way, you know how to vote.
Slashdot Mirror
I once had to debug a program in an embedded controller - the company I
worked for had this as a product that we'd written 10 years earlier - the
computer that had the assembler and debugger for that controller had been
hauled off for scrap years earlier and the only known copies of the source
code for the program was on that machine's hard drive and on a tape backup
for which we had no functioning tape drive.
Then a bug was found in a mode of operation that we'd hardly ever used
before...just one day before we were planning to demo it to a customer. I
had 24 hours to write a disassembler, an assembler and a simulator for the
CPU - then disassemble the program, find the bug, fix it, reassemble it, test
and burn new EPROM's.
The assembler was essentially just the disassembler run backwards and the
disassembler was little more than a lookup table for the opcodes.
Fortunately, the bug was easy to find and I made it with just one all-nighter.
I bet they don't include any of the hilarious out-takes that the Star Wars graphics team showed at SigGraph last week. Things like:
:-) but since they can't show the 3D Hulk model in public yet, they re-used an existing model. Hence the shot of Yoda ripping his clothes off. Heck, he's green - what more do you want?
:-)
Aniken leaping on his speeder bike (live action) - then being swapped out for a 3D graphic 'stunt double'. When the graphic Aniken zooms off on the bike, a small error in the cloth simulation leaves him naked while his cloak flutters gently (and realistically) to the ground.
So they fixed that problem - but for some reason there is a sign error on the slipstream airflow over the clothing - so his robes flip forward over his head - and he's *still* naked on a speederbike.
Or the shot of Yoda where for some unaccountable reason his clothes appear to be attacking him while he's trying to look fierce for Duku's benefit...
Or the shot of JarJar when an slight oversight caused the cloth simulation on his robes not to be run at all - so his robes are puffed up like a balloon. It looks like he's wearing a crinolin hoop-skirt.
Or the half dozen outtakes of the shot where the big guy in the diner (with four arms) is simultaneously hugging ObiWan and pulling up his pants - but the cloth simulation isn't coping well with the contact forces from his hands or his butt - so his trousers fall down in take after take after take...
Or the animation done by one of the ILM team who is now working on the Incredible Hulk movie - she is doing *ripping* cloth (huh! I wonder why?
Or - well, you get the idea. I guess you had to be there.
Actually, the ones in Episode II (which are called AT-TE's) are the closest
because they have six legs. The AT-AT's had four and the AT-ST's only two.
> I also found it intesting that everyone who played won.
:-(
I didn't.
So evidently you *could* lose - if you were enough of a Klutz with a sword. I agree though that *most* people won.
The deal here is that we currently have GPU's that simply cannot implement anything like a full-up C compiler. There is no point in wishing for something that the hardware simply cannot support.
/. crowd is whether we should embrace Cg now - or wait a year (or more) for the hardware to catch up with something like the OpenGL 2.0 shader language (which is very similar to Cg - but isn't implementable on most hardware...yet).
Cg doesn't have integers because GeForce chips don't implement integer math operations. There are no pointers because the hardware doesn't implement them.
So, the choice here is either to put up with a C subset that will grow with the hardware until it's not a subset anymore (and live with the consequent lack of compatibility between versions of the hardware and Cg compilers) -- OR you carry on writing GPU-based shaders in machine-code (which *also* changes with hardware versions).
We are at the very beginning of a revolution here and as such, we have to put up with some initial inconveniences.
A better debate for the
At the OpenGL Birds-of-a-Feather session at SigGraph last week, nVidia clearly expressed an interest in working with ATI and 3Dlabs on the OpenGL 2.0 standard - but those of us who need to use realtime shader languages simply cannot wait another year. I think we should expect to use Cg until something better shows up - probably in the form of the OpenGL 2.0 shader language.
One should note that the Direct3D DX-9 shader language (called HLSL by Microsoft) is basically the same thing as Cg.
My 11 year old son and I tried this exhibit at the 'Emerging Technologies' section of SigGraph.
The headset doesn't fit well and moves around all the time. This would be OK for the usual sitting in a chair looking around" kind of VR, but when you are jumping around and spinning to see where he bad guys are coming from - it's hopeless.
Your field of view is *WAY* to narrow for fighting.
The graphics were very 1995 - it looked like they were almost an afterthought. Hardly any texture, plain green floor, crude enemy animation with red triangles for blood splotches and yellow triangles for sparks when the swords hit.
The spatialised audio didn't help in locating your enemies. People watching the show were forever shouting "He's Behing You!!" to players who couldn't see that they were being chopped to bits by enemies they couldn't see. The narrow field of view wasn't helping any.
The fancy "force feedback" sword was about as effective as a Nintendo 64 rumble-pack in conveying that you had or hadn't hit something - but that was about it.
It was a brave effort - and fun for a short time, but definitely *NOT* earth-shattering VR.
> If the patent has existed since 1986, doesn't
> it expire at the end of 2003?
Probably - but that's the point. Just as with the Unisys/GIF thing - the optimum strategy for an unscrupulous company is to wait quietly for as long as they can so that the technology becomes as widespread as possible - then 'reveal' the patent while it has just enough time left to run to ensure that your victims do in fact have to license it.
There really needs to be a 'statute of limitations' on patents so that a company who doesn't enforce an obviously infringed patent can't come back 10 years later and prosecute.
It's inconceivable that these guys didn't *know* that JPEG was infringing their patent. Since they didn't do anything about it 10 years ago, this can only be a case of entrapment - and that should be illegal.
Just as with GIF, we can (presumably) dream up a patent-free lossy image compression scheme - but it'll take *years* to get that into all those browsers, paint programs, cameras and scanners.
What makes the law so iniquitous in these cases is that there is no way for a law-abiding person to abide by the law. When you invent a new file format, there is no way to search all of those billions of patents to see if you are infringing one of them. Then when you have a product out there that the patent holder is fully aware of, he says nothing until the technology is so entrenched that when he finally does pounce, you have no choice but to license it.
> I hope they're not using normal glass, which is
> technically a liquid. Look at windows in colonial
> houses; their bottom is thicker than their top.
Think "Zero-G".
> Software patents tend to very specific. Is there
> no one in the open source graphics community who
> can discard the MS algorithms and specifically
> replace them with patent-free algorithms that are
> at least nearly as good?
Not really. What's being debated is the concept of
having programmable data paths in the graphics
hardware. If that's what the underlying hardware *does*, you pretty much have to expose it through the API - or else you have an API that's forever frozen in about 1999 as hardware bravely advances with an interface that only D3D can use.
Think of it as if M$ had patented compiling floating point numbers. You could write compilers that would use fixed point - but they wouldn't ever run very fast because there would be all that hardware you couldn't get to. Also, your functionality would be severely impaired - you could still (in principle) write whatever programs you wanted - but it would be like being thrown back to the 1960's.
That's the kind of scale of event we have here.
But you couldn't implement D3D under Linux without
violating the very same patents that OpenGL would be violating.
Plus, there is no information on which to base these hypothetical 3D drivers. Remember, we only have nVidia drivers because nVidia provide them. Think they'd provide D3D drivers for Linux? I doubt it. ATI don't provide enough information for their hardware to allow Linux drivers that don't completely suck.
When a hardware vendor licenses OpenGL from SGI (this isn't free), he undertakes to run the official OpenGL conformance test suite - which is some humungous software package that (theoretically) tests *everything* in your driver.
Two problems with that: Firstly, no test suite can *ever* test everything - so every implementation will still have bugs. Secondly, SGI don't seem to actively monitor this compliance testing anymore. It's been said that they don't want to discourage hardware vendors from providing OpenGL drivers by being too heavy-handed about it.
It's a thin line to tread. Do you allow bad implementations to pollute the standard and thus make OpenGL unpopular with application programmers? Or do you police the standard with a rod of iron and make it too costly for hardware vendors to write allowable drivers? Either one of those policies could kill OpenGL.
It's not that it kills Xfree - it doesn't. What it does do is to put a very certain end on all hope of having hardware-accellerated 3D graphics under any OS except M$.
That completely and forever makes it possible to run modern games under Linux. We'll have 50 versions of Tetris - and that's that. That wipes out a large fraction of Linux's user-base and makes it impossible for Linux to ever become a mainstream desktop OS.
This is nothing short of a disaster - it's precisely the kind of thing that "Illegal Monopolies" are not supposed to be allowed to do.
I've always been a big time enthusiast of OpenGL - but it has to be said that with the way modern graphics cards are going, there is little to choose between the two API's anymore.
We are rapidly moving to a position where (with all the cool programmability stuff), modern programs will use the graphics API to stuff anonymous data into the graphics card - and it is the programs that run *on* the graphics card that will do the rest. The form of those graphics card programs are *IDENTICAL* for the two API's (which presumably explains how M$ come to think they own the rights to the programmability stuff that's in OpenGL without having contributed anything significant to that API).
The *BIG* issue that slashdotters need to be concerned about is that OpenGL code can be run on every computer on the planet regardless of hardware or OS - and D3D cannot.
The Parhelia's only major 'win' seems to be when
it's FAA (Fragment Antialiasing) is enabled and it's
competing against the nVidia and ATI's FSAA (Full
Screen Antialiasing). However, this isn't an
apples-and-apples comparison.
FAA (as I understand it) only antialiases the
edges of polygons - hence, if two polygons
intersect, the new 'edge' formed by their
intersection will be totally jaggy. There are
a couple of other 'paranoid' cases where it'll
break too. FSAA (as it's name implies) doesn't
have those kinds of restrictions.
Since FSAA basically slows the machine in
proportion to the number of subsamples you
render - and FAA only does that for pixels
close to the polygon edges, you can see why
this gives the Parhelia such an advantage.
Whether you regard this as a disgusting
kludge or a clever optimisation depends
a lot on your application.
It's amazing how far Matrox have come - but
they needed to get this card out in time for
*last* XMAS in order to have a winner.
(Also - no sign of any Linux drivers - Booo!)
I gotta second this one. We built our house in Texas where all but about two of the people who actually did the work didn't speak a word of English. My wife took Spanish classes just so she could talk to the workers. Beer, soft drinks, Big Mac's and Pizza were all provided - most on a daily basis. It's *DEFINITELY* worth doing that. We asked the contractor if we could have a fancy herringbone pattern worked into the brickwork under the windows - and he wanted to charge us an extra $1k for doing it...well, about $10 spent at MacDonalds got us it 'for free'.
We'd also visit the site at least daily - often to find the bricklayers sitting around because they'd run out of sand or something...it was our mobile phone that got things moving again by getting the damned contractor to get off his
ass and get some delivered. Getting friendly with those guys was *well* worth it.
I designed my house on my PC using a regular CAD package - then wrote some custom 3D visualisers so I could show my wife (who doesn't "grok" 2D plans). I make models of all our furniture and placed them in-situ to verify that everything would fit and not block walkways or anything like that.
We were advised to use a professional architect to turn my plans into something that wouldn't fall down and would meet code. He charged us a small fortune to redraw my plans from scratch, and did very little to them apart from introducing some spelling errors.
The details of construction methods that the architect added to my plans were *ignored* by the contractor - the direction that floor joists run and where the air conditioning ducts go bears *no* resemblance to the plans. We carefully worked out where all the light switches, electrical outlets, phones and 10baseT's would go - and they were right there on all the plans...But on the day the electrician appeared, he just asked us to go round and mark where we wanted things with a spray can - he didn't even *want* a set of plans!
The contractor was similarly a waste of money. I visited the building site daily...sometimes twice daily - and measured *everything* they did. Despite that, two subtle dimensional errors crept in - one of which completely fsck'ed up my ergonomic kitchen layout by forcing me to put the refrigerator somewhere other than where I wanted it. We hadn't noticed until the day we moved in and by then it was far to late to do anything about it. An error of just a couple of inches is enough to do that - so CHECK EVERYTHING CAREFULLY!!
We went with a fixed price contract - which was a good idea because it prevented him from screwing us for every little problem - however it also resulted in some running battles.
Take for example, the driveway. We wanted it to be flat along one section and slope upwards a little later because we knew that in the future, we'd want an extra parking place next to the flat part. However, to do that required moving a lot of dirt - and the plans didn't show where the driveway sloped. The contractor argued that his contract didn't require him to move the dirt - and it would cost us money we didn't have to change that.
So now we have a sloping parking place. (Grrrr!)
On the whole though, the process was rather enjoyable - and our house is pretty damned amazing for the money we paid.
Next time (surely a *LONG* way off!) I'll dump the contractor and the architect. I don't think I could do better than they did - but I think that an intelligent person will do no worse so you might as well save the money and use it to pay for any little mistakes you might happen to make.
You can download the Linux version of Cg now...
so at least they appear to be telling the truth
about that. There was also a comment somewhere
about them OpenSourcing Cg sometime soon.
This doesn't appear to have the long shadow
of Microsoft cast over it.
I build all my own PC's too - and I agree that
...Stuff
they always come out cheaper than a pre-built box
but that's generally because I'm bringing in a lot
of parts from my previous-but-one machine.
You never need a new modem or a NIC, you probably
don't buy a new keyboard or mouse...who cares
whether you have an x24 or x48 CD-ROM?
like that adds up fast.
I suspect that if you started from *nothing* and
had to buy all the cables and all the other junk,
it probably would be cheaper to grab a Dell and
toss out the M$ software without agreeing to
the EULA by turning it on.
What? Nobody suggested making a beowulf
cluster of these? If you networked about
a million of them, you could maybe emulate
a Pentium.
Since we get the sources (this is guaranteed by
GPL), we can reconstruct the base CD-ROM...exactly
if need be.
Hence, all this 'per-seat' licensing is getting
you is the *name* 'UnitedLinux'.
So, we make this reconstructed CD be called something catchy (how about 'StandardLinux') - and
bye-bye per-seat licensing.
Or we can just call it "Debian" and not bother.
Dunno - I've had troubles for the last 15 years - doctors can cure the symptoms and get me back to work after about 10 days of rest...but they can't get rid of the problem permenantly.
Egonomic adjustments? Well, they are certainly important too - but I've had experts come into my work area and measure everything - the conclusion is that I've had it correctly set up for *years* and I'm still having periodic trouble - so it isn't that.
I take frequent breaks - so it isn't that.
The *ONLY* thing which has dramatically lessened the problems was switching to a 'split' style keyboard. Not one of the radically silly ones - just a standard Microsoft or Micro Innovations split board. It hasn't gotten rid of the problem 100% - but I only suffer enough to lose time from work maybe once every couple of years.
So, for one victim at least, going to an ergonomic keyboard has been the only thing that's actually provided some long term help (although it's still not a 100% fix).
However, it's very clear that not everyone shares the exact same symptoms or the exact same causes - and the exact same cure won't work for everyone either.
My advice to victims (and I'm not a doctor) is to do ALL of the following:
1) As soon as you get any symptoms at all. STOP TYPING! You can't "work through the pain" - it'll only get worse and harder to treat.
2) Get a qualified ergonomics expert to look at your work area. Take all of the advice you can - but don't be afraid to ask for explanations for why they are making those recommendations.
3) Get a split keyboard of some kind.
4) If you do get real pain, go to a doctor. Take time off work - veg out in front of a TV for a week.
But above all: YMMV.
There are *significant* differences here.
* It's not legal to copy a $10 bill 'for your
personal use' - so preventing it from being
copied doesn't impinge on peoples rights.
* There is no legal use for a copy of a $10,
where there are plenty of legal uses for a
copy of a CD.
* Adding copy protection to a $10 doesn't
degrade it's worth - adding a watermark
to a CD does degrade it's sound quality.
* If photocopiers had to be modified in order
to prevent them from copying currency, we
might still have qualms about doing that
modification.
* Copying a $10 harms everyone since it devalues
everyone's money. Copying a CD only harms a
small subset of the population. Hence, there
could be an agument of "Greatest good for
greatest number".
* The only function of a $10 bill is to be a
token that's uncopyable. Almost every aspect
of it can be designed for copy protection
without degrading it's usefulness in any way.
A CD has a completely separate function (to
carry audio) - and modifying that to make it
uncopyable is an ancilliary function.
Hence, I don't see this as a valid analogy.
Or pretty much any modern Radio or TV station.
Trying to play any watermarked material on-air
would almost certainly fail - there must be
lots of digital stages in the transmission pathway.
Then inside my TV, my surround-sound home
theatre, you name it. This would (in effect)
force all devices that accept analog inputs
to use *only* analog processing in their
internals - and that's just plain silly!
This should do bad things for PVR's too - but
I guess that's not considered A Bad Thing by
the proponents.
> How hard can it be to simply build a decent converter from scratch? Or,
:-)
> is this an unusually difficult task?
Take a D-to-A converter - and wire it up to
an analog comparator. The comparator outputs
(say) a '1' when the incoming analog signal is
larger than the output of the D-to-A, '0' when
it's smaller.
Now, connect up a counter to the input of the
D-to-A. Arrange for the counter to start at
zero and gradually increase the voltage coming
out of the D-to-A until the comparator says '0'.
Note the value of the counter...that's the
measure of the incoming voltage.
Then reset the counter and do it all over again.
...only do it MUCH faster than that!
A counter could be a piece of software and a
D-to-A converter could be a bunch of resistors
soldered across your parallel port - or it
could be the output of your sound card. An
analog comparator can be a diode.
This approach works OK for audio signals - but
it would be hard to make it work at video
frequencies. However, there are plenty of
other ways to build an A-to-D, but I rather
like the elegance of the one I just described.
In short - "No, it's not unusually difficult".
You can build an A-to-D converter using a
D-to-A converter, a counter, and an analog comparator.
It's hard to see how this law could prevent
such devices from being built successfully.
So once again, we have a "solution" that doesn't
prevent the *genuine* bad-guy mass-piracy
problems - but does take existing rights away
from the casual user.
If this gets through it's proof that our
lawmakers are either utterly corrupt or
terminally stupid - either way, you know how
to vote.