Will they use USB this time? Always wondered why neither Playstation2 nor XBox used USB for the controllers, after all they already have USB on board so why not use it and go proprietary instead? Do they really make any additional money out of this, especially since PC users can't use the gamepads for PC use without buying a converter first? Or is this just to lock out 'unworthy' gamepads in advanced so that users don't plugin their PC gamepads with not enough buttons into the console and then complain?
### And if you install with tar and remove with rm you either have to supply all the dependencies in the tar ball which will cause a lot of duplication and waste of disk space
Diskspace problem could be solved by hard-links. Download would get a bit larger, but not really all that much, especially since with todays system you have to redownload all stuff that depends on a library if it breaks ABI. That said, yes, you might need more than plain tar, but not much more, a pretty thin wrapper could handle everything. And anyway, harddisk are huge, bandwidth gets more and more every day, people however are still the same as last year or the year before, so better waste resources that grow over time and are cheap, instead of wasting valuable human time.
### If you think it's so simple why don't you implement it? If it works well people will adopt it.
It would just end up as yet-another-system, such stuff would need to be happening at LSB level and not as yet another 'package manager'.
### The whole point of using shared libraries is that it makes things like complex GUI environments possible in sensible amounts of RAM.
The hard-linking solution would allow the same, while still keeping stuff seperate from each other.
Beside that I doubt that dynamic linking really helps, it was ment to help, but that doesn't mean it actually does. If I do a "apt-get upgrade" I always need to download a whole damn lot of stuff that due to dependencies need to be downloaded, it does neither contain new feature nor does it fix real bugs, it just happens that dependecies force it to be redownloaded.
Beside that dynamic linking is only an advantage if more than two programms using the same library at the same time, it doesn't help for single-use libraries, there it actually slows things down and consumes more drive space (static linking can throw unused symbols away, dynamic linking can't).
I agree that for Gnome and KDE it might be needed, but the majority of my libraries is not a core KDE or Gnome component but some random one where there is very little chance that I ever use two programms at the same time that will make use of it.
### That doesn't solve the problem of somebody who released a library upgrade thinking it didn't break stuff, but that actually did.
Sure it does, just make sure that libraries get a uniq name and that the packages that uses the library provides them and not a third party that might screw things up at any point.
### So basically you want packages that create and manage themselves?
No, I want a way to install packages so that they don't need to be managed at all. As long as stuff gets installed scattered all across a single directory tree it MUST be managed to allow install/uninstall without excidently overwriting stuff, if you however install everything in a seperate directory that problem basically fades away completly (install with tar, uninstall with rm). Sure will have some other stuff now with library paths and such, but most of them could be workarounded already by extremly simple workarounds like wildcards in the paths definition:
### That's exactly the same thing as having all the shared libraries in the same place, isn't it?
No, it would be all libraries in a different place so that they don't conflict with each other, every. The hardlinking would just be a way to keep the disk usage down, nothing more.
### The first means that if you do get a binary from somewhere, chances are it'll be missing a library it needs. Why?
One can answer this question far easier: Because it didn't statically link the library or because it didn't come with the dynamic libraries it needed. With todays amount of diskspace there is really very little reason to not statically link everything except glibc and some of the X11 libraries.
Its not "learning" its wasting time for most part. Learning is something from which you can draw later on, however most Linux problems are solved by:
* blindly copy&pasting something from a HowTo or Newsgroup
* try&error
* something application or version specific that will be outdated and basically worthless in a few month
* some wrapper tool, which break all the time are incompatible with other wrapper tools and handedited files
Printing is really one example that is a major pain under Linux, it simply never worked for me any good. Sure I can get a piece of paper out of my printer, but half the time it will be misaligned, pure garbage that got stuck in the printers memory or stuff that got incorrectly converted by the 'magic' filters or look simply pretty shitty[1], far away from what the printer actually could do. At work where we have expensive postscript printers I can in general just ftp the files to the printer, bypass all of Linux filters and get a good result in no time.
[1] The last time I had that problem I solved it by converting the ps to pdf via ps2pdf, then loaded it in acroread and converted it back to ps, printing quality improved by like 500%. Have I learned anything by doing that? Well, yep, printing under linux still sucks, but nothing beside that.
apt-get isn't a killer app, its a distribution specfic workaround for a problem that should be fixed upstream. Beside that even apt-get is FAR from perfect, since there are the following problems:
* stable is way behind everybody else, if some piece of software doesn't support your hardware, say XFree86, you are in deep throuble, hardly any newbie will stand this much longer then a few days
* unstable on the other side while being more current can do havoc at any point, beside 'apt-get upgrade' isn't all that fun for modem users, hell even 'apt-get update' is already a serious problem for modem users. testing is still more a game of luck, sometimes it work sometimes it doesn't, nothing that I would give in the hands of a newbie.
* apt-get doesn't fix dependency hell, it just works around it so that dependencies get automatically detected, apt-get however DOES NOT resolve conflicts in a user expected way, if library foo and library bar are incompatible, apt-get will remove everything that depends on the other when I want to install one of them.
* apt-get can't install different versions of -dev packages in most cases since the includes conflict
* apt-get is a one-way thing, it doesn't provide a roll-back. Simple example would be Gnome2, once it got released I took a look at it and it sucked, lots of features removed and stuff didn't work, was there a way to get Gnome1.4 back? No, I was stuck with Gnome2 thanks to apt-get. Sure, I could manually track each and every dependecy and install it in a seperate prefix, but thats nothing that a newbie wants to do.
* apt-get depends extremly on the quality of the repository from which it grabs stuff, unofficial packages often cause throuble and if the maintainers of the repo to something ugly like removing a programm that you depend on, bad luck for you, there is no easy workaround, then to not use apt-get and do everything manually.
A solution to the dependcy hell would be one that is not distrospecific and allows me to download and install any Linux stuff I want from the net, not just the one that some Debian maintainers thought would be worth packaging. It should also allow to install any number of different versions of the same programm without relying on extra work of the maintainer to handle the situation.
Sadly many of the problems are caused by the FHS layout, which is now standardized and thus basically unfixable for a long long time.
'apt-get' is part of the problem, not the solution. Try for example to keep a Gnome1.4 and a Gnome2.x together on a Debian, apt-get doesn't help you here, you would need to compile everything yourself. Same with basically every other programm, you can't keep to different version of it unless the maintainer as specefically prepared the packages to handle this, else you will got a conflict and one programm will get removed as soon as you try to install the other.
A clever filesystem could even remove the diskspace problem by simply hardlinking the dependencies in, instead of copying them. So you only still have the dependency only once, but ever application sees its own pseudo-copy of it.
Re:Thoughts of Python...
on
Dive Into Python
·
· Score: 2, Informative
### Right, and even worse, its inability to encapsulate class-local methods (no data hiding => no OO!).
I don't think that data hiding is all that important for OO, after all it doesn't add any functionality, it just restricts access a little bit and is in languages like C++ even easily workarounded via raw pointers or even more evil '#define private public' hacks. Worse of all, data hiding can make it actually impossible or very ugly to workaround bugs in a library.
Anyway, as far as I know Python does data hiding via '__' prefixes infront of the variable name, should be good enough to tell anybody 'don't touch this' while still allowing access if absolutly necesarry.
Well, you still have the choice between tabs and spaces, so if somebody indents with lots of tabs you are in the same throuble as in any other language too. Python does neither enforce any special naming or such, so people can still write unreadable code if they like, I really don't see how just enforcing idention helps here much, since you still need a common coding style.
### I don't get your point about moving blocks and breaking the code.
Try to move some local helper function up into a higher level, with any non-indention driven language I copy&paste and click 'C-c C-q', job done. With Python on the other side I have to remove the exact right amount of indention, if done manually you have a very good chance of messing stuff up. It gets worse if it comes to web-forums, email and such where indention gets easily broken. With a non-whitespace driven language I can just copy&paste, with Python I have to manually reinsert the indention and if I am unlucky the code doesn't even contain any hints on where a block ended.
Incorrection indention is corrected with almost a single click in any better editor, I really don't see it as a problem unless people are using notepad to write their programms of course.
The problem with pythons whitespace is that it causes quite a bit more problems than it solves in my view. Especially when one refactors function and classes (make a local function a global or visa verse) it is just way to easy to break the code, since once you have broken the indention you have broken the programm and its quite hard to recover from that (no hint left at where the code block ends). That whitespace issue was together with the lack of proper closures the reason why I switched from python to ruby.
One thing I don't get is why isn't there some software out there to verify the proofs? I mean math follows rules and these rules should be convertable into a piece of software, shouldn't they? So why do I always read that somebody might have proofed this and that, yet nobody has yet verified it and often there are even just a few people with enough knowledge to verify the proof at all so it takes quite some time until a proof get verified.
I am not talking about having a computer generate the proof itself, which can be difficult of course, I am just talking about verifing a given proof.
Yes, at the top its one pixel, but on the side it isn't and thats exactly the reason why the resulting ciricle is rather useless for pixel work and quite ugly.
Correct algorithm would be this one, which basically every programm supports, just gimp doesn't:
Oh boy, why do people always start to say "Gimp isn't meant to be this or that" if some feature simply doesn't work or is simply completly flawed?
How about simply fixing the brokeness instead?
Gimp is a image manipulation programm and for that it should be able to do what ever stuff I need to manipulate images, if its broken it needs fixing, not users telling me that I 'do not need the feature'.
If you select '1' as 'Stroke Width' you get a two pixel width circle, not a one pixel width one. Even using a one pixel brush and the pencil tool doesn't give you a one-pixel width circle, but something like a 1.5 width one. Changing the anti-aliasing seetting of the selection doesn't seem to improve things either. Selecting a 'Stroke Width' of '0.5' and enabling antialiasing gives you actually a 50% transparent 2 pixel circle, which is quite far away from an 'optimal' result.
Anyway, nothing of the results that Gimp gives you are much useable when pixel precision matters.
- have brushes or tools in general as plugins
- allow the user to customize the toolbox
Given these two things you couldn't create a PS-lookalike, but it would give at least basic flexibility into the users hand and would allow people to add stuff like linedrawing and such without depending on the good-will of Gimp developers. It wouldn't be much, but it would be a start and really shouldn't be that difficult to create.
About the multiple programms for other regions, its basically all historic, Inkscape is a fork of Sodipodi with a much better interface, OO.org Draw is just the result of StarOffice getting open source, so it got in main parts developed independent of the OpenSource world, Lyx is build on TeX, while the others are not. And well, the rest boils down to Gnome vs. KDE.
Only question left is why there isn't a decent KDE drawing programm, but maybe thats just a matter of time =:)
One last thing, with the GPUs in todays graphics card and the shader support one can do extremly impressive stuff like very large brushes, high-range images, freely zoomable images, effect layers, etc. and everything accelerated in hardware, since I don't think we will see support for them any time soon in the Gimp, my current hope are that something outside of Gimp will emerge that will make use of these features.
No, its not easy, the oposite actually, the way you draw lines and primitves in Gimp simply DOES NOT work. Try this:
- switch brush to "Difference" mode - try to draw a line
The result? Since you need to draw a dot first before you can start drawing a line, you end up with a 'artefact' at the start of the line. A proper line-drawing tool could avoid that.
Similar bugs happen when you try to draw a circle or rect, since information is lost when you stuff is converted to a selection and then stroked its impossible to get clean 1 pixel width circles and outlines, the result will be larger than one pixel and quite a few pixel will be away from where they really should be. A proper tool could again easily avoid this issue.
I am not saying that such tools should replace the current functionality, just that they would be a great addition to it, since the current functionality is both completly unobvious and actually broken for some jobs, while of course being more powerfull for others.
Even as a long time Gimp user (~5 years), with basically no Photoshop and only a little CorelPhotopaint knowledge I have to say that the Gimp interface just sucks. Yes, it gets the job done and it could be worse (think sodipodi;), but there is just so much in it that could be improved. While WiW might not be the solution, having to have at least 5 or 6 windows open even if I am just editing a single image just sucks extremly, docking helps a little bit, but its not a solution, just a little workaround and worst of all there is currently no way do dock stuff to the image window itself, so palett and brush window have to be floating around, annoying.
Speaking about 'working on core functionality', sorry, but I havn't seen much of that happening, they might have rewritten the core of Gimp once or twice, but basically none of that is visible from a users point of view. There is still no macro recorder, you can't resize brushes, you don't have a toolbar for custom buttons, there are no advanced brushes[1], you can't even draw a 1 pixel circle with it, you can create new tools as plug-ins, etc. Sure, some of this might require some work, but simple stuff like drawing primitives is only missing because the developers seem to be extremly hostile to anything that doesn't fit their philosophie (which in most part seems to be based on NIH[2]). Userfriendliness seems to be something that they try to avoid at all cost.
After all one should not forget that the Gimp interface never seems to have been much designed, it just happens to be started that way and never ever touched again.
I just hope that one day there will be an alternative to Gimp, maybe compatible to Gimp plug-ins, so that we could finally get rid of Gimp.
PS: This might be a bit more flaimbait then I really mean, but reading about how people tell how Gimp is all good and fine is just extremly frustrating, since it is cleary not.
The article focused on OpenSource games and game content itself, not on OpenSource use in games, little but extremly important difference.
Sure using Ogg/Vorbis instead of MP3 saves you a few bucks in licensing, thats why Ogg/Vorbis is good for game developers, it however won't have any impact on the license of the game itself, the game will still be closed source as always.
### I do not care if Doom3 is open source or not. I am willing to pay iD for Doom3. I just want a version of the game to run on my Linux box.
You pretty much answer your question yourself with that. Open Source doesn't matter much for the development of the game itself, but it matters a lot for the bugfixing and porting, without OpenSource people either can't do it at all or only with serious additional work. That said companies will of course not go OpenSource since the benefit such as a Linux port are of course extremly limited compared to the losses (no money on licensing the engine, easier cheating,...).
The article is about using Open Source license for the game and its content itself, its not about use of Open Source libraries in commercial game development, which is of course rather clear that it can be usefull there (ie. use ogg for free instead of paying mp3 licensing fees, advantage of OSS is clear there).
Looking back at Shawn Hargreaves Article on Open Source gaming things haven't changed much and probally won't in the near future, since the nature of games is just different from techincal programms that perform a more or less well defined task.
However I think one of the key points to move Open Source gaming further ahead lies in the tools, the engine and the data freely available, once we have reached a point where there is 'enough' of it available, we might see free games poping up. It won't be the hollywood blockbaster games, but it will be little short-stories and stuff which can be done by two or three persons. Some years ago you needed to basically start with a blank sheet of paper and no tools when you wanted to start a game, today we have at least a bunch of tools (Gimp, Blender, Wings3d,...) available for creating content, in the sound area there is still much missing, but we are moving slowly forwards. We also have a bunch of libraries and engines, which while not being up to Doom3 standards, still might be enough for a homebrewn game, that said, with every game that uses them, they will of course also mature a bit more. On the content side however we are still at a very low level, however in large part that might be due to the lack of proper license and to the lack of tools in the past, thing might hopefully change a bit in the future.
Why I think it might work in the long run? Imagine in another five years we might have a repository full of 3d models, textures and sound. Now somebody comes along and wants to create a game, all he has todo is to select a collection of models and textures that will fit his story, point&click them together in some 3d editor and just add his dialogs lines to them. Some ready-to-use 3d engine will do the rest. Sure it won't look commercial quality, especially not like commercial-quality will look in five games. But a game created by such building blocks wouldn't look like it would look today, full of one-color box placeholders, but instead it would be full of well done 3d models. Sure there is still balancing and fixing needed, but those building blocks could reduce the entry level for game creation by quite a bit. It might not work for all games, but it might be still provide a good amount of entertainment. It won't replace commercial game development for sure, but it will be a good addition.
At it stands now however we have still a huge lack of manpower, not just artists, but also programmers who are able to work on a game, since even on the code side of a game, there is some kind of art involved that an average application programmer might not be able to provide. This lack of people is most likly caused by the lack of games on Linux, since those interested in game development are naturally also interested in games.
So if you are an artist or programmer who wants to move Linux gaming forward, stop complaining and do something, join projects which interested you be it games or the content-creation tools, which are at least equally important. If you don't know a project that would be worth joining, join us at the
Game of the Month on Happy Penguin where we pick a game every once in a while and try to polish it, thus joining forces and focusing it on a single project for a short period of time. Don't expect to end up with a Doom3, but your contribution can make a difference and might provide the gamers with another good game.
Slashdot Mirror
Will they use USB this time? Always wondered why neither Playstation2 nor XBox used USB for the controllers, after all they already have USB on board so why not use it and go proprietary instead? Do they really make any additional money out of this, especially since PC users can't use the gamepads for PC use without buying a converter first? Or is this just to lock out 'unworthy' gamepads in advanced so that users don't plugin their PC gamepads with not enough buttons into the console and then complain?
### And if you install with tar and remove with rm you either have to supply all the dependencies in the tar ball which will cause a lot of duplication and waste of disk space
Diskspace problem could be solved by hard-links. Download would get a bit larger, but not really all that much, especially since with todays system you have to redownload all stuff that depends on a library if it breaks ABI. That said, yes, you might need more than plain tar, but not much more, a pretty thin wrapper could handle everything. And anyway, harddisk are huge, bandwidth gets more and more every day, people however are still the same as last year or the year before, so better waste resources that grow over time and are cheap, instead of wasting valuable human time.
### If you think it's so simple why don't you implement it? If it works well people will adopt it.
It would just end up as yet-another-system, such stuff would need to be happening at LSB level and not as yet another 'package manager'.
### The whole point of using shared libraries is that it makes things like complex GUI environments possible in sensible amounts of RAM.
The hard-linking solution would allow the same, while still keeping stuff seperate from each other.
Beside that I doubt that dynamic linking really helps, it was ment to help, but that doesn't mean it actually does. If I do a "apt-get upgrade" I always need to download a whole damn lot of stuff that due to dependencies need to be downloaded, it does neither contain new feature nor does it fix real bugs, it just happens that dependecies force it to be redownloaded.
Beside that dynamic linking is only an advantage if more than two programms using the same library at the same time, it doesn't help for single-use libraries, there it actually slows things down and consumes more drive space (static linking can throw unused symbols away, dynamic linking can't).
I agree that for Gnome and KDE it might be needed, but the majority of my libraries is not a core KDE or Gnome component but some random one where there is very little chance that I ever use two programms at the same time that will make use of it.
### That doesn't solve the problem of somebody who released a library upgrade thinking it didn't break stuff, but that actually did.
Sure it does, just make sure that libraries get a uniq name and that the packages that uses the library provides them and not a third party that might screw things up at any point.
### So basically you want packages that create and manage themselves?
No, I want a way to install packages so that they don't need to be managed at all. As long as stuff gets installed scattered all across a single directory tree it MUST be managed to allow install/uninstall without excidently overwriting stuff, if you however install everything in a seperate directory that problem basically fades away completly (install with tar, uninstall with rm). Sure will have some other stuff now with library paths and such, but most of them could be workarounded already by extremly simple workarounds like wildcards in the paths definition:
LIBRARY_PATH=/Software/*/lib/
or the like.
### That's exactly the same thing as having all the shared libraries in the same place, isn't it?
No, it would be all libraries in a different place so that they don't conflict with each other, every. The hardlinking would just be a way to keep the disk usage down, nothing more.
### The first means that if you do get a binary from somewhere, chances are it'll be missing a library it needs. Why?
One can answer this question far easier: Because it didn't statically link the library or because it didn't come with the dynamic libraries it needed. With todays amount of diskspace there is really very little reason to not statically link everything except glibc and some of the X11 libraries.
Its not "learning" its wasting time for most part. Learning is something from which you can draw later on, however most Linux problems are solved by:
* blindly copy&pasting something from a HowTo or Newsgroup
* try&error
* something application or version specific that will be outdated and basically worthless in a few month
* some wrapper tool, which break all the time are incompatible with other wrapper tools and handedited files
Printing is really one example that is a major pain under Linux, it simply never worked for me any good. Sure I can get a piece of paper out of my printer, but half the time it will be misaligned, pure garbage that got stuck in the printers memory or stuff that got incorrectly converted by the 'magic' filters or look simply pretty shitty[1], far away from what the printer actually could do. At work where we have expensive postscript printers I can in general just ftp the files to the printer, bypass all of Linux filters and get a good result in no time.
[1] The last time I had that problem I solved it by converting the ps to pdf via ps2pdf, then loaded it in acroread and converted it back to ps, printing quality improved by like 500%. Have I learned anything by doing that? Well, yep, printing under linux still sucks, but nothing beside that.
apt-get isn't a killer app, its a distribution specfic workaround for a problem that should be fixed upstream. Beside that even apt-get is FAR from perfect, since there are the following problems:
* stable is way behind everybody else, if some piece of software doesn't support your hardware, say XFree86, you are in deep throuble, hardly any newbie will stand this much longer then a few days
* unstable on the other side while being more current can do havoc at any point, beside 'apt-get upgrade' isn't all that fun for modem users, hell even 'apt-get update' is already a serious problem for modem users. testing is still more a game of luck, sometimes it work sometimes it doesn't, nothing that I would give in the hands of a newbie.
* apt-get doesn't fix dependency hell, it just works around it so that dependencies get automatically detected, apt-get however DOES NOT resolve conflicts in a user expected way, if library foo and library bar are incompatible, apt-get will remove everything that depends on the other when I want to install one of them.
* apt-get can't install different versions of -dev packages in most cases since the includes conflict
* apt-get is a one-way thing, it doesn't provide a roll-back. Simple example would be Gnome2, once it got released I took a look at it and it sucked, lots of features removed and stuff didn't work, was there a way to get Gnome1.4 back? No, I was stuck with Gnome2 thanks to apt-get. Sure, I could manually track each and every dependecy and install it in a seperate prefix, but thats nothing that a newbie wants to do.
* apt-get depends extremly on the quality of the repository from which it grabs stuff, unofficial packages often cause throuble and if the maintainers of the repo to something ugly like removing a programm that you depend on, bad luck for you, there is no easy workaround, then to not use apt-get and do everything manually.
A solution to the dependcy hell would be one that is not distrospecific and allows me to download and install any Linux stuff I want from the net, not just the one that some Debian maintainers thought would be worth packaging. It should also allow to install any number of different versions of the same programm without relying on extra work of the maintainer to handle the situation.
Sadly many of the problems are caused by the FHS layout, which is now standardized and thus basically unfixable for a long long time.
'apt-get' is part of the problem, not the solution. Try for example to keep a Gnome1.4 and a Gnome2.x together on a Debian, apt-get doesn't help you here, you would need to compile everything yourself. Same with basically every other programm, you can't keep to different version of it unless the maintainer as specefically prepared the packages to handle this, else you will got a conflict and one programm will get removed as soon as you try to install the other.
A clever filesystem could even remove the diskspace problem by simply hardlinking the dependencies in, instead of copying them. So you only still have the dependency only once, but ever application sees its own pseudo-copy of it.
### Right, and even worse, its inability to encapsulate class-local methods (no data hiding => no OO!).
I don't think that data hiding is all that important for OO, after all it doesn't add any functionality, it just restricts access a little bit and is in languages like C++ even easily workarounded via raw pointers or even more evil '#define private public' hacks. Worse of all, data hiding can make it actually impossible or very ugly to workaround bugs in a library.
Anyway, as far as I know Python does data hiding via '__' prefixes infront of the variable name, should be good enough to tell anybody 'don't touch this' while still allowing access if absolutly necesarry.
### With python it's not an issue.
Well, you still have the choice between tabs and spaces, so if somebody indents with lots of tabs you are in the same throuble as in any other language too. Python does neither enforce any special naming or such, so people can still write unreadable code if they like, I really don't see how just enforcing idention helps here much, since you still need a common coding style.
### I don't get your point about moving blocks and breaking the code.
Try to move some local helper function up into a higher level, with any non-indention driven language I copy&paste and click 'C-c C-q', job done. With Python on the other side I have to remove the exact right amount of indention, if done manually you have a very good chance of messing stuff up. It gets worse if it comes to web-forums, email and such where indention gets easily broken. With a non-whitespace driven language I can just copy&paste, with Python I have to manually reinsert the indention and if I am unlucky the code doesn't even contain any hints on where a block ended.
Incorrection indention is corrected with almost a single click in any better editor, I really don't see it as a problem unless people are using notepad to write their programms of course.
The problem with pythons whitespace is that it causes quite a bit more problems than it solves in my view. Especially when one refactors function and classes (make a local function a global or visa verse) it is just way to easy to break the code, since once you have broken the indention you have broken the programm and its quite hard to recover from that (no hint left at where the code block ends). That whitespace issue was together with the lack of proper closures the reason why I switched from python to ruby.
One thing I don't get is why isn't there some software out there to verify the proofs? I mean math follows rules and these rules should be convertable into a piece of software, shouldn't they? So why do I always read that somebody might have proofed this and that, yet nobody has yet verified it and often there are even just a few people with enough knowledge to verify the proof at all so it takes quite some time until a proof get verified.
I am not talking about having a computer generate the proof itself, which can be difficult of course, I am just talking about verifing a given proof.
Yes, at the top its one pixel, but on the side it isn't and thats exactly the reason why the resulting ciricle is rather useless for pixel work and quite ugly.
l e7 67.asp
Correct algorithm would be this one, which basically every programm supports, just gimp doesn't:
http://www.gamedev.net/reference/articles/artic
Oh boy, why do people always start to say "Gimp isn't meant to be this or that" if some feature simply doesn't work or is simply completly flawed?
How about simply fixing the brokeness instead?
Gimp is a image manipulation programm and for that it should be able to do what ever stuff I need to manipulate images, if its broken it needs fixing, not users telling me that I 'do not need the feature'.
http://pingus.seul.org/~grumbel/tmp/gimp-onepixelb ug.png
The right image is what I want, the left images show what Gimp gives you (stroke with width 1 and stroke with pencil tool and one-pixel brush).
If you select '1' as 'Stroke Width' you get a two pixel width circle, not a one pixel width one. Even using a one pixel brush and the pencil tool doesn't give you a one-pixel width circle, but something like a 1.5 width one. Changing the anti-aliasing seetting of the selection doesn't seem to improve things either. Selecting a 'Stroke Width' of '0.5' and enabling antialiasing gives you actually a 50% transparent 2 pixel circle, which is quite far away from an 'optimal' result.
Anyway, nothing of the results that Gimp gives you are much useable when pixel precision matters.
My wishlist would be:
- have brushes or tools in general as plugins
- allow the user to customize the toolbox
Given these two things you couldn't create a PS-lookalike, but it would give at least basic flexibility into the users hand and would allow people to add stuff like linedrawing and such without depending on the good-will of Gimp developers. It wouldn't be much, but it would be a start and really shouldn't be that difficult to create.
About the multiple programms for other regions, its basically all historic, Inkscape is a fork of Sodipodi with a much better interface, OO.org Draw is just the result of StarOffice getting open source, so it got in main parts developed independent of the OpenSource world, Lyx is build on TeX, while the others are not. And well, the rest boils down to Gnome vs. KDE.
Only question left is why there isn't a decent KDE drawing programm, but maybe thats just a matter of time =:)
One last thing, with the GPUs in todays graphics card and the shader support one can do extremly impressive stuff like very large brushes, high-range images, freely zoomable images, effect layers, etc. and everything accelerated in hardware, since I don't think we will see support for them any time soon in the Gimp, my current hope are that something outside of Gimp will emerge that will make use of these features.
No, its not easy, the oposite actually, the way you draw lines and primitves in Gimp simply DOES NOT work. Try this:
- switch brush to "Difference" mode
- try to draw a line
The result? Since you need to draw a dot first before you can start drawing a line, you end up with a 'artefact' at the start of the line. A proper line-drawing tool could avoid that.
Similar bugs happen when you try to draw a circle or rect, since information is lost when you stuff is converted to a selection and then stroked its impossible to get clean 1 pixel width circles and outlines, the result will be larger than one pixel and quite a few pixel will be away from where they really should be. A proper tool could again easily avoid this issue.
I am not saying that such tools should replace the current functionality, just that they would be a great addition to it, since the current functionality is both completly unobvious and actually broken for some jobs, while of course being more powerfull for others.
Even as a long time Gimp user (~5 years), with basically no Photoshop and only a little CorelPhotopaint knowledge I have to say that the Gimp interface just sucks. Yes, it gets the job done and it could be worse (think sodipodi ;), but there is just so much in it that could be improved. While WiW might not be the solution, having to have at least 5 or 6 windows open even if I am just editing a single image just sucks extremly, docking helps a little bit, but its not a solution, just a little workaround and worst of all there is currently no way do dock stuff to the image window itself, so palett and brush window have to be floating around, annoying.
Speaking about 'working on core functionality', sorry, but I havn't seen much of that happening, they might have rewritten the core of Gimp once or twice, but basically none of that is visible from a users point of view. There is still no macro recorder, you can't resize brushes, you don't have a toolbar for custom buttons, there are no advanced brushes[1], you can't even draw a 1 pixel circle with it, you can create new tools as plug-ins, etc. Sure, some of this might require some work, but simple stuff like drawing primitives is only missing because the developers seem to be extremly hostile to anything that doesn't fit their philosophie (which in most part seems to be based on NIH[2]). Userfriendliness seems to be something that they try to avoid at all cost.
After all one should not forget that the Gimp interface never seems to have been much designed, it just happens to be started that way and never ever touched again.
I just hope that one day there will be an alternative to Gimp, maybe compatible to Gimp plug-ins, so that we could finally get rid of Gimp.
[1] http://www.levien.com/gimp/wetdream.html
[2] http://en.wikipedia.org/wiki/Not_Invented_Here
PS: This might be a bit more flaimbait then I really mean, but reading about how people tell how Gimp is all good and fine is just extremly frustrating, since it is cleary not.
The article focused on OpenSource games and game content itself, not on OpenSource use in games, little but extremly important difference.
Sure using Ogg/Vorbis instead of MP3 saves you a few bucks in licensing, thats why Ogg/Vorbis is good for game developers, it however won't have any impact on the license of the game itself, the game will still be closed source as always.
### I do not care if Doom3 is open source or not. I am willing to pay iD for Doom3. I just want a version of the game to run on my Linux box.
...).
You pretty much answer your question yourself with that. Open Source doesn't matter much for the development of the game itself, but it matters a lot for the bugfixing and porting, without OpenSource people either can't do it at all or only with serious additional work. That said companies will of course not go OpenSource since the benefit such as a Linux port are of course extremly limited compared to the losses (no money on licensing the engine, easier cheating,
The article is about using Open Source license for the game and its content itself, its not about use of Open Source libraries in commercial game development, which is of course rather clear that it can be usefull there (ie. use ogg for free instead of paying mp3 licensing fees, advantage of OSS is clear there).
Game of the Month Link got messed up, correct one is: http://happypenguin.org/forums/viewforum.php?f=21
However I think one of the key points to move Open Source gaming further ahead lies in the tools, the engine and the data freely available, once we have reached a point where there is 'enough' of it available, we might see free games poping up. It won't be the hollywood blockbaster games, but it will be little short-stories and stuff which can be done by two or three persons. Some years ago you needed to basically start with a blank sheet of paper and no tools when you wanted to start a game, today we have at least a bunch of tools (Gimp, Blender, Wings3d, ...) available for creating content, in the sound area there is still much missing, but we are moving slowly forwards. We also have a bunch of libraries and engines, which while not being up to Doom3 standards, still might be enough for a homebrewn game, that said, with every game that uses them, they will of course also mature a bit more. On the content side however we are still at a very low level, however in large part that might be due to the lack of proper license and to the lack of tools in the past, thing might hopefully change a bit in the future.
Why I think it might work in the long run? Imagine in another five years we might have a repository full of 3d models, textures and sound. Now somebody comes along and wants to create a game, all he has todo is to select a collection of models and textures that will fit his story, point&click them together in some 3d editor and just add his dialogs lines to them. Some ready-to-use 3d engine will do the rest. Sure it won't look commercial quality, especially not like commercial-quality will look in five games. But a game created by such building blocks wouldn't look like it would look today, full of one-color box placeholders, but instead it would be full of well done 3d models. Sure there is still balancing and fixing needed, but those building blocks could reduce the entry level for game creation by quite a bit. It might not work for all games, but it might be still provide a good amount of entertainment. It won't replace commercial game development for sure, but it will be a good addition.
At it stands now however we have still a huge lack of manpower, not just artists, but also programmers who are able to work on a game, since even on the code side of a game, there is some kind of art involved that an average application programmer might not be able to provide. This lack of people is most likly caused by the lack of games on Linux, since those interested in game development are naturally also interested in games.
So if you are an artist or programmer who wants to move Linux gaming forward, stop complaining and do something, join projects which interested you be it games or the content-creation tools, which are at least equally important. If you don't know a project that would be worth joining, join us at the Game of the Month on Happy Penguin where we pick a game every once in a while and try to polish it, thus joining forces and focusing it on a single project for a short period of time. Don't expect to end up with a Doom3, but your contribution can make a difference and might provide the gamers with another good game.