On Wed, Jul 30, 2008 at 2:07 PM, Hugo Arts
<hugo.yoshi@xxxxxxxxx> wrote:
I agree that this is not a basic function but I don't see it as being less basic than
pygame.transform.laplacian -
find edges in a surface.
True. But I'm not sure laplacian belongs in the package either. Then again, maybe I suffer from feature creep paranoia. It's too early to say anything about the frequency of its use.
Feature creep is only a problem IMOHO if the api sucks and or the docs suck. For example compare Crystal Space to Panda3d. Both are strong 3d engines, both are open source, both have a python API but CS is really hard to understand and the docs suck. I played with it for 2 months and never did anything useful with it, everything had errors too. Othe other hand Panda3d is really great! It has great docs and an great API. The only other problem I can see is if the programmers get spead to thin to keep up the code base and the code has poor docs. Perhaps there is something to be said for keeping the lib small too. KISS
Perlin noise has a LOT of uses with game writing: surfaces, shapes, and movement can
all be made better using it.
I have never seen any pygame projects using Perlin noise before, but that could also be a chicken/egg thing. I still think its not basic functionality. There's no GUI into the core for the same reason. quoting the about page: "the core is kept simple, and extra things like GUI
libraries, and effects are developed separately outside of pygame."
I would argue that Perlin is a simple function and in no way comes close to the complexity of a GUI. That said, I have always wished that Pygame had a gui that was as good as the rest of it. I have found all the GUI's that I have tried that are refrenced on the web site to be lacking (I did this a few years ago, I am sure they have improved).
As for people not using it, I am sure that is because they don't understand it well or how it could be useful. A good doc with some examples would go a long way towards changing that.
Of course, by all means develop a separate library outside of pygame.
I think that's a Great Idea(tm), and people that want the functionality can easily download it.
Perhaps it could be integrated into the core later if there is enough interest.
I will think about that, I have never made a python addition before and my C is a bit weak. I was thinking that adding a simple and useful funtion to the pygame code might be a good way to learn about it.
I have not checked out that Caseman lib in full but from what I see it only has 3d perlin and not other dimensions and I don't know how fast it is.
I also agree that we could make a whole section of code like this. There are other types of noise, a lot of vector math toys like unit vector and perpendicular vector etc that get used a lot in game making. I am sure there are more that could be rounded up for a nice set of functions. Then there are even really big ones like AI functions that could be written (I keep thinking that a Prolog lib for python would be great for making games!) but then that is in the same class as a gui or 3d etc.
Vector/AI aren't really in the same functionality type as noise functions. Besides, there are already 2d and 3d vectors in the cookboock section. But you could bundle it up into a nice noise/procedural generation library.