"Creating something and then inviting everyone to come and play with it and come and make money on this stuff we have."
He left out the final part:
"Creating something and then inviting everyone to come and play with it and come and make money on this stuff we have. That's when we steal everything that everyone else made, claim it as our own, and lock out everyone. That's how our monopoly works."
>The ugly API. I write for the framebuffer because >I can get a cleaner API there. Not that this is a >popular attitude - slashdotters hate the Windows >monopoly, but consider it a heresy to not use >OpenGL for graphics. Just try saying you still >use a console and it's a guaranteed Troll mod.
I'm not saying that you should not use the console. Using the console is fine, and I often do it my self, but if you want fancy graphics --and I believe that that is what you were complaining about-- then you should look to OpenGL (which has drivers that work through X).
The frame buffer is essentially just a pointer to memory. I've seen some attempts to do some hardware acceleration on some cards but the implementation is not good. You can either call an ioctl for each hardware operation, which means an OS context switch every time you do an operation (bad), or you can memory map the graphics card registers and bypass all the kernel abstractions and bang at the the hardware yourself. ie each application that uses the frame buffer can just implement it's own hack at a driver for that card -- this is awful.
There are some attempts at doing this right, I haven't coded for them, but I've looked at them. ie directFB. As a graphics library this seems reasonable, but why re-invent the wheel?
My take on it is this:
"Those who dont understand history being doomed to repeat it."
Of course you're free to try and invent something new, make new and better things -- and I've done this myself. I've worked on a game engine for a while now. My approach is to do everything from scratch, with out looking at the standard way of doing things. This way I have at least a chance of coming up with something new. But this does not mean that my engine is better than any other. Usually I find that my implementations, ie LOD algorythms etc. end up being very similar to what others have done.
On Linux, it is great to have freedom to do what ever you want, and you do, but it is also good to have some persistant, cross-platform, secure standards which you can build on top of. If you come up with something new, which is several orders of magnitude better than what is already there, then maybe the comunity should look at suffering the pain of switching.
I too like to use Linux to play games, except I like the fancy graphics, and I get them!. UT2004, Neverwinter, etc. What is the aversion to using X?
I'm happy to use the binary drivers to get the HW accel, but I can at least see the logic of wanting to have opensource drivers. If that's what you wan't, then just use the DRI version of dirvers for supported cards (sometimes less performance, but still OK).
But, if you demand to use the text console to play games, or the frame buffer than you have nothing to complain about -- you've gotten what you wished for!
Actually a linux port was promised from the get-go.
Still I've been using the beta (5 now). And it has been behaving much better than the Windows version. It's more stable and faster! -- I'm very happy with the port -- and there are ways to play the movies outside of the game.
200 bucks for a 40 Gig HD, keyboard + mouse + network card isn't all that high. Their cost is most likely not much less, considering that the hardware is somewhat custom and low volume.
Now, the real value is not the hardware, but being able to run linux + develop against fully supported harware accel ps2 graphics on a PS2. This is fantastic!
The file system takes care of caching disk access in ram, so if you write to a tmp file, the file system will write to memory (ram), and eventualy write it to disk when it get around to it, or if you do a "sync" at the prompt. If the tmp file is read soon after it was written, then deleted, it will never even get written to disk.
The driver that they released has some extra code to drive the custom chips that they have put on the board. -- At least this is what they said at the Linux University that I went to.
Jamie
Re:3dfx is basically gone
on
ATI Radeon 256
·
· Score: 1
>Back on ATI's side, the Radeon looks like it will have more features that the GF2. As a game coder, I like that.:) Also, ATI is likely to have better Linux support. I also like that.
nVidia/SGI have a driver in the works. I've seen it working at one of SGI's "linux university" shows. It was runing a performer demo, and it ran it very fast:) The driver is supposed to be out in May along with an SGI Linux workstation with their own version of an nVidia card in it.
I got a version of a microsoft media player (for linux) over a year ago. It actualy worked, but I felt very uneasy when I installed it as root! (what else did the install do?).
SPEC viewperf
http://www.spec.org/benchmarks.html#gpc
This was true before 2.0 with the GLslang language...
Strictly speaking though it is an API that includes a GLSlang language.
"Creating something and then inviting everyone to come and play with it and come and make money on this stuff we have." He left out the final part: "Creating something and then inviting everyone to come and play with it and come and make money on this stuff we have. That's when we steal everything that everyone else made, claim it as our own, and lock out everyone. That's how our monopoly works."
Videos that I converted from my camera etc. To the PSP no longer play!
Now I only get this message:
"This video cannot be played"
http://sw-bf.de/article.xhtml?id=15
Actually if you read the artical, it was a two part question
Will you be able to play SWBF on 'exotic' platforms like the Linux-kernel or Mac OS? Will you release a dedicated-server-software?
1)
The question states "Will you be able to play SWBF"
and
2)
"will you release a dedicated-server-software"
Being able to play, implies a client.
The answer was yes they were looking into a linux version, but they never said which part of the question they were answering.
The real origional was in German, so maybe some native german speekers could verify the translation.
http://sw-bf.de/article.xhtml?id=15
There was talk of a Linux port. Anyone have an update?
http://www.linux-gamers.net/modules/news/articl
>The ugly API. I write for the framebuffer because
>I can get a cleaner API there. Not that this is a >popular attitude - slashdotters hate the Windows >monopoly, but consider it a heresy to not use >OpenGL for graphics. Just try saying you still
>use a console and it's a guaranteed Troll mod.
I'm not saying that you should not use the console. Using the console is fine, and I often do it my self, but if you want fancy graphics --and I believe that that is what you were complaining about-- then you should look to OpenGL (which has drivers that work through X).
The frame buffer is essentially just a pointer to memory. I've seen some attempts to do some hardware acceleration on some cards but the implementation is not good. You can either call an ioctl for each hardware operation, which means an OS context switch every time you do an operation (bad), or you can memory map the graphics card registers and bypass all the kernel abstractions and bang at the the hardware yourself. ie each application that uses the frame buffer can just implement it's own hack at a driver for that card -- this is awful.
There are some attempts at doing this right, I haven't coded for them, but I've looked at them. ie directFB. As a graphics library this seems reasonable, but why re-invent the wheel?
My take on it is this:
"Those who dont understand history being doomed
to repeat it."
Of course you're free to try and invent something new, make new and better things -- and I've done this myself. I've worked on a game engine for a while now. My approach is to do everything from scratch, with out looking at the standard way of doing things. This way I have at least a chance of coming up with something new. But this does not mean that my engine is better than any other. Usually I find that my implementations, ie LOD algorythms etc. end up being very similar to what others have done.
On Linux, it is great to have freedom to do what ever you want, and you do, but it is also good to have some persistant, cross-platform, secure standards which you can build on top of. If you come up with something new, which is several orders of magnitude better than what is already there, then maybe the comunity should look at suffering the pain of switching.
I too like to use Linux to play games, except I like the fancy graphics, and I get them!. UT2004, Neverwinter, etc. What is the aversion to using X?
I'm happy to use the binary drivers to get the HW accel, but I can at least see the logic of wanting to have opensource drivers. If that's what you wan't, then just use the DRI version of dirvers for supported cards (sometimes less performance, but still OK).
But, if you demand to use the text console to play games, or the frame buffer than you have nothing to complain about -- you've gotten what you wished for!
Actually a linux port was promised from the get-go.
Still I've been using the beta (5 now). And it has been behaving much better than the Windows version. It's more stable and faster! -- I'm very happy with the port -- and there are ways to play the movies outside of the game.
No it's not a rip off!
200 bucks for a 40 Gig HD, keyboard + mouse + network card isn't all that high. Their cost is most likely not much less, considering that the hardware is somewhat custom and low volume.
Now, the real value is not the hardware, but being able to run linux + develop against fully supported harware accel ps2 graphics on a PS2. This is fantastic!
The file system takes care of caching disk access in ram, so if you write to a tmp file, the file system will write to memory (ram), and eventualy write it to disk when it get around to it, or if you do a "sync" at the prompt. If the tmp file is read soon after it was written, then deleted, it will never even get written to disk.
The driver that they released has some extra code to drive the custom chips that they have put on the board. -- At least this is what they said at the Linux University that I went to.
Jamie
>Back on ATI's side, the Radeon looks like it will have more features that the GF2. As a game coder, I like that. :) Also, ATI is likely to have better Linux support. I also like that.
nVidia/SGI have a driver in the works. I've seen it working at one of SGI's "linux university" shows. It was runing a performer demo, and it ran it very fast:) The driver is supposed to be out in May along with an SGI Linux workstation with their own version of an nVidia card in it.
I got a version of a microsoft media player (for linux) over a year ago. It actualy worked, but I felt very uneasy when I installed it as root! (what else did the install do?).
Actually the current x86's are RISC (mostly). Most of the old x86 instructions get decoded into risk-ops, then processed in a RISK fashion.