RLE + VLC? This is one of the first things people try when toying with data compression. Of course, usually the VLC of choice is huffman or arithmetic coding. Huffman has been around since the 50s, RLE even longer, combinations of the two were omnipresent in early archive formats, among others. Now, patenting one very specific VLC technique, that is another matter. But patenting RLE + VLC in general is just braindead.
There is nothing redeemable about Forgent Networks' JPEG RLE patents (which is *extremely* trivial), the infamous Acacia project-killer, the Alcatel-Lucent MP3 patent trolling, Creative Labs' game audio innovation lockdown and zfail-Shadow Volume-Patents etc.
All of these used trivial patents to squash companies that were actually producing something. They contribute nothing and just act like bloodsuckers. I doubt anybody would be sad to see these go.
Also, you seem to think that only large companies want this reform. In fact, EVERY PROGRAMMER OUT THERE wants it. We want to develop without danger of infringing trivial nonsensical patents like the "progress bar patent".
With some notable exceptions like the blind spot in the eye, the kneecap, or our teeth. Also, why is the liver the only organ which can grow back? Why don't we have limbs that can regrow? Why can't we control our own immune system consciously, for example to designate HI and Influenza viruses as hostile?
Wrong. I am thinking of C++. Count the times you pass a reference or a pointer vs. the times you actually want to copy large, complex objects. The outcome is pretty clear. Hell, boost even contains a "noncopyable" class as a tool to disallow deep copies.
Deep copies are the exception. Shallow copies are the rule. This is totally obvious, and virtually all other languages do it this way. The only two reasons why C++ doesn't have it that way are the C legacy and the ownership problem (which is solved by the GC).
Yet another problem with by-value as default are move semantics. It basically boils down to the problem of extra copies in return values. C++0x sort of fixes it with the aforementioned move semantics. See http://www.codeguru.com/cpp/misc/misc/versioninfo/article.php/c14443 for more. Note that this issue is an artifact of the by-value-default design decision in C++.
So in 99.999% of cases, you don't want a to pass by reference or to copy the object - instead, you want to pass a copy of the pointer to some instance.
Wrong conclusion. Your example just shows that the assignment operator is ill-defined. Besides, this is possible in D, since you can overload the assignment operator.
And, how to do actual copies of the object? Since doing *deep* copies is rarely done on purpose, a clone() method is the way to go.
No multiple inheritance is pretty good from a readability & codability viewpoint, as long as there is some mechanism that allows you to more clearly express your concept (i.e. Java interfaces). Multiple inheritance creates confusion potentially - which parent am I inheriting function foo from if both of them declare it? What is the destructor order if parents have virtual destructors?
I take it you never did C++ metaprogramming then? Never implemented policies, CRTP and the like?
Not sure what your problems with operator overloading are. Presumably you think that the return value should be part of the method's signature. Not sure if this is a good or bad idea - maybe it creates issues for compiler writers & ambiguity in the error messages?
See this example:
x[5] = 1;
How is this done in C++? x' index operator returns an lvalue (e.g. a non-const reference), whose type in turn defines the assigment operator. This is the right way, since retrieval and assignment are two orthogonal concepts. What if x is some sort of container class? If there were a "[]=" operator, the container class would have to define retrieval *and* assignment. But the latter is not the container's job.
D has an opIndexAssign operator, which is "[]=". Fortunately, there is progress; an opIndexLvalue operator has been accepted into D2. However, opIndex would be sufficient if it were possible to define the return value itself as an lvalue.
The GC is the way to go for complex application. The reason is simple: the GC has a global overview over all memory usage of the application (minus special stuff like OpenGL textures). This means that the GC can reuse previously allocated memory blocks, defragment memory transparently, automatically detect and elimitate leaks etc.
Somewhat less obvious is that a GC allows for by-reference assigments being the default. In C++, by-value is default. a = b will always copy the contents of b to a. While this is OK for primitive stuff, it is certainly not OK for complex types such as classes. In 99.999% of all cases, you actually want a reference to an object, and not copy that object. But, as said, the default behavior of assignment is "copy value".
This is a big problem in practice. The existence of shared_ptr, reference counting pointers etc. are a consequence. We could redefine the default behavior as "pass a reference of b to a", but who will then take care of the lifetime of b? Using a GC, this last question is handled trivially; when the GC detects 0 references, b is discarded.
Now, once you have by-reference as default, things like closures get much easier to introduce. Neither D nor C++ have them at the moment, but C++0x requires considerably more efforts to introduce them. Functional languages all have a GC for a reason.
D did another thing right: it did not remove destructors, like Java did. Instead, when there are zero references to an object, the GC calls the destructor *immediately*, but deallocates the memory previously occupied by that object whenever it wishes (or it reuses that memory). This way RAII is possible in D, which is very useful for things like scoped thread locks.
They also simplified the syntax, which is one of the major problems of C++. Creating D parsers is not hard. Try creating a C++ parser.
Now, what they got wrong: - operator overloading - const correctness - lvalue return values (which would solve most of the operator overload problems) - no multiple inheritance (which does make sense when using generic programming and metaprogramming; just see policy-based design and the CRTP C++ technique for examples) - crappy standard library called Phobos (getting better though) - and ANOTHER de-facto standard library called Tango, which looks a lot like a Java API and makes little use of D's more interesting features like metaprogramming, functional and generic programming
And here is was, thinking that they had an actual jet pack. But this... this is just a useless toy. Hey - when I want to fly around in the city, a *hose* isn't exactly practical.
But this leads to some inherent problems with jetpacks and flying cars: fuel problems aside, these things would be *hard* to pilot. Just think about it - you're flying around with your shiny jetpack, at what, 150mph? Imagine the accidents that could happen, or the amount of skill necessary to remain in control of that thing. Same for flying cars. Just look at the number of *regular* car accidents. Adding an extra degree of freedom will not exactly lower down that number.
C allows for things that just don't make sense on GPUs. Arbitrary branching, pointer aliasing, etc. are poisonous for GPU performance.
GPUs excel at tasks that map N input values to one output value, with a minimum amount of unpredictable branches. If a task fits in this well, it is likely being accelerated already, via CUDA, Stream, CTM. If it doesn't fit, forcing it on the GPU is a waste of time.
What you want to look at are things like C++ DSELs, which create expression templates out of compile-time defined language specifications. This way, you can have a "shader language" that is evaluated at compile-time, either to a "real" shading language, or to plain old C++ code for the CPU.
Indeed. In fact, I think that cheap non-volatile RAM will be the Next Big Thing, since fundamental paradigma will change. As you said it, no real booting done, data rarely moved etc. To fully exploit this, new operating systems have to be written, since ALL existing ones are based on the assumption that you have to copy data to RAM. "Opening" a file would equal getting a pointer to the memory block. Fragmentation would be an issue, though.
Upon entering the bus, passengers have two options: pay for a ticket, or start eating beans and provide fuel for the vehicle. Don't forget to lift the lid, sir, we don't want to make a mess, do we?
Holy crap. This is how US schools are like? I've never been more glad to have grown up in Europe.
The "land of the free".... with authoritarian boot camps nicknamed "schools".
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 1
In sum, moc is a minor nuisance, not more. Good documentation, RAD and API are *far* more important.
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 5, Informative
Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView (actually, *no* toolkit out there has anything like this).
You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit, the best opensource one out there. Using new features don't guarantee a top result, and vice versa.
Perhaps nothing like that, especially as a single project that does everything. OTOH, part of the beauty of open source is that one project doesn't have to do everything.
The problem is that game-art often must be done specifically for a game. Sure, there are stock models and textures, but these are for decorations only, or get processed (sometimes rather heavily). You just cannot design "generic" levels or "generic" characters. So, development of a game is necessarily more monolithic than your typical open source project, which can reuse tons of code.
In FPS games, the tech tends to be a more dominant factor than in other genres. For example, in strategy games, the tech is quite unimportant. Balancing has a much higher priority. And balancing is donen by a designer, not a programmer. How many opensource coders exist who are competent game designers as well?
Another example: Deus Ex (part 1, that is). It is extremely unlikely such a game can ever be done non-commercially. Sure, coders aren't a problem, but good game design is vital for such a game. Who writes the tons of dialogue? Who designs the levels? Who shall be lead designer? Etc. Usually, you just don't get such people without money. You are extremely lucky if you do.
You mentioned FreeCiv. It has been in development since 1996 and is one of the few examples of actually finished open source games. Note that its game art is rather simple, compared to today's games. As a result, many tilesets exist.
But since the complexity of game assets and design for something like Deus Ex, Half-Life 1 & 2, Halo, System Shock, Starcraft etc. is orders of magnitude higher, I highly doubt such games will ever exist as opensource.
Compare an open-source space sim like Vega Strike (which is actually quite good) to something like X3. Game-asset wise, X3 wins, but this is an unfair comparison. Why? Because the company which made X3 spent tons of money designing the art.
I can already see Indian sub-inspectors extorting people with records of porn they watched. Seriously, a morality police is among the worst things imaginable, it is like the crown of this totalitarian bill.
Have a look at Crytek. They have about 4-5 programmers, and created their own AAA engine. (It took them quite a while though.)
You are right with the middleware though. Especially the toolchain is whats sorely missing in many open source engines. Just imagine developing games with the UnrealEngine, but without UnrealEd. Or Source games without Hammer etc. I would even go as far as saying that the engine itself is the *secondary* component, while the level editor, the importers etc. are the most important ones.
As for the initial project: all projects *need* some sort of dictator at the helm. Grassroot democracy does not work in projects. Unfortunately, many open-source projects fall in this trap (gtkmm 1 was a good example), and nothing gets done, or the results are mediocre.
You hit the nail on the head, sir. It is not uncommon to see tons of artists and designers, but only 5 programmers in a commercial game development team.
I wonder though if one successful open source game - not just a quake3 mod, but an entire game including top-notch design and custom-made game art - would kickstart a wave of similar projects. At the very least, it would serve as an example how it can succeed.
The big reason windows wins for gaming isnt that everyone HAS windows. It's that the developers find programming for windows is EASY!
Wrong. The big reason Windows wins is that developing games for it actually may pay off. Linux is too small for this. Back in the days when the PS2 was No 1, developers wrote games for it, even though its "SDK" was horribly crappy (basically a modified gcc whipped up together with some basic docs).
2.6 vs. 2.4 should be obvious - TONS of new useful features, added drivers... As of 2.6.28, it incorporates GEM, which will be very useful for graphics driver development.
Slashdot Mirror
RLE + VLC? This is one of the first things people try when toying with data compression. Of course, usually the VLC of choice is huffman or arithmetic coding. Huffman has been around since the 50s, RLE even longer, combinations of the two were omnipresent in early archive formats, among others. Now, patenting one very specific VLC technique, that is another matter. But patenting RLE + VLC in general is just braindead.
There is nothing redeemable about Forgent Networks' JPEG RLE patents (which is *extremely* trivial), the infamous Acacia project-killer, the Alcatel-Lucent MP3 patent trolling, Creative Labs' game audio innovation lockdown and zfail-Shadow Volume-Patents etc.
All of these used trivial patents to squash companies that were actually producing something. They contribute nothing and just act like bloodsuckers. I doubt anybody would be sad to see these go.
Also, you seem to think that only large companies want this reform. In fact, EVERY PROGRAMMER OUT THERE wants it. We want to develop without danger of infringing trivial nonsensical patents like the "progress bar patent".
99/100 here, using the official 4.5 release. Apparently, the link test fails.
Debian does it right by simply declaring a certain snapshot of their stuff as a release.
Gentoo does this, too: their releases are basically snapshot dumps.
With some notable exceptions like the blind spot in the eye, the kneecap, or our teeth. Also, why is the liver the only organ which can grow back? Why don't we have limbs that can regrow? Why can't we control our own immune system consciously, for example to designate HI and Influenza viruses as hostile?
Ah! A command-line neutron bomb?
I am sure Linux is ready for the desktop now.
For marketing reasons, the developers prefer to call Bash 4.0 SP1 "Bash 7" and sell it as a full-price product.
I'm sure you're thinking of Java or C.
Wrong. I am thinking of C++. Count the times you pass a reference or a pointer vs. the times you actually want to copy large, complex objects. The outcome is pretty clear. Hell, boost even contains a "noncopyable" class as a tool to disallow deep copies.
Deep copies are the exception. Shallow copies are the rule. This is totally obvious, and virtually all other languages do it this way. The only two reasons why C++ doesn't have it that way are the C legacy and the ownership problem (which is solved by the GC).
Yet another problem with by-value as default are move semantics. It basically boils down to the problem of extra copies in return values. C++0x sort of fixes it with the aforementioned move semantics. See http://www.codeguru.com/cpp/misc/misc/versioninfo/article.php/c14443 for more. Note that this issue is an artifact of the by-value-default design decision in C++.
So in 99.999% of cases, you don't want a to pass by reference or to copy the object - instead, you want to pass a copy of the pointer to some instance.
Wrong conclusion. Your example just shows that the assignment operator is ill-defined. Besides, this is possible in D, since you can overload the assignment operator.
And, how to do actual copies of the object? Since doing *deep* copies is rarely done on purpose, a clone() method is the way to go.
No multiple inheritance is pretty good from a readability & codability viewpoint, as long as there is some mechanism that allows you to more clearly express your concept (i.e. Java interfaces). Multiple inheritance creates confusion potentially - which parent am I inheriting function foo from if both of them declare it? What is the destructor order if parents have virtual destructors?
I take it you never did C++ metaprogramming then? Never implemented policies, CRTP and the like?
Not sure what your problems with operator overloading are. Presumably you think that the return value should be part of the method's signature. Not sure if this is a good or bad idea - maybe it creates issues for compiler writers & ambiguity in the error messages?
See this example:
x[5] = 1;
How is this done in C++? x' index operator returns an lvalue (e.g. a non-const reference), whose type in turn defines the assigment operator. This is the right way, since retrieval and assignment are two orthogonal concepts. What if x is some sort of container class? If there were a "[]=" operator, the container class would have to define retrieval *and* assignment. But the latter is not the container's job.
D has an opIndexAssign operator, which is "[]=". Fortunately, there is progress; an opIndexLvalue operator has been accepted into D2. However, opIndex would be sufficient if it were possible to define the return value itself as an lvalue.
The GC is the way to go for complex application. The reason is simple: the GC has a global overview over all memory usage of the application (minus special stuff like OpenGL textures). This means that the GC can reuse previously allocated memory blocks, defragment memory transparently, automatically detect and elimitate leaks etc.
Somewhat less obvious is that a GC allows for by-reference assigments being the default. In C++, by-value is default. a = b will always copy the contents of b to a. While this is OK for primitive stuff, it is certainly not OK for complex types such as classes. In 99.999% of all cases, you actually want a reference to an object, and not copy that object. But, as said, the default behavior of assignment is "copy value".
This is a big problem in practice. The existence of shared_ptr, reference counting pointers etc. are a consequence. We could redefine the default behavior as "pass a reference of b to a", but who will then take care of the lifetime of b? Using a GC, this last question is handled trivially; when the GC detects 0 references, b is discarded.
Now, once you have by-reference as default, things like closures get much easier to introduce. Neither D nor C++ have them at the moment, but C++0x requires considerably more efforts to introduce them. Functional languages all have a GC for a reason.
D did another thing right: it did not remove destructors, like Java did. Instead, when there are zero references to an object, the GC calls the destructor *immediately*, but deallocates the memory previously occupied by that object whenever it wishes (or it reuses that memory). This way RAII is possible in D, which is very useful for things like scoped thread locks.
They also simplified the syntax, which is one of the major problems of C++. Creating D parsers is not hard. Try creating a C++ parser.
Now, what they got wrong:
- operator overloading
- const correctness
- lvalue return values (which would solve most of the operator overload problems)
- no multiple inheritance (which does make sense when using generic programming and metaprogramming; just see policy-based design and the CRTP C++ technique for examples)
- crappy standard library called Phobos (getting better though)
- and ANOTHER de-facto standard library called Tango, which looks a lot like a Java API and makes little use of D's more interesting features like metaprogramming, functional and generic programming
And here is was, thinking that they had an actual jet pack. But this ... this is just a useless toy. Hey - when I want to fly around in the city, a *hose* isn't exactly practical.
But this leads to some inherent problems with jetpacks and flying cars: fuel problems aside, these things would be *hard* to pilot. Just think about it - you're flying around with your shiny jetpack, at what, 150mph? Imagine the accidents that could happen, or the amount of skill necessary to remain in control of that thing. Same for flying cars. Just look at the number of *regular* car accidents. Adding an extra degree of freedom will not exactly lower down that number.
C allows for things that just don't make sense on GPUs. Arbitrary branching, pointer aliasing, etc. are poisonous for GPU performance.
GPUs excel at tasks that map N input values to one output value, with a minimum amount of unpredictable branches. If a task fits in this well, it is likely being accelerated already, via CUDA, Stream, CTM. If it doesn't fit, forcing it on the GPU is a waste of time.
What you want to look at are things like C++ DSELs, which create expression templates out of compile-time defined language specifications. This way, you can have a "shader language" that is evaluated at compile-time, either to a "real" shading language, or to plain old C++ code for the CPU.
Indeed. In fact, I think that cheap non-volatile RAM will be the Next Big Thing, since fundamental paradigma will change. As you said it, no real booting done, data rarely moved etc. To fully exploit this, new operating systems have to be written, since ALL existing ones are based on the assumption that you have to copy data to RAM. "Opening" a file would equal getting a pointer to the memory block. Fragmentation would be an issue, though.
Upon entering the bus, passengers have two options: pay for a ticket, or start eating beans and provide fuel for the vehicle. Don't forget to lift the lid, sir, we don't want to make a mess, do we?
Holy crap. This is how US schools are like? I've never been more glad to have grown up in Europe.
The "land of the free" .... with authoritarian boot camps nicknamed "schools".
In sum, moc is a minor nuisance, not more. Good documentation, RAD and API are *far* more important.
Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView (actually, *no* toolkit out there has anything like this).
You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit, the best opensource one out there. Using new features don't guarantee a top result, and vice versa.
Perhaps nothing like that, especially as a single project that does everything. OTOH, part of the beauty of open source is that one project doesn't have to do everything.
The problem is that game-art often must be done specifically for a game. Sure, there are stock models and textures, but these are for decorations only, or get processed (sometimes rather heavily). You just cannot design "generic" levels or "generic" characters. So, development of a game is necessarily more monolithic than your typical open source project, which can reuse tons of code.
In FPS games, the tech tends to be a more dominant factor than in other genres. For example, in strategy games, the tech is quite unimportant. Balancing has a much higher priority. And balancing is donen by a designer, not a programmer. How many opensource coders exist who are competent game designers as well?
Another example: Deus Ex (part 1, that is). It is extremely unlikely such a game can ever be done non-commercially. Sure, coders aren't a problem, but good game design is vital for such a game. Who writes the tons of dialogue? Who designs the levels? Who shall be lead designer? Etc. Usually, you just don't get such people without money. You are extremely lucky if you do.
You mentioned FreeCiv. It has been in development since 1996 and is one of the few examples of actually finished open source games. Note that its game art is rather simple, compared to today's games. As a result, many tilesets exist.
But since the complexity of game assets and design for something like Deus Ex, Half-Life 1 & 2, Halo, System Shock, Starcraft etc. is orders of magnitude higher, I highly doubt such games will ever exist as opensource.
Compare an open-source space sim like Vega Strike (which is actually quite good) to something like X3. Game-asset wise, X3 wins, but this is an unfair comparison. Why? Because the company which made X3 spent tons of money designing the art.
MP3 players, set top boxes, cellphones, digital picture frames, etc. require a FS, for example.
I can already see Indian sub-inspectors extorting people with records of porn they watched. Seriously, a morality police is among the worst things imaginable, it is like the crown of this totalitarian bill.
Have a look at Crytek. They have about 4-5 programmers, and created their own AAA engine. (It took them quite a while though.)
You are right with the middleware though. Especially the toolchain is whats sorely missing in many open source engines. Just imagine developing games with the UnrealEngine, but without UnrealEd. Or Source games without Hammer etc. I would even go as far as saying that the engine itself is the *secondary* component, while the level editor, the importers etc. are the most important ones.
As for the initial project: all projects *need* some sort of dictator at the helm. Grassroot democracy does not work in projects. Unfortunately, many open-source projects fall in this trap (gtkmm 1 was a good example), and nothing gets done, or the results are mediocre.
You hit the nail on the head, sir. It is not uncommon to see tons of artists and designers, but only 5 programmers in a commercial game development team.
I wonder though if one successful open source game - not just a quake3 mod, but an entire game including top-notch design and custom-made game art - would kickstart a wave of similar projects. At the very least, it would serve as an example how it can succeed.
If you're into the FPS genre, that is.
But: where are open source RPGs? I don't mean shallow crap like Oblivion, but stuff like Planescape Torment or Baldurs Gate 1 & 2.
Unfortunately, the game art problem allows only FPS games to be done as open source...
The big reason windows wins for gaming isnt that everyone HAS windows. It's that the developers find programming for windows is EASY!
Wrong.
The big reason Windows wins is that developing games for it actually may pay off. Linux is too small for this. Back in the days when the PS2 was No 1, developers wrote games for it, even though its "SDK" was horribly crappy (basically a modified gcc whipped up together with some basic docs).
2.6 vs. 2.4 should be obvious - TONS of new useful features, added drivers... As of 2.6.28, it incorporates GEM, which will be very useful for graphics driver development.