How this got modded up is beyond me. Not only is it not insightful, it's downright wrong!
When communicating to local hardware, there is no TCP/IP anywhere. It communicates over a local socket. It has been implemented with shared memory, and guess what? It didn't perform any better than over a local socket! That's why you don't see shared memory in XFree today.
And i dunno about you, but my fonts look just fine. They're probably the same TrueType fonts you've seen a million times on Windows.
While i agree with your main point that having a homogeneous computer environment, especially in computer science, is a bad thing, but i do have one nit to pick.
You write that "your college students are there to learn and be trained for the work-place of tomorrw," but that's only really true if this is a trade school he's talking about. Granted, these days education-- even higher education-- is generally seen as a way to get a good job, but the point of a real college or university, as opposed to a trade school, is general education, not to teach one a trade (aka how to do a job). Generally, college is supposed to teach you good ways to think about problems, and give you an informational base to work from. A good education will allow you to apply what you've learned through the tools available.
Having said that, there are many useful lessons to be learned in interoperating between computing environments. I use Linux almost exclusively, but most of the people i develop with use Windows. There are challenges to writing cross-platform code that are good to know, especially if you're going off into the commercial software development world, 'cause out there, if you're writing end-user software, and you don't know how to manage cross-platform projects, there's slim-to-no chance you'll end up using it under Linux. If you know the pitfalls however, your chances are a bit better (though still not all that good).
You're indeed right about strategy turn-based war games, but i think it's only because it's a niche audience that's more accepting of alternative distribution channels. I can't comment on the text adventures, though i'm guessing the combined revenues from all text adventure sales aren't enough to support too many developers. And in both these areas, i'm guessing that the development is pretty much incremental increases. The war-game crowd basicly knows what they want, they're just looking for new tweaks and scenarios. Not to say it's entirely stagnant or all the games are the same, but rather i'm guessing they all conform rather rigidly to the genre specifics.
Galactic Civilizations and Rise of Nations are hardly big-name games. Not to say they don't have the production values, but they don't have the marketing force that real big-name games have. Black and White, on the other hand, was developed by a small company, and was a big-name game because of one person: Peter Molyneux. Not only is he something of a celebrity in game development, but he also brought millions of dollars in to fully fund development. That's how he had creative control-- he was spending his life savings.
I use fluxbox, which for those of you not in the know, is a windowmanager based on Blackbox that implements tabs for windows in a general way. I can make a window with multiple mozilla tabs, or lynx tabs, or terminal tabs, or i can make a window with a terminal on one tab, the progress report for my cd burning on the next tab, and Quake on the next tab. It's a great, general solution, and it actually saves so much screen realestate, i use my multiple desktops much less frequently (pretty much only when i want different layouts of windows on the screen).
However, the problem is that the way i use tabs in Mozilla would require some amount of intelligent interaction between Mozilla and fluxbox for opening tabs in new windows, in the background or the foreground, using mouse gestures to move between them, etc. All but the last of these could (and should) be handled by the windowmanager prereferences for that program, but what about the last? Should we roll gestures into the windowmanager as well? What about radial context menues? These are, in my opinion, some interesting questions, and ones to which i don't have the answer. What i will say, however, is that in the state of things today, in applications that make heavy use of interactions between the "documents", MDI still makes sense.
Yes, and my point, which i now realize i could've made clearer in my post, is that they DO attempt to use some faux focus in motion pictures-- if they didn't, it'd look even worse-- but it's really hard to get right, and they often err on the side of overly-clear.
On the one hand, focus is the issue here. Focus is very important, and i myself HATE when the CGI looks like CGI because it's too in focus.
BUT, as someone who's done a few high-quality computer animated shorts, there's a large amount of work that goes into, and a significant number of applications to help with, post-processing effects, such as blur and focus and color temperature. It's fundamentally a very hard problem. For color and lighting, Paul Debevec has been doing a lot of new and interesting things to use real-world lighting to light computer models, and computer lighting to light real people. As for blur and focus, i'm not sure of any really good algorithms or techniques, but in practice, it's largely all hand-tweaked, which is bound to be imperfect.
It's easy to say that "damn CGI artists don't know what the word 'focus' means," but when you take a good look at the problem, it's hardly that trivial.
I've used a couple of the big-name packages in this area (Maya, Lightwave, Renderman(prman & bmrt)), but i'm primarilly a programmer. Being a programmer of 3d applications at that, i have a few suggestions as to how you do it:
First, encapsulate the system-specific stuff, preferably through pre-existing libraries where available. You can encapsulate the 3D renderer as well, though i'd suggest just picking one (*cough* OpenGL *cough*) and doing it well, at least at first, not worrying about wrapping it up. Next, i'd design the entire interface in said 3D rendering context or other windows popped up from it, both so that you don't have to worry about gui consistency across platforms, and so that it goes fast with fewer big library dependencies. There are a couple cross-platform libraries that do GUIs for OpenGL out there.
Now, if you've used Maya much, you'll know that it's basically a big programming enviroment with a few graphics hooks. The rest is scripted. It's truly amazing, but i think that this is quite vital. I'd suggest using SWIG or Boost::Python to do Python interfacing to your compiled code, and use Python to build the interface and implement a lot of the details (some tools, basic relationships,...). This doesn't mean you won't also want some simple command-language as well, but for the heavier-duty stuff, i think Python's your language, but then, it's really personal preference. I suggest you go with something that's clean and robust and has good, easy C or C++ language bindings.
Don't worry about a rendering engine, just get it to work with Renderman (prman, entropy, bmrt, etc.). Most renderers in comercial software fall short of those anyway.
Oh, and try to get the groundwork in there quickly, then do RAD with Python, replacing stuff as needed for performance.
So, to recap: incremental development, scriptabiliy, OpenGL everything for display, scriptability, Renderman export, and above all, scripability. Especially scriptability that's easy for artist-types to use.
Whoever modded this up needs to use some common sense. A record groove that's precise to under 5 nanometers? Sorry, that right there should tell you that this is lacking somewhere. Perhaps some people don't understand that the needle on your record will NOT, no mater how good it is, pick up vibrations caused by a few nanometers of change because that is literally just a handful of atoms!
Now, where the analysis is wrong is a tougher question for me. I'm guessing, however, that it has something to do with the fact that the author assumes that the info isn't encoded on a logarithmic scale. You do, after all, have to have a very special amp to use a phonograph.
That's right, this is bound to fail, but not for the reasons you're guessing. Let me start at the beginning:
In Understanding Comics, Scott McCloud discusses the various levels of abstraction in comic art. How abstract a character is has a great deal of influence on how the character is perceived. Charlie Brown is Charlie Brown because of how he is drawn as much as because of his personality. If Charlie Brown were drawn by Gary Larson, of The Far Side, or acted by Mike Meyers, it just won't feel like Charlie Brown.
If you're with me so far, then it's not too terribly large a step to say that video game characters don't translate well across levels of abstraction either. The semi-realistic Lara-croft would not feel like the same character if presented as a pudgy Mario-esque character. Of course, over franchises, characters do evolve, this is a tricky process, often involving the redefinition of a character. Donkey Kong, for example, is an entirely different character in Donkey Kong Country than in the original Donkey Kong.
There is yet another aspect of abstraction with games. That is, the gameplay itself can be more or less abstract. Ultimately, players have no problem with a 8-bit Mario who can jump 8 times his own height, and doubles in size when touching a mushroom, but in a 3d third-person shooter, this would seem quite out of place.
So, ultimately, my point is that games that go back and forth from 128-bit near-photo-realistic graphics and advanced simulation to 128x128 pixel monochrome display with menu-based simple game mechanics will ultimately not be terribly compelling. This is more true for games whose characters, settings, and mechanics are more technologically advanced and more realistic. It would be like watching a movie with your favorite actors, and then when you're out of the house, getting to see a cartoon version with simplified plot and dialog. Not that there's anything wrong with either form, it's just that they do not mesh well together.
There are games for which this system would work perfectly well (Pokemon coming to mind), but as the industry will not rally around the niche created by this phone, the number of games who will take good advantage of this technology will be severly limited, for good or ill.
Alias|Wavefront just recently slashed prices significantly, actually. The $10,000 per seat is no more (still not cheap, though)!
However, i have to say that i had a similar reaction as the parent of your post. That's a cool hack, but creating an object in-scene that the eyes follow that you can place and key is really rather easy in Maya.
You raise good points though. I wouldn't inflict the Maya renderer on anyone, whereas the Lightwave renderer is quite nice in my experience. Furthermore, as of LW6.5, Maya seems to have better subdivisions, though i like Lightwave's tools and interface better.
Overall, though, i have to say that Maya is one of the most impressively scriptable and versitile tools i've ever used. Terrible interface, but if you want to do something, you *can*, without exiting the program.
Well, the funny thing about this is that all the.NET web service stuff uses SOAP (XML) to communicate through HTTP (presumably for both ease-of-use and so that webservices can be used in places with restrictive firewalls, for good or ill). Now, this guy is undoubtably aware of this fact, but coming from that knowledge, it's interesting to note that Microsoft's.NET team:
a) Bases their web services on communication via HTTP then b) Says HTTP is doomed because it's not peer to peer
Maybe someone made a bad choice for their protocol and is trying to cover his ass? I doubt it. Maybe they're trying to shift blame for any shortcomings of.NET webservices onto the protocol (not that i've heard anything about shortcomings-- it's been a couple months since i've worked with.NET at all).
Or maybe this guy has a point, which i doubt, but i'm far from qualified to really judge.
" What will this do to Transgaming? They will no longer be able to make changes and keep them to themselves - kind of seems like it destroys their business model. "
Well, i'm not sure about how Transgaming works, but they could always fork a version of Wine from before it turns LGPL. Or, as someone else said, they could try to do a dual-licenced Wine, and pay for a version that they don't have to disclose the source to. That'd probably be difficult to do on a project that wasn't set up like that from the beginning, though (copyright holders may not be so willing to give away their privledges if someone will be making a buck on it).
I'll avoid most of my comments about your choice of language because most of it is of a political nature, rather than practical one; however, I really wouldn't suggest trying to make a massively multiplayer game with a language you're unfamiliar with. It's quite an undertaking even with a language you know. I know; i'm working on one.
As for the networking code transparency, this one seems fairly obvious to me.. Just keep a datastructure containing all the changed or "tainted" objects as you go. Make mutator functions of your classes set objects as tainted. Then, just do the networking updates once or twice every time through the main loop (assuming it's in the same thread. Otherwise, you can implement something that might end up being a little more efficient).
As for updating only what the player needs to be updated on, this seems like a question of algorithm efficiency. I don't know the specifics of your game, but with most massively multiplater games, transmitting the entire world state, or even the entire list of changes to every client, every cycle would be insane. So, you have to only update the section of the world that the player can see. How to do this well depends on the internal structure of the world, and what sort of stuff the player can "see". If the game is room-based, then this is easy. If the player can always just see a specific size circle or rectangle around him, this is also easy (each event can check distance to all players in its regeon). If it works like most RTS with arbitrary viewing areas, then you might have to be a little more clever. Whether this is even much of a concern is really a question of the number of people supported, and the expected hardware this'll be running on.
A few people have pointed out that if you're the sole contributor, you're free to licence the software as you see fit. However, even if this is the case, I don't think it solves the problem. Essentially what the author wants is to keep the codebase Free and have all changes come back to the community. What the author doesn't care about that the LGPL does is the ability to relink with other libraries, since that can be pretty diffecult with hardware.
After a little exploration at gnu.org's Free licence list i saw the "licence of Guile" (third one down) that looks like exactly what you're looking for. The licence is not on the web, though, so you'll have to download Guile and see for yourself. It says it's essentially the GPL only with a blanket statement allowing linking with non-free software.
"Also, if videogames are considered art than what stops other computer programs from also being considered art? Censoring videogames because of violence or even programs because of DMCA-type laws may be considered censoring art - something that many Americans have traditionally been very opposed to?"
This is like saying that because paintings are art, then what's to stop us from saying that normal old house-painting is art, and thus city ordinances on the appearence of buildings are violating first ammendment rights by censoring art.
I'm not saying all code is or isn't art, i'm just saying that code isn't automatically art. Furthermore, i think the submitter obviously has no real care for whether or not it's actually art, but only would the official "art" status would mean for code in general, which is a fairly bad way to approach proving that code is art.
Code is a tool, like paint. Paint, in certain configurations is considered to be art, but paint does not make something art, and in fact, it's fairly difficult to make paint into good art. Throwing the blanket statement of "code is art" around just seems silly and shows that the speaker doesn't really understand what most people talk about when they talk about what is "art".
Well, of course they used RiCurves, all the Renderman hair shaders i've ever seen use RiCurves, but the question is how they got it to look SO much like hair.
For example, the scene where Sully is in the blizzard, lying on the ground, the interaction between his hair, the snow particles, and the wind just knocks my socks off. It really looks like there's quite some wind turbulance, though i wouldn't be too surprised if it's something simpler, like a couple moving "fans".
I'll agree that at this point, they only seem to be able to do very clean, very straight hair, but in that domain, it's damn impressive. I think the problem may be hairs interacting with each other-- i couldn't even tell you if there's any collision detection in Sully's hair at all, and self-intersection tests and other collision detection could GREATLY slow down rendering, though i once heard a guy from Pixar saying that if given the option of making it look a little better makes it take significantly longer, Pixar will generally make it look better. Still, given that PRman (Photorealistic Renderman-- Pixar's Renderman renderer) isn't a ray-tracer and thus can't do more realistic reflections, shadows, and refractions (you'll notice that you'll never see two reflective things next to each other in Pixar films because PRman can't handle doing a hall of mirrors without a lot of kluding, or passing the scene off to a different renderer), they obviously have their limits.
Well, lets see. A turing machine can be (and is) used as the basis set for all programming languages. Aside from that, any set of features that allows you to create a turing machine is the basis for all languages.
This may seem a bit of a snide comment, but i have a point. The question is not whether you can do it, the question is how easilly you can implement the features of the other languages, which is a hell of a nebulous thing.
It's an interesting question, though, because a corrilary is the question of what languages you can abstract in such a way that they can work together transparently. If you look at what Microsoft has done with.NET (shudder), their VM is geared towards the C++alikes and up, including C++, C#, VB.NET (not the older VB-- there were significant incompatibilities), Perl, and if it weren't for the political issues, Java would be on the list too. People are working on the lower level languages, but it's tough and ugly because the system is geared towards the whole OOP paradigm (from what i am told, the basic VM instructions look quite a bit like C# in design).
I guess i just think the question is a bit nebulous. I mean, he can answer, but it's hard to show that his set of functionality was any better than anyone else's unless you actually implemented it-- well, unless there was a glaring omission or something.
Phone books give people the tools to create the copyrighted tones, and infringe on the copyrights. Thus, they, like Napster or DeCSS, are accessories to copyright infringement, and illegal in the US.
By that same logic, if I pay you to fix my car, and you then walk over and break my windows, i just shouldn't pay you to fix my car again.
The point is that when i enter my personal information on a website, i'm entering into an agreement to provide them with personal information on contingency that they use it in the stated manner. If they state that they can retroactively change the licence at any time, then anything's fair game, as long as they include it in the licence, but if they don't, then they have no right to use the information for any other purpose.
The reason there are any laws governing commerce is because of situations like this, where "buyer beware" doesn't apply.
Okay, a lot of good points have been made. Specifically, production restraints on the consoles, but they also want to see which games flop and which do well (though i know that what does well in Japan doesn't always do well here).
Anyway, I know with most consoles in the past, the games and hardware are region-specific. that is, a Japanese game will not play in an American unit, and vice versa. Now, i'm pretty sure this is just an artificial limitation to stop export of the consoles, but it does mean that you can't just pick up 100,000 consoles from Japan and sell them here unless you know a 100,000 people that want Japanese-language games.
Then again, i wouldn't put that past some people...
You talk about the amazing (my word) performance of your 2D hardware and how using OpenGL will toss all that out the window.
Well, I'm gonna let you on to a little secret that game programmers know all too well. Doing 2D graphics is usually faster if you use the 3D hardware to do it. Now, it does depend on what you're doing, but overall, putting sprites onto polygons and blitting the polygons to the screen is faster than drawing the sprites on the screen directly.
I know these seems odd, but it's really just a fact of the video cards being great for 3D (or bad for 2D, if you want to look at it that way). There's just been so much of a push for 3D in cards, and not too many people have been asking for better 2D performance, so the current crop of video cards is kinda lop-sided.
Microsoft even stopped developing new versions of DirectDraw. They say that if you want to make 2D applications, use Direct3D. This wasn't because DirectDraw was done, or because they want all new games to be 3D, but because 2D graphics API's are becoming insufficient.
Unless i missed something, no one was talking about moving the windows around in 3D. It's strictly a performance thing.
Okay. Start with this: why the hell does kwrite automatically copy selections into the clipboard whether I want it to or not? (Did that on RH6.0, anyway; I haven't really paid attention to whether it's been fixed since).
This is a feature in X, not a bug. If you don't like it, you can turn it off. Well, unless KWrite does it explicitly (as opposed to the general way most apps use). Now, the real question is why Redhat doesn't make this easily configurable.
Why are we letting politics dominate our desktop decisions? And why the hell isn't the Linux community trying to forge alliances with the Mac community?
Some might argue that those politics are why we're here. Now, I agree that you can (and people do) go too far with it, but the reason that Microsoft and others can't just assimilate GNU/Linux is because of things like the GPL and decentralization. As for alliances with the Mac community, I think there are hurt feelings on both sides. Plus many developers think Apple has a rather one sided view of sharing. I can't speak on this myself, but i do know that Apple is rather trigger-happy with the lawyers which does keep me the hell away, both from anger and fear of litigation.
Still, i think you have a point about forming alliances. I think first we should look to the other UNIX's, where most any software can be ported with a minimum of effort. Then look towards the BeOS's, Macs, QNX's, etc. The problem, of course, is that all these OS's are competing for a lot of the same users, so there's bound to be some friction.
When the Mac came out, Apple put out the Mac Human Interface guidelines. Microsoft has its own rules for Windows. We have no such thing for either of the significant Linux desktops. Believe it or not, this is a bad thing. For this to work we need some interface guidelines, preferably written by someone using both MacOS and Linux (since Mac users as a general rule are more sensitive to clumsy interface design)
I agree for the most part, but I will say that I've been really unimpressed by Apple type designs (Nautilus, for example). That's not to say that there's nothing to be learned from Mac users, but I'd like to see some of the UNIX spirit in the GUI. Small, powerful apps (or pieces, ala CORBA) that can be linked together with scripts (read "high level languages." Whoops! There's your RAD) rather than these monolithic monstrosities. Power should NOT be sacrificed for simplicity. If there's no way to make something both usable for the average layman and powerful for those of us who're interested, then make to versions that are as compatable as possible. There does not need to be one answer to everything, there should just be one default. We'll get nowhere by copying other desktops. We have to go with what works, and scrap the rest.
As for the matter of open source desktop apps, we only have ourselves to blame. Browser?
Hey, I hear great things about Konq.
If you have nothing at all to contribute to OpenOffice or any of its competitors, you have no
right whatsoever to bitch about articles like this.
Yeah! Anyone who's working on GNOME and KDE but not an office suite should shut their yaps! Wait, no. I think anyone who's happily using Linux as a desktop enviroment has a right to disagree with articles like this. That's not to say there aren't valid points, but there are plenty of problems in the arguements, too. Everyone who wants Linux on the desktop seems to be saying, "Come on! We need to clone these other desktops. Forget what got us this far, let's get in shape and do what Apple/Windows did!" But as I said earlier, we have to use our strengths, and improve where these other GUIs didn't. I don't think choice has to be a bad thing if we also have good standards.
Why can't [g]vim and [x]emacs live side by side? How about a CORBA object for displaying/editing text, and let the user choose vim, or nedit, or kwrite, or emacs, or whatever? Choice doesn't have to be bad.
The Linux world needs to swallow its pride and accept that some decisions do need to be made from above, or at least proposed from above and accepted by a critical mass.
Like the Linux kernel and Linus Torvalds? Or like Perl and Larry Wall? Maybe more like Python and Guido van Rossum? Or GNOME and Migel de Icaza? Granted, there's still room for inter-project cooperation, but with the exception of a few feuding factions, I think we're pretty good about that. Even GNOME and KDE are getting along better these days.
Our desktop flagship programs are huge. Mozilla is about a 20MB source tarball IIRC, and I believe OpenOffice is well over 300MB. This is IMHO unacceptable in a Unix-based community; monolithic office suites are a Bad Thing to begin with, and given that there hasn't been a really core-type feature invented since the multidimensional spreadsheet I have to wonder where all this bloat is coming from (since I don't use it I could be off-base).
My guess is that a lot of it is coming from the feature-cloning with regards to MSWord, though I couldn't say definitely, since I don't use OpenOffice. My point is that for the media to say, "oh, Linux is becoming a viable desktop OS" we need all that bloat. They want to see the "Linux version of/counterpart to" MSWord, Excel, and all those other ones. If you're really just looking for functionality, pick up emacs and LaTeX. If you want all the razzle-dazzle of MSWord, you're going to have to take the bloat that comes with it too.
We need more than developers in the Open Source community, you see. What's missing from the Open Source equation is support personnel like tech writers and creative people.
I couldn't agree more! So much of the current work towards UI design is being put towards making stuff pretty, when what people really want is making the GUI usable. Even some of the people doing GUI design at Redhat make dumb mistakes, such as asking for data that could've been inferred, or making a window pop up in front of the information to enter into the window... In GNOME (last i used it, at least), there's plenty of pretty stuff, but why can't i set up the working directory for a program I launch off the bar? Why can't i easily make global revisions to my application menu without su'ing to root? It almost makes me want to fix these things myself.
How this got modded up is beyond me. Not only is it not insightful, it's downright wrong!
When communicating to local hardware, there is no TCP/IP anywhere. It communicates over a local socket. It has been implemented with shared memory, and guess what? It didn't perform any better than over a local socket! That's why you don't see shared memory in XFree today.
And i dunno about you, but my fonts look just fine. They're probably the same TrueType fonts you've seen a million times on Windows.
b.c
While i agree with your main point that having a homogeneous computer environment, especially in computer science, is a bad thing, but i do have one nit to pick.
You write that "your college students are there to learn and be trained for the work-place of tomorrw," but that's only really true if this is a trade school he's talking about. Granted, these days education-- even higher education-- is generally seen as a way to get a good job, but the point of a real college or university, as opposed to a trade school, is general education, not to teach one a trade (aka how to do a job). Generally, college is supposed to teach you good ways to think about problems, and give you an informational base to work from. A good education will allow you to apply what you've learned through the tools available.
Having said that, there are many useful lessons to be learned in interoperating between computing environments. I use Linux almost exclusively, but most of the people i develop with use Windows. There are challenges to writing cross-platform code that are good to know, especially if you're going off into the commercial software development world, 'cause out there, if you're writing end-user software, and you don't know how to manage cross-platform projects, there's slim-to-no chance you'll end up using it under Linux. If you know the pitfalls however, your chances are a bit better (though still not all that good).
b.c
You're indeed right about strategy turn-based war games, but i think it's only because it's a niche audience that's more accepting of alternative distribution channels. I can't comment on the text adventures, though i'm guessing the combined revenues from all text adventure sales aren't enough to support too many developers. And in both these areas, i'm guessing that the development is pretty much incremental increases. The war-game crowd basicly knows what they want, they're just looking for new tweaks and scenarios. Not to say it's entirely stagnant or all the games are the same, but rather i'm guessing they all conform rather rigidly to the genre specifics.
Galactic Civilizations and Rise of Nations are hardly big-name games. Not to say they don't have the production values, but they don't have the marketing force that real big-name games have. Black and White, on the other hand, was developed by a small company, and was a big-name game because of one person: Peter Molyneux. Not only is he something of a celebrity in game development, but he also brought millions of dollars in to fully fund development. That's how he had creative control-- he was spending his life savings.
b.c
I agree in concept, but disagree in practice.
I use fluxbox, which for those of you not in the know, is a windowmanager based on Blackbox that implements tabs for windows in a general way. I can make a window with multiple mozilla tabs, or lynx tabs, or terminal tabs, or i can make a window with a terminal on one tab, the progress report for my cd burning on the next tab, and Quake on the next tab. It's a great, general solution, and it actually saves so much screen realestate, i use my multiple desktops much less frequently (pretty much only when i want different layouts of windows on the screen).
However, the problem is that the way i use tabs in Mozilla would require some amount of intelligent interaction between Mozilla and fluxbox for opening tabs in new windows, in the background or the foreground, using mouse gestures to move between them, etc. All but the last of these could (and should) be handled by the windowmanager prereferences for that program, but what about the last? Should we roll gestures into the windowmanager as well? What about radial context menues? These are, in my opinion, some interesting questions, and ones to which i don't have the answer. What i will say, however, is that in the state of things today, in applications that make heavy use of interactions between the "documents", MDI still makes sense.
b.c
Yes, and my point, which i now realize i could've made clearer in my post, is that they DO attempt to use some faux focus in motion pictures-- if they didn't, it'd look even worse-- but it's really hard to get right, and they often err on the side of overly-clear.
b.c
You're half-right.
On the one hand, focus is the issue here. Focus is very important, and i myself HATE when the CGI looks like CGI because it's too in focus.
BUT, as someone who's done a few high-quality computer animated shorts, there's a large amount of work that goes into, and a significant number of applications to help with, post-processing effects, such as blur and focus and color temperature. It's fundamentally a very hard problem. For color and lighting, Paul Debevec has been doing a lot of new and interesting things to use real-world lighting to light computer models, and computer lighting to light real people. As for blur and focus, i'm not sure of any really good algorithms or techniques, but in practice, it's largely all hand-tweaked, which is bound to be imperfect.
It's easy to say that "damn CGI artists don't know what the word 'focus' means," but when you take a good look at the problem, it's hardly that trivial.
ben.c
I've used a couple of the big-name packages in this area (Maya, Lightwave, Renderman(prman & bmrt)), but i'm primarilly a programmer. Being a programmer of 3d applications at that, i have a few suggestions as to how you do it:
...). This doesn't mean you won't also want some simple command-language as well, but for the heavier-duty stuff, i think Python's your language, but then, it's really personal preference. I suggest you go with something that's clean and robust and has good, easy C or C++ language bindings.
First, encapsulate the system-specific stuff, preferably through pre-existing libraries where available. You can encapsulate the 3D renderer as well, though i'd suggest just picking one (*cough* OpenGL *cough*) and doing it well, at least at first, not worrying about wrapping it up. Next, i'd design the entire interface in said 3D rendering context or other windows popped up from it, both so that you don't have to worry about gui consistency across platforms, and so that it goes fast with fewer big library dependencies. There are a couple cross-platform libraries that do GUIs for OpenGL out there.
Now, if you've used Maya much, you'll know that it's basically a big programming enviroment with a few graphics hooks. The rest is scripted. It's truly amazing, but i think that this is quite vital. I'd suggest using SWIG or Boost::Python to do Python interfacing to your compiled code, and use Python to build the interface and implement a lot of the details (some tools, basic relationships,
Don't worry about a rendering engine, just get it to work with Renderman (prman, entropy, bmrt, etc.). Most renderers in comercial software fall short of those anyway.
Oh, and try to get the groundwork in there quickly, then do RAD with Python, replacing stuff as needed for performance.
So, to recap: incremental development, scriptabiliy, OpenGL everything for display, scriptability, Renderman export, and above all, scripability. Especially scriptability that's easy for artist-types to use.
I hate to be the pedant here, but if Linux had had all this in 1993, we'd be ruling the world right about now.
That is, if we had the hardware to run all that stuff back then.
Still, it is a good time to be a Linux user.
ben.c
Whoever modded this up needs to use some common sense. A record groove that's precise to under 5 nanometers? Sorry, that right there should tell you that this is lacking somewhere. Perhaps some people don't understand that the needle on your record will NOT, no mater how good it is, pick up vibrations caused by a few nanometers of change because that is literally just a handful of atoms!
Now, where the analysis is wrong is a tougher question for me. I'm guessing, however, that it has something to do with the fact that the author assumes that the info isn't encoded on a logarithmic scale. You do, after all, have to have a very special amp to use a phonograph.
b.c
Or, if they didn't want to be total hypocrites, they could just use ispell.
ben.c
That's right, this is bound to fail, but not for the reasons you're guessing. Let me start at the beginning:
In Understanding Comics, Scott McCloud discusses the various levels of abstraction in comic art. How abstract a character is has a great deal of influence on how the character is perceived. Charlie Brown is Charlie Brown because of how he is drawn as much as because of his personality. If Charlie Brown were drawn by Gary Larson, of The Far Side, or acted by Mike Meyers, it just won't feel like Charlie Brown.
If you're with me so far, then it's not too terribly large a step to say that video game characters don't translate well across levels of abstraction either. The semi-realistic Lara-croft would not feel like the same character if presented as a pudgy Mario-esque character. Of course, over franchises, characters do evolve, this is a tricky process, often involving the redefinition of a character. Donkey Kong, for example, is an entirely different character in Donkey Kong Country than in the original Donkey Kong.
There is yet another aspect of abstraction with games. That is, the gameplay itself can be more or less abstract. Ultimately, players have no problem with a 8-bit Mario who can jump 8 times his own height, and doubles in size when touching a mushroom, but in a 3d third-person shooter, this would seem quite out of place.
So, ultimately, my point is that games that go back and forth from 128-bit near-photo-realistic graphics and advanced simulation to 128x128 pixel monochrome display with menu-based simple game mechanics will ultimately not be terribly compelling. This is more true for games whose characters, settings, and mechanics are more technologically advanced and more realistic. It would be like watching a movie with your favorite actors, and then when you're out of the house, getting to see a cartoon version with simplified plot and dialog. Not that there's anything wrong with either form, it's just that they do not mesh well together.
There are games for which this system would work perfectly well (Pokemon coming to mind), but as the industry will not rally around the niche created by this phone, the number of games who will take good advantage of this technology will be severly limited, for good or ill.
ben.c
Alias|Wavefront just recently slashed prices significantly, actually. The $10,000 per seat is no more (still not cheap, though)!
However, i have to say that i had a similar reaction as the parent of your post. That's a cool hack, but creating an object in-scene that the eyes follow that you can place and key is really rather easy in Maya.
You raise good points though. I wouldn't inflict the Maya renderer on anyone, whereas the Lightwave renderer is quite nice in my experience. Furthermore, as of LW6.5, Maya seems to have better subdivisions, though i like Lightwave's tools and interface better.
Overall, though, i have to say that Maya is one of the most impressively scriptable and versitile tools i've ever used. Terrible interface, but if you want to do something, you *can*, without exiting the program.
ben.c
Well, the funny thing about this is that all the .NET web service stuff uses SOAP (XML) to communicate through HTTP (presumably for both ease-of-use and so that webservices can be used in places with restrictive firewalls, for good or ill). Now, this guy is undoubtably aware of this fact, but coming from that knowledge, it's interesting to note that Microsoft's .NET team:
.NET webservices onto the protocol (not that i've heard anything about shortcomings-- it's been a couple months since i've worked with .NET at all).
a) Bases their web services on communication via HTTP then
b) Says HTTP is doomed because it's not peer to peer
Maybe someone made a bad choice for their protocol and is trying to cover his ass? I doubt it. Maybe they're trying to shift blame for any shortcomings of
Or maybe this guy has a point, which i doubt, but i'm far from qualified to really judge.
ben.c
" What will this do to Transgaming? They will no longer be able to make changes and keep them to themselves - kind of seems like it destroys their business model. "
Well, i'm not sure about how Transgaming works, but they could always fork a version of Wine from before it turns LGPL. Or, as someone else said, they could try to do a dual-licenced Wine, and pay for a version that they don't have to disclose the source to. That'd probably be difficult to do on a project that wasn't set up like that from the beginning, though (copyright holders may not be so willing to give away their privledges if someone will be making a buck on it).
ben.c
I'll avoid most of my comments about your choice of language because most of it is of a political nature, rather than practical one; however, I really wouldn't suggest trying to make a massively multiplayer game with a language you're unfamiliar with. It's quite an undertaking even with a language you know. I know; i'm working on one.
As for the networking code transparency, this one seems fairly obvious to me.. Just keep a datastructure containing all the changed or "tainted" objects as you go. Make mutator functions of your classes set objects as tainted. Then, just do the networking updates once or twice every time through the main loop (assuming it's in the same thread. Otherwise, you can implement something that might end up being a little more efficient).
As for updating only what the player needs to be updated on, this seems like a question of algorithm efficiency. I don't know the specifics of your game, but with most massively multiplater games, transmitting the entire world state, or even the entire list of changes to every client, every cycle would be insane. So, you have to only update the section of the world that the player can see. How to do this well depends on the internal structure of the world, and what sort of stuff the player can "see". If the game is room-based, then this is easy. If the player can always just see a specific size circle or rectangle around him, this is also easy (each event can check distance to all players in its regeon). If it works like most RTS with arbitrary viewing areas, then you might have to be a little more clever. Whether this is even much of a concern is really a question of the number of people supported, and the expected hardware this'll be running on.
Hope that helps,
ben.c
A few people have pointed out that if you're the sole contributor, you're free to licence the software as you see fit. However, even if this is the case, I don't think it solves the problem. Essentially what the author wants is to keep the codebase Free and have all changes come back to the community. What the author doesn't care about that the LGPL does is the ability to relink with other libraries, since that can be pretty diffecult with hardware.
After a little exploration at gnu.org's Free licence list i saw the "licence of Guile" (third one down) that looks like exactly what you're looking for. The licence is not on the web, though, so you'll have to download Guile and see for yourself. It says it's essentially the GPL only with a blanket statement allowing linking with non-free software.
Hope that helps,
ben.c
"Also, if videogames are considered art than what stops other computer programs from also being considered art? Censoring videogames because of violence or even programs because of DMCA-type laws may be considered censoring art - something that many Americans have traditionally been very opposed to?"
This is like saying that because paintings are art, then what's to stop us from saying that normal old house-painting is art, and thus city ordinances on the appearence of buildings are violating first ammendment rights by censoring art.
I'm not saying all code is or isn't art, i'm just saying that code isn't automatically art. Furthermore, i think the submitter obviously has no real care for whether or not it's actually art, but only would the official "art" status would mean for code in general, which is a fairly bad way to approach proving that code is art.
Code is a tool, like paint. Paint, in certain configurations is considered to be art, but paint does not make something art, and in fact, it's fairly difficult to make paint into good art. Throwing the blanket statement of "code is art" around just seems silly and shows that the speaker doesn't really understand what most people talk about when they talk about what is "art".
ben.c
Well, of course they used RiCurves, all the Renderman hair shaders i've ever seen use RiCurves, but the question is how they got it to look SO much like hair.
For example, the scene where Sully is in the blizzard, lying on the ground, the interaction between his hair, the snow particles, and the wind just knocks my socks off. It really looks like there's quite some wind turbulance, though i wouldn't be too surprised if it's something simpler, like a couple moving "fans".
I'll agree that at this point, they only seem to be able to do very clean, very straight hair, but in that domain, it's damn impressive. I think the problem may be hairs interacting with each other-- i couldn't even tell you if there's any collision detection in Sully's hair at all, and self-intersection tests and other collision detection could GREATLY slow down rendering, though i once heard a guy from Pixar saying that if given the option of making it look a little better makes it take significantly longer, Pixar will generally make it look better. Still, given that PRman (Photorealistic Renderman-- Pixar's Renderman renderer) isn't a ray-tracer and thus can't do more realistic reflections, shadows, and refractions (you'll notice that you'll never see two reflective things next to each other in Pixar films because PRman can't handle doing a hall of mirrors without a lot of kluding, or passing the scene off to a different renderer), they obviously have their limits.
ben.c
Well, lets see. A turing machine can be (and is) used as the basis set for all programming languages. Aside from that, any set of features that allows you to create a turing machine is the basis for all languages.
.NET (shudder), their VM is geared towards the C++alikes and up, including C++, C#, VB.NET (not the older VB-- there were significant incompatibilities), Perl, and if it weren't for the political issues, Java would be on the list too. People are working on the lower level languages, but it's tough and ugly because the system is geared towards the whole OOP paradigm (from what i am told, the basic VM instructions look quite a bit like C# in design).
This may seem a bit of a snide comment, but i have a point. The question is not whether you can do it, the question is how easilly you can implement the features of the other languages, which is a hell of a nebulous thing.
It's an interesting question, though, because a corrilary is the question of what languages you can abstract in such a way that they can work together transparently. If you look at what Microsoft has done with
I guess i just think the question is a bit nebulous. I mean, he can answer, but it's hard to show that his set of functionality was any better than anyone else's unless you actually implemented it-- well, unless there was a glaring omission or something.
ben.c
Phone books give people the tools to create the copyrighted tones, and infringe on the copyrights. Thus, they, like Napster or DeCSS, are accessories to copyright infringement, and illegal in the US.
Same with telephones, i guess.
ben.c
By that same logic, if I pay you to fix my car, and you then walk over and break my windows, i just shouldn't pay you to fix my car again.
The point is that when i enter my personal information on a website, i'm entering into an agreement to provide them with personal information on contingency that they use it in the stated manner. If they state that they can retroactively change the licence at any time, then anything's fair game, as long as they include it in the licence, but if they don't, then they have no right to use the information for any other purpose.
The reason there are any laws governing commerce is because of situations like this, where "buyer beware" doesn't apply.
ben.c
Okay, a lot of good points have been made. Specifically, production restraints on the consoles, but they also want to see which games flop and which do well (though i know that what does well in Japan doesn't always do well here).
Anyway, I know with most consoles in the past, the games and hardware are region-specific. that is, a Japanese game will not play in an American unit, and vice versa. Now, i'm pretty sure this is just an artificial limitation to stop export of the consoles, but it does mean that you can't just pick up 100,000 consoles from Japan and sell them here unless you know a 100,000 people that want Japanese-language games.
Then again, i wouldn't put that past some people...
ben.c
You talk about the amazing (my word) performance of your 2D hardware and how using OpenGL will toss all that out the window.
Well, I'm gonna let you on to a little secret that game programmers know all too well. Doing 2D graphics is usually faster if you use the 3D hardware to do it. Now, it does depend on what you're doing, but overall, putting sprites onto polygons and blitting the polygons to the screen is faster than drawing the sprites on the screen directly.
I know these seems odd, but it's really just a fact of the video cards being great for 3D (or bad for 2D, if you want to look at it that way). There's just been so much of a push for 3D in cards, and not too many people have been asking for better 2D performance, so the current crop of video cards is kinda lop-sided.
Microsoft even stopped developing new versions of DirectDraw. They say that if you want to make 2D applications, use Direct3D. This wasn't because DirectDraw was done, or because they want all new games to be 3D, but because 2D graphics API's are becoming insufficient.
Unless i missed something, no one was talking about moving the windows around in 3D. It's strictly a performance thing.
ben.c
I actually really like this name. It fits well with the Gimp, yet makes sense. My vote goes for KInk.
ben.c
Okay. Start with this: why the hell does kwrite automatically copy selections into the clipboard whether I want it to or not? (Did that on RH6.0, anyway; I haven't really paid attention to whether it's been fixed since).
This is a feature in X, not a bug. If you don't like it, you can turn it off. Well, unless KWrite does it explicitly (as opposed to the general way most apps use). Now, the real question is why Redhat doesn't make this easily configurable.
Why are we letting politics dominate our desktop decisions? And why the hell isn't the Linux community trying to forge alliances with the Mac community?
Some might argue that those politics are why we're here. Now, I agree that you can (and people do) go too far with it, but the reason that Microsoft and others can't just assimilate GNU/Linux is because of things like the GPL and decentralization. As for alliances with the Mac community, I think there are hurt feelings on both sides. Plus many developers think Apple has a rather one sided view of sharing. I can't speak on this myself, but i do know that Apple is rather trigger-happy with the lawyers which does keep me the hell away, both from anger and fear of litigation.
Still, i think you have a point about forming alliances. I think first we should look to the other UNIX's, where most any software can be ported with a minimum of effort. Then look towards the BeOS's, Macs, QNX's, etc. The problem, of course, is that all these OS's are competing for a lot of the same users, so there's bound to be some friction.
When the Mac came out, Apple put out the Mac Human Interface guidelines. Microsoft has its own rules for Windows. We have no such thing for either of the significant Linux desktops. Believe it or not, this is a bad thing. For this to work we need some interface guidelines, preferably written by someone using both MacOS and Linux (since Mac users as a general rule are more sensitive to clumsy interface design)
I agree for the most part, but I will say that I've been really unimpressed by Apple type designs (Nautilus, for example). That's not to say that there's nothing to be learned from Mac users, but I'd like to see some of the UNIX spirit in the GUI. Small, powerful apps (or pieces, ala CORBA) that can be linked together with scripts (read "high level languages." Whoops! There's your RAD) rather than these monolithic monstrosities. Power should NOT be sacrificed for simplicity. If there's no way to make something both usable for the average layman and powerful for those of us who're interested, then make to versions that are as compatable as possible. There does not need to be one answer to everything, there should just be one default. We'll get nowhere by copying other desktops. We have to go with what works, and scrap the rest.
As for the matter of open source desktop apps, we only have ourselves to blame. Browser?
Hey, I hear great things about Konq.
If you have nothing at all to contribute to OpenOffice or any of its competitors, you have no
right whatsoever to bitch about articles like this.
Yeah! Anyone who's working on GNOME and KDE but not an office suite should shut their yaps! Wait, no. I think anyone who's happily using Linux as a desktop enviroment has a right to disagree with articles like this. That's not to say there aren't valid points, but there are plenty of problems in the arguements, too. Everyone who wants Linux on the desktop seems to be saying, "Come on! We need to clone these other desktops. Forget what got us this far, let's get in shape and do what Apple/Windows did!" But as I said earlier, we have to use our strengths, and improve where these other GUIs didn't. I don't think choice has to be a bad thing if we also have good standards.
Why can't [g]vim and [x]emacs live side by side? How about a CORBA object for displaying/editing text, and let the user choose vim, or nedit, or kwrite, or emacs, or whatever? Choice doesn't have to be bad.
The Linux world needs to swallow its pride and accept that some decisions do need to be made from above, or at least proposed from above and accepted by a critical mass.
Like the Linux kernel and Linus Torvalds? Or like Perl and Larry Wall? Maybe more like Python and Guido van Rossum? Or GNOME and Migel de Icaza? Granted, there's still room for inter-project cooperation, but with the exception of a few feuding factions, I think we're pretty good about that. Even GNOME and KDE are getting along better these days.
Our desktop flagship programs are huge. Mozilla is about a 20MB source tarball IIRC, and I believe OpenOffice is well over 300MB. This is IMHO unacceptable in a Unix-based community; monolithic office suites are a Bad Thing to begin with, and given that there hasn't been a really core-type feature invented since the multidimensional spreadsheet I have to wonder where all this bloat is coming from (since I don't use it I could be off-base).
My guess is that a lot of it is coming from the feature-cloning with regards to MSWord, though I couldn't say definitely, since I don't use OpenOffice. My point is that for the media to say, "oh, Linux is becoming a viable desktop OS" we need all that bloat. They want to see the "Linux version of/counterpart to" MSWord, Excel, and all those other ones. If you're really just looking for functionality, pick up emacs and LaTeX. If you want all the razzle-dazzle of MSWord, you're going to have to take the bloat that comes with it too.
We need more than developers in the Open Source community, you see. What's missing from the Open Source equation is support personnel like tech writers and creative people.
I couldn't agree more! So much of the current work towards UI design is being put towards making stuff pretty, when what people really want is making the GUI usable. Even some of the people doing GUI design at Redhat make dumb mistakes, such as asking for data that could've been inferred, or making a window pop up in front of the information to enter into the window... In GNOME (last i used it, at least), there's plenty of pretty stuff, but why can't i set up the working directory for a program I launch off the bar? Why can't i easily make global revisions to my application menu without su'ing to root? It almost makes me want to fix these things myself.
Of course, then i found WindowMaker.
-ben.c