This is so wonderful. For years, GNOME users have been saying how GNOME brings more choice to the Linux desktop, how there is enough room for both to coexist, how the two aren't competing, etc. Of course, this was back when GNOME still sucked. Now, with the official blessing of IBM et al, GNOME users are talking about how KDE is scared to lose, how GNOME is going to totally take over the Linux desktop, etc. Lovely, absolutely lovely.
I have used Alias's Maya, but while there is a lot of stuff you can do using MEL, all of them relate to tools in the GUI. If your dino doesn't yet exist, then good luck using a laser scanner to capture those vertecies. Lastly, sure rendering may be command line-batch proessed, but I don't see anything in Maya that lets you model anything from the command line. And for my purposes, 3D Studio MAX is quite all right. I don't do a lot of animation, it's mostly 3D modeling to use in OpenGL programs and on website or publishing.
99% of 3D artists use GUI tools. Just thought you should know. Seriously though, you can't possibly be advocating using a text-based raytracer over using 3DStudio, can you? But hey, if you can figure out all the verticies that go into a 3D dinosaur, that's great. If you can make a realistic 3D scene only by positioning objects according to their coordinates, wonderful. If you can do 3D animation entirely based on the physics of the system (instead of using the physics engines built into most 3D modelers) wonderful.
PS> What the hell are you doing calling 3D Studio "limited?"
My comment is aimed at the more general problem that GNOME and KDE apps are not compatible. They are not just seperate tool kits, but entirely seperate operating environemnts. Compare this to Windows's MFC which is just a wrapper over Win32. A Win32 app and an MFC app are fully compatible. They interchange data using the same formats, they share a common clipboard, they share the same object model, they use the same underlying OS services, etc. You can say that GNOME is just a GUI, but then you have to explain how a GUI can take up 20MB+ of harddrive space. WindowMaker is just a GUI. FVWM is just a GUI. BlackBox is just a GUI. An application written for BlackBox is totally compatible with windowmaker without any extra libraries. GNOME (and KDE) is not just a GUI. To the user, it's a desktop environment. To the application, it provieds nost only an entirely new API, but totally new services that are only acessible to apps written for GNOME. I say, at that point, an application goes from being a GUI, to becoming a "mini operating system." These projects, like enlightenment and EMacs have caught the "I am an OS" syndrome, and it does not really make sense to consider them "just GUIs" anymore. Certainly, they split the market. A GNOME app is no longer a Linux app, it's a GNOME app. Sure you can run it on KDE/Linux using extra libraries, but then again, you can run Linux apps on FreeBSD using extra libraries. Programmers now have to choose one or the other. Users have to choose one or the other. (Users can do both, but it is a less than ideal solution because of extra libraries, and the lack of interoperability between applications for the two DEs.) None of this was every a problem with the prolifiration window managers. In fact, I dare say that "freedom of choice" has actually DECREASED with the coming of KDE and GNOME. Wheras you could choose any window manager and still be able to run any app, now you have to run either GNOME or KDE (or both.) You don't do the choosing, the application developers do.
A linux glibc is a compatibility library when uses on a FreeBSD system. A compatibility library is anything that allows an application meant for one system to be run on another. My FreeBSD comment is SUPPOSED to fall apart. I was using it to show that Linux/KDE and Linux/GNOME are two different OSs. Instead of thinking about it from a technical standpoint, think about it from a user's standpoint. You cannot run a GNOME application on KDE without using the GNOME libraries. Since the GNOME libraries form such an abstraction layer around the application, it can be said that running a GNOME app on KDE/Linux using the GNOME compatibility libraries is similar to running a Linux app on FreeBSD using the Linux compatibility libraries. As for the WINE example, you prove my point. If you say that a GNOME application running with compatibility libraries under KDE still constitutes the same OS (from a functional, not technical standpoint) then you have to say that Linux running a Windows app using Windows compatibility libraries also constitutes the two being the same OS. Obviously that's not true.
Will a GNOME application run on KDE? (Without compatibility libraries.) Can you write an entire GNOME application without making a single POSIX call? Does GNOME include a VFS layer? I rest my case.
PS> If you include compatibility layers, then you can consider Linux and FreeBSD the same OS because FreeBSD can run Linux apps using a compatibility library.
Actually, due to all the differences between KDE and GNOME, they can easily be considered two different OSs. In corner you've got KDE/Linux, and in the other, GNOME/Linux. Let the fights begin!
As I remember it, the reason Genesis games had a darker, edgier look was because of the Genesis's ridiculously small color palatte. (64 onscreen out of 512 compared to the SNES's 256 on screen out of 32768)
Actually, you can't outright say a 1.4GHz Athlon is faster than a 2GHz P4. While it may be true for business apps, I think that the P4 will really kick for 3D.
The NVIDIA Vanta chips are probably best here. You can get a 8MB version for about $40 on pricewatch, or a 16MB version for about $50. Around $55-60 you can get a Matrox G200.
Hello? Were you reading? This thing has a 400MHz dual channel RDRAM bus. That's 3.2GB/sec, which is about 4 times faster than the Athlon bus. (which runs 100MHz SDRAM)
Okay, here is the deal. If Intel can pull of the manufacturing of this thing, the 2GHz chip will not be far off. Meanwhile, I doubt it is possible for the.18 micron Athlon to be pushed up to 2GHz. If Intel can maintain this huge clock speed they've got two major advantages.
1) Their parts perform about as well as a much lower clocked Athlon for most tasks. However, give it something really regular like 3D, and it totally blows the Athlon away. Intel has gotten wise to the fact that nobody really uses consumer chips for anything other than 3D. Even the most bloated of Office apps don't demand much more than a 500MHz chip. However, get into anything 3D or media related (stuff that is pretty regular, but very compute intensive) then procs 1GHz+ are required. By performing about the same for most tasks, and totally blowing Athlon away in media, Intel hopes to get back their market share. This also explains why Intel is targetting this chip only at consumers (no SMP, the rumblings about using SDRAM) because the chip really wouldn't be ideal in a server situation.
B) Intel has the clock-speed advantage in terms of marketing. Like it or not, a huge number of people by their CPU for the clock-speed. In the market, a 1.4GHz Athlon vs. a 2GHz P4 at the same price will be a no-brainer for most people.
History, shit I was playing the games back then! Sure some of the SNES games were a little kiddie (especially at first) but since the SNES had the shear bulk of the games, a lot of mature games came out too. First of all anything from Square Soft. Sure some of them (Chrono Trigger) had a younger image (though CT was far from kiddie) but there is a difference between image and actual game-play. You also had a lot of horror games, a lot of fighting games, combat sims (Iron Eagle and Urban strike), the list goes on.
Okay, MSVC's problems could be fixed, it could not be fixed. (Actually, the linux kernel seems to have some not-standard dependencies so you can't totally blame them.) Either way, I meant fastest. The person I was responding to was talking about speed, the quote that I included was talking about speed. I thought I made myself sufficiantly clear.
That's irrelevant, I was talking about speed. Still, VisualC++ isn't as standard complient as one would like. Of course moving a large-code base from one compiler to another is something I'd only wish upon those I really hated.
Oh god, not one of those "quality not quantity" nimrods. I thought you were all shot when Nintendo64 did so crappily in Japan. The thing is, that Sony has nothing to do with "saturating the market." If you don't remember exactly what happened, Nintendo had to come up with the "quality not quantity" bullshit because they were the only ones making games for awhile. Sony on the otherhand, probably had more good games, than Nintendo did. Nintendo was in the same position as Sony back in the SNES days, and it is agreed that SNES was probably one of the most successful consoles in history. The thing is, that approach may lead to a lot of crap games, but in the end, sheer volume makes sure that the library of good games is large. Also, it enables a lot of selection. Nintendo was really hurt in Japan because there weren't any (not good or bad, ANY!) RPGs on Nintendo 64. (Aside from the RPG-pretender Quest64.) Choice is good. "Quality not quantity" is game censorship.
Actually, as any avid vid-game owner knows, the limitation is not keeping the old machine, but how many S-Video ports you've got on the back of your TV. (At our house S-Video ports are a rare-commodity. Trade wars flare up over them all the time.)
Not really. The whole "kiddie" thing only comes from the N64 since the majority of the decent games (originally) on that platform came from Nintendo/Rare, and Nintendo itself has always made "kiddie" games. Actually, during the SNES, there were a lot of "adult" games.
Does the graphics chip smack of DirectX or what? (S3TC is the standard Direct3D texture compression mechanism) Although texture compression is a great idea. If you've ever seen those Unreal-S3TC screenshots you'll know what I mean. Lastly, 16MB of SOUND RAM! That's got to be a typo.
Slashdot Mirror
This is so wonderful. For years, GNOME users have been saying how GNOME brings more choice to the Linux desktop, how there is enough room for both to coexist, how the two aren't competing, etc. Of course, this was back when GNOME still sucked. Now, with the official blessing of IBM et al, GNOME users are talking about how KDE is scared to lose, how GNOME is going to totally take over the Linux desktop, etc. Lovely, absolutely lovely.
I have used Alias's Maya, but while there is a lot of stuff you can do using MEL, all of them relate to tools in the GUI. If your dino doesn't yet exist, then good luck using a laser scanner to capture those vertecies. Lastly, sure rendering may be command line-batch proessed, but I don't see anything in Maya that lets you model anything from the command line. And for my purposes, 3D Studio MAX is quite all right. I don't do a lot of animation, it's mostly 3D modeling to use in OpenGL programs and on website or publishing.
Can you embed KDE apps into GNOME apps?
Exactly how was I supposed to interpret "Text tools work better, trust me" as a non-inflamatory comment?
99% of 3D artists use GUI tools. Just thought you should know. Seriously though, you can't possibly be advocating using a text-based raytracer over using 3DStudio, can you? But hey, if you can figure out all the verticies that go into a 3D dinosaur, that's great. If you can make a realistic 3D scene only by positioning objects according to their coordinates, wonderful. If you can do 3D animation entirely based on the physics of the system (instead of using the physics engines built into most 3D modelers) wonderful.
PS> What the hell are you doing calling 3D Studio "limited?"
My comment is aimed at the more general problem that GNOME and KDE apps are not compatible. They are not just seperate tool kits, but entirely seperate operating environemnts. Compare this to Windows's MFC which is just a wrapper over Win32. A Win32 app and an MFC app are fully compatible. They interchange data using the same formats, they share a common clipboard, they share the same object model, they use the same underlying OS services, etc. You can say that GNOME is just a GUI, but then you have to explain how a GUI can take up 20MB+ of harddrive space. WindowMaker is just a GUI. FVWM is just a GUI. BlackBox is just a GUI. An application written for BlackBox is totally compatible with windowmaker without any extra libraries. GNOME (and KDE) is not just a GUI. To the user, it's a desktop environment. To the application, it provieds nost only an entirely new API, but totally new services that are only acessible to apps written for GNOME. I say, at that point, an application goes from being a GUI, to becoming a "mini operating system." These projects, like enlightenment and EMacs have caught the "I am an OS" syndrome, and it does not really make sense to consider them "just GUIs" anymore. Certainly, they split the market. A GNOME app is no longer a Linux app, it's a GNOME app. Sure you can run it on KDE/Linux using extra libraries, but then again, you can run Linux apps on FreeBSD using extra libraries. Programmers now have to choose one or the other. Users have to choose one or the other. (Users can do both, but it is a less than ideal solution because of extra libraries, and the lack of interoperability between applications for the two DEs.) None of this was every a problem with the prolifiration window managers. In fact, I dare say that "freedom of choice" has actually DECREASED with the coming of KDE and GNOME. Wheras you could choose any window manager and still be able to run any app, now you have to run either GNOME or KDE (or both.) You don't do the choosing, the application developers do.
A linux glibc is a compatibility library when uses on a FreeBSD system. A compatibility library is anything that allows an application meant for one system to be run on another. My FreeBSD comment is SUPPOSED to fall apart. I was using it to show that Linux/KDE and Linux/GNOME are two different OSs. Instead of thinking about it from a technical standpoint, think about it from a user's standpoint. You cannot run a GNOME application on KDE without using the GNOME libraries. Since the GNOME libraries form such an abstraction layer around the application, it can be said that running a GNOME app on KDE/Linux using the GNOME compatibility libraries is similar to running a Linux app on FreeBSD using the Linux compatibility libraries. As for the WINE example, you prove my point. If you say that a GNOME application running with compatibility libraries under KDE still constitutes the same OS (from a functional, not technical standpoint) then you have to say that Linux running a Windows app using Windows compatibility libraries also constitutes the two being the same OS. Obviously that's not true.
Will a GNOME application run on KDE? (Without compatibility libraries.) Can you write an entire GNOME application without making a single POSIX call? Does GNOME include a VFS layer? I rest my case.
PS> If you include compatibility layers, then you can consider Linux and FreeBSD the same OS because FreeBSD can run Linux apps using a compatibility library.
Another text-tools hardliner? When you can do 3D modeling more efficiently in text, please call me back so I can throw away 3D Studio.
Actually, due to all the differences between KDE and GNOME, they can easily be considered two different OSs. In corner you've got KDE/Linux, and in the other, GNOME/Linux. Let the fights begin!
This is the media's POV. It's always surrounded by a reality distortion field. Get used to it.
They should also learn how to put some polish on their product ;)
As I remember it, the reason Genesis games had a darker, edgier look was because of the Genesis's ridiculously small color palatte. (64 onscreen out of 512 compared to the SNES's 256 on screen out of 32768)
Actually, you can't outright say a 1.4GHz Athlon is faster than a 2GHz P4. While it may be true for business apps, I think that the P4 will really kick for 3D.
The NVIDIA Vanta chips are probably best here. You can get a 8MB version for about $40 on pricewatch, or a 16MB version for about $50. Around $55-60 you can get a Matrox G200.
Hello? Were you reading? This thing has a 400MHz dual channel RDRAM bus. That's 3.2GB/sec, which is about 4 times faster than the Athlon bus. (which runs 100MHz SDRAM)
Okay, here is the deal. If Intel can pull of the manufacturing of this thing, the 2GHz chip will not be far off. Meanwhile, I doubt it is possible for the .18 micron Athlon to be pushed up to 2GHz. If Intel can maintain this huge clock speed they've got two major advantages.
1) Their parts perform about as well as a much lower clocked Athlon for most tasks. However, give it something really regular like 3D, and it totally blows the Athlon away. Intel has gotten wise to the fact that nobody really uses consumer chips for anything other than 3D. Even the most bloated of Office apps don't demand much more than a 500MHz chip. However, get into anything 3D or media related (stuff that is pretty regular, but very compute intensive) then procs 1GHz+ are required. By performing about the same for most tasks, and totally blowing Athlon away in media, Intel hopes to get back their market share. This also explains why Intel is targetting this chip only at consumers (no SMP, the rumblings about using SDRAM) because the chip really wouldn't be ideal in a server situation.
B) Intel has the clock-speed advantage in terms of marketing. Like it or not, a huge number of people by their CPU for the clock-speed. In the market, a 1.4GHz Athlon vs. a 2GHz P4 at the same price will be a no-brainer for most people.
History, shit I was playing the games back then! Sure some of the SNES games were a little kiddie (especially at first) but since the SNES had the shear bulk of the games, a lot of mature games came out too. First of all anything from Square Soft. Sure some of them (Chrono Trigger) had a younger image (though CT was far from kiddie) but there is a difference between image and actual game-play. You also had a lot of horror games, a lot of fighting games, combat sims (Iron Eagle and Urban strike), the list goes on.
Okay, MSVC's problems could be fixed, it could not be fixed. (Actually, the linux kernel seems to have some not-standard dependencies so you can't totally blame them.) Either way, I meant fastest. The person I was responding to was talking about speed, the quote that I included was talking about speed. I thought I made myself sufficiantly clear.
That's irrelevant, I was talking about speed. Still, VisualC++ isn't as standard complient as one would like. Of course moving a large-code base from one compiler to another is something I'd only wish upon those I really hated.
Oh god, not one of those "quality not quantity" nimrods. I thought you were all shot when Nintendo64 did so crappily in Japan. The thing is, that Sony has nothing to do with "saturating the market." If you don't remember exactly what happened, Nintendo had to come up with the "quality not quantity" bullshit because they were the only ones making games for awhile. Sony on the otherhand, probably had more good games, than Nintendo did. Nintendo was in the same position as Sony back in the SNES days, and it is agreed that SNES was probably one of the most successful consoles in history. The thing is, that approach may lead to a lot of crap games, but in the end, sheer volume makes sure that the library of good games is large. Also, it enables a lot of selection. Nintendo was really hurt in Japan because there weren't any (not good or bad, ANY!) RPGs on Nintendo 64. (Aside from the RPG-pretender Quest64.) Choice is good. "Quality not quantity" is game censorship.
Actually, as any avid vid-game owner knows, the limitation is not keeping the old machine, but how many S-Video ports you've got on the back of your TV. (At our house S-Video ports are a rare-commodity. Trade wars flare up over them all the time.)
Not really. The whole "kiddie" thing only comes from the N64 since the majority of the decent games (originally) on that platform came from Nintendo/Rare, and Nintendo itself has always made "kiddie" games. Actually, during the SNES, there were a lot of "adult" games.
Does the graphics chip smack of DirectX or what? (S3TC is the standard Direct3D texture compression mechanism) Although texture compression is a great idea. If you've ever seen those Unreal-S3TC screenshots you'll know what I mean. Lastly, 16MB of SOUND RAM! That's got to be a typo.
ext.