I thought display pdf was also actualy sending pdf code to the window server, and pdf code just happened to be a lighter weight subset of postscript (pretty much postscript minus the programability). And I admit, messed up, Xdps wasn't until openstep but the point still stands that it's an existing system that proven workable that gives you the best of both worlds.
Also, I may be mistaken but I was pretty sure the quartxz windowserver got vector commands in some sort of protocal form (like pdf). Apps would send commands like "create an spline with these coordinates and assign it object name blah" and then allow the app to do resolution independant displays and deformations of that object just referencing it by name. Mind you I've never programmed for quartz so I may be talking out of my ass. Render on the other hand only does deformation and displays of pixmaps like you said, (or static color areas, which is where its power to composite objects out of these color areas comes in).
Anyways, the point was originally that with not too much more effort X can do all this without giving up the remote display, backward compatibility, extensibility and platform independance that we all love (or at least I do....I know there are X haters out there).
Quartz is based off a technology that was originally designed to be an extension to X. Mind you apple didn't implement it that way, but Xdps is in the works which will allow X apps to define a display postscript visual (which is actually more capable than display pdf, apple used the pdf subset of postscript so as not to pay royalties to adobe) and have all the compositing, path based, and vector capabilites of OSX, along with the extensibility of postscript, encapsulated in an X window that has all the features of X.
Or you could use X render which allows all of this to be easily implemented very efficiently in client side libraries. Basically the X framework is powerfull enough to give you choice and see which method works best.
Well for the multiplayer, RTCW is only teamwork based. Its actually team and class oriented (kinda like team fortress, except you can change classes with each respawn). I'm only pointing this out because I really like RTCW's multiplayer, and I'm dissapointed at how few servers there are for it relatively. CS is definitely a good game, but I just kinda got tired of playing dust over and over. Now the question is when I'll get sick of playing beach over and over...
Theoretically the mass of the galaxy itself should be enough to hold it together. Even the black hole could have originally been formed from matter collecting at the center of gravity of the galaxy.
Except not. The cards actually have an incredibly high detailed barcode that stores 2k per strip (two strips per card) and with four or five cards you can store an original nintendo game.
Technology *has* progressed. The HuCards were rom chips in a card package. Look inside a genesis cart, its mostly air. If they had chosen to they could have put those on "cards". The cards this article is referring to are cardboard trading-card sized cards with an incredibly detailed barcode on one side (so detailed that the individual dots aren't distinguishable by eye). The e-reader actually scans them with a laser and stores the program in flash on the reader and runs it from there. So yeah, yesterdays games which used to be on huge cartridges (these will be original NES games so really huge) are now represented by dots of ink.
The 8500 driver *is* just a rebranded fireGL driver, and it wasn't even rebranded until just a month ago. Not only that, it doesn't really work all that well. The fireGL and the 8500 may have the same chip, but they're tuned completely differently. The firegl driver is written to work the way the firegl does (its a professional card, optimized to work with high poly counts and little to no texturing) and so 8500s crawl with that driver. The weather channel is developing better drivers but since they're doing it with no help from ATI it takes a while.
Counterstrike is no longer an issue. Valve updated their anticheat system so that WineX is a recognized platform, and they're working with transgaming to keep that up to date. Hopefully you should never have anticheat issues again.
Oh and WC3 works perfectly for me. Are you sure your CDROM is a supported one?
It's actually the FireGL driver. Some people discovered it works (though slowly) with the 8500 so ATI has decided they're going to call it an official 8500 driver.
Win2k is nothing like the same fucking implementation as 9x. They are completely different systems from top to bottom. The only place they come even close to being similar is in one library at the top level that takes the native calls of each system (in Win9x its the dos kernel calls and the VXD interface, and in WinNT/2k/XP its the NT executive interface) and wrap them in a defined standard set of functions called Win32. What wine is doing is wrapping linux's native calls (posix) with a library (called libwine) that implements the win32 interface. Were wine to completely implement that interface (its at something like 90% now), and an operating system be packaged with a linux kernel and wine as the primary program interface (remember linux is a kernel not an os, the distribution is an os) then you would have a fully fledged version of windows. Not a windows emulator, but a version of windows not written by MS (unless you use MS in the definition of windows in which case this whole argument is stupid).
Traditionally, "emulating" something is only when there is no way you could consider the emulator a new version of the original. Most notably this is with hardware emulation. If you wrote a program to emulate a powerpc processor, there's no way you could say this program is reimplementation of a powerpc processor, because its obviously not a piece of silicon. But you don't say that an athlon is a pentium emulator, you say its a reimplementation of the x86 spec.
Its very strange to see a post about the Alexandria meet in response to the Seattle meet. I just escaped from Alexandria to Seattle. No matter how hard I try to get away from there it somehow worm's its way back into my life.
(ps. No I didn't go to the Seattle meet. Wanted to but was stuck at work until midnight last night)
You're right about SGI not using Sparc or PowerPC processors but SGI is attempting to depreciate the MIPS. The latest Origins can have either MIPS or Itanium modules in them, and the Itanium configuration is described by them as the "high performance" option while MIPS is for "legacy configurations".
One issue is that all of the flying wing designs out there (and this is closer to a flying wing than a delta wing, and there is definitly a difference between the two) are on small craft. Something about the design lends to inherrently unstable craft, that take a much more precise control system to keep stable. Its just now that computer control of multiple flaps is precise enough that something like this in this large of a formfactor is feasable.
I'll admit I don't know as much about the PS2 as I do the other machines, but from what I remember, the PS2 has the ability to turn each of its 128bit scalar registers into 4 32 bit element vectors. And this vector mode is the prefered way of doing most hard calculations (considering you rarely need to deal with 64 bit numbers much less 128).
The $5 million number is a *very* rough estimate, and most of the bigger selling titles cost much more than that to develop. Then you have to take into account advertisement costs, distribution (you do have to pay trucks to take your game to best buys across the country you know), and apparently legal fees (at least most current game companies feel the need to sue anyone that writes any program that interacts with their game in any way (companies like Id withstanding)).
Just because programmers don't get paid per unit sold doesn't mean they don't factor into the profits of a game. Games cost upwards of $5 million to program upfront. Your $40 of profit per game doesn't even get factored in until this investment is returned.
I wonder how these reporters would react if you pointed out to them that the Gamecube and Xbox are both 32 bit and the PS2 spends most of its time in a 32 bit mode.
Re:gnome and mozilla released in the same month!
on
GNOME 2.0 Released
·
· Score: 2
And Warcraft 3. How many times has that game been completely redesigned?
That wasn't my point. DirectX shaders and OpenGL (1.2) shaders are done through C function calls that manipulate the GPU's shader assembler. OpenGL 2.0 was going to do away with this by defining a compiled language for shaders that would compile down to OpenGL extensions for whatever video card you're using. Theoretically, the OpenGL 2.0 shader language could be compiled into DirectX calls as well. And I realize that Cg could compile to the same OpenGL calls that the shader language does, what I'm wondering is why nVidia is pushing this in the first place, considering they helped define a large chunk of the OpenGL shader language. Yes it can co-exist, but they're not complementary, they're redundant.
Slashdot Mirror
I thought display pdf was also actualy sending pdf code to the window server, and pdf code just happened to be a lighter weight subset of postscript (pretty much postscript minus the programability). And I admit, messed up, Xdps wasn't until openstep but the point still stands that it's an existing system that proven workable that gives you the best of both worlds.
Also, I may be mistaken but I was pretty sure the quartxz windowserver got vector commands in some sort of protocal form (like pdf). Apps would send commands like "create an spline with these coordinates and assign it object name blah" and then allow the app to do resolution independant displays and deformations of that object just referencing it by name. Mind you I've never programmed for quartz so I may be talking out of my ass. Render on the other hand only does deformation and displays of pixmaps like you said, (or static color areas, which is where its power to composite objects out of these color areas comes in).
Anyways, the point was originally that with not too much more effort X can do all this without giving up the remote display, backward compatibility, extensibility and platform independance that we all love (or at least I do....I know there are X haters out there).
Quartz is based off a technology that was originally designed to be an extension to X. Mind you apple didn't implement it that way, but Xdps is in the works which will allow X apps to define a display postscript visual (which is actually more capable than display pdf, apple used the pdf subset of postscript so as not to pay royalties to adobe) and have all the compositing, path based, and vector capabilites of OSX, along with the extensibility of postscript, encapsulated in an X window that has all the features of X.
Or you could use X render which allows all of this to be easily implemented very efficiently in client side libraries. Basically the X framework is powerfull enough to give you choice and see which method works best.
Well for the multiplayer, RTCW is only teamwork based. Its actually team and class oriented (kinda like team fortress, except you can change classes with each respawn). I'm only pointing this out because I really like RTCW's multiplayer, and I'm dissapointed at how few servers there are for it relatively. CS is definitely a good game, but I just kinda got tired of playing dust over and over. Now the question is when I'll get sick of playing beach over and over...
MOH and RTCW are both teamwork based games. MOH moreso than counterstrike.
Theoretically the mass of the galaxy itself should be enough to hold it together. Even the black hole could have originally been formed from matter collecting at the center of gravity of the galaxy.
Descent has a native port (all three sequals).
Except not. The cards actually have an incredibly high detailed barcode that stores 2k per strip (two strips per card) and with four or five cards you can store an original nintendo game.
Technology *has* progressed. The HuCards were rom chips in a card package. Look inside a genesis cart, its mostly air. If they had chosen to they could have put those on "cards". The cards this article is referring to are cardboard trading-card sized cards with an incredibly detailed barcode on one side (so detailed that the individual dots aren't distinguishable by eye). The e-reader actually scans them with a laser and stores the program in flash on the reader and runs it from there. So yeah, yesterdays games which used to be on huge cartridges (these will be original NES games so really huge) are now represented by dots of ink.
The 8500 driver *is* just a rebranded fireGL driver, and it wasn't even rebranded until just a month ago. Not only that, it doesn't really work all that well. The fireGL and the 8500 may have the same chip, but they're tuned completely differently. The firegl driver is written to work the way the firegl does (its a professional card, optimized to work with high poly counts and little to no texturing) and so 8500s crawl with that driver. The weather channel is developing better drivers but since they're doing it with no help from ATI it takes a while.
Counterstrike is no longer an issue. Valve updated their anticheat system so that WineX is a recognized platform, and they're working with transgaming to keep that up to date. Hopefully you should never have anticheat issues again.
Oh and WC3 works perfectly for me. Are you sure your CDROM is a supported one?
It's actually the FireGL driver. Some people discovered it works (though slowly) with the 8500 so ATI has decided they're going to call it an official 8500 driver.
I was about to say, damn Portlanders stole the name from Seattle.
Win2k is nothing like the same fucking implementation as 9x. They are completely different systems from top to bottom. The only place they come even close to being similar is in one library at the top level that takes the native calls of each system (in Win9x its the dos kernel calls and the VXD interface, and in WinNT/2k/XP its the NT executive interface) and wrap them in a defined standard set of functions called Win32. What wine is doing is wrapping linux's native calls (posix) with a library (called libwine) that implements the win32 interface. Were wine to completely implement that interface (its at something like 90% now), and an operating system be packaged with a linux kernel and wine as the primary program interface (remember linux is a kernel not an os, the distribution is an os) then you would have a fully fledged version of windows. Not a windows emulator, but a version of windows not written by MS (unless you use MS in the definition of windows in which case this whole argument is stupid).
Traditionally, "emulating" something is only when there is no way you could consider the emulator a new version of the original. Most notably this is with hardware emulation. If you wrote a program to emulate a powerpc processor, there's no way you could say this program is reimplementation of a powerpc processor, because its obviously not a piece of silicon. But you don't say that an athlon is a pentium emulator, you say its a reimplementation of the x86 spec.
Its very strange to see a post about the Alexandria meet in response to the Seattle meet. I just escaped from Alexandria to Seattle. No matter how hard I try to get away from there it somehow worm's its way back into my life.
(ps. No I didn't go to the Seattle meet. Wanted to but was stuck at work until midnight last night)
We seattle slashdotters tend not to gather. It makes it easier for that mob on the eastside to hunt us.
You're right about SGI not using Sparc or PowerPC processors but SGI is attempting to depreciate the MIPS. The latest Origins can have either MIPS or Itanium modules in them, and the Itanium configuration is described by them as the "high performance" option while MIPS is for "legacy configurations".
One issue is that all of the flying wing designs out there (and this is closer to a flying wing than a delta wing, and there is definitly a difference between the two) are on small craft. Something about the design lends to inherrently unstable craft, that take a much more precise control system to keep stable. Its just now that computer control of multiple flaps is precise enough that something like this in this large of a formfactor is feasable.
I'll admit I don't know as much about the PS2 as I do the other machines, but from what I remember, the PS2 has the ability to turn each of its 128bit scalar registers into 4 32 bit element vectors. And this vector mode is the prefered way of doing most hard calculations (considering you rarely need to deal with 64 bit numbers much less 128).
The $5 million number is a *very* rough estimate, and most of the bigger selling titles cost much more than that to develop. Then you have to take into account advertisement costs, distribution (you do have to pay trucks to take your game to best buys across the country you know), and apparently legal fees (at least most current game companies feel the need to sue anyone that writes any program that interacts with their game in any way (companies like Id withstanding)).
Just because programmers don't get paid per unit sold doesn't mean they don't factor into the profits of a game. Games cost upwards of $5 million to program upfront. Your $40 of profit per game doesn't even get factored in until this investment is returned.
I wonder how these reporters would react if you pointed out to them that the Gamecube and Xbox are both 32 bit and the PS2 spends most of its time in a 32 bit mode.
And Warcraft 3. How many times has that game been completely redesigned?
You're from Seattle aren't you?
Well, warcraft 3 hasn't even been released yet but it works perfectly in WineX (or at least the betas did).
That wasn't my point. DirectX shaders and OpenGL (1.2) shaders are done through C function calls that manipulate the GPU's shader assembler. OpenGL 2.0 was going to do away with this by defining a compiled language for shaders that would compile down to OpenGL extensions for whatever video card you're using. Theoretically, the OpenGL 2.0 shader language could be compiled into DirectX calls as well. And I realize that Cg could compile to the same OpenGL calls that the shader language does, what I'm wondering is why nVidia is pushing this in the first place, considering they helped define a large chunk of the OpenGL shader language. Yes it can co-exist, but they're not complementary, they're redundant.