Re: [pygame] Python and Speed
Learn to write C. The best software is written as a hybrid of multiple technologies, each serving a different purpose. Python's strengths are rapid development and succint, easy to read code. C's strengths are flexibility and machine optimization. MMX and SSE assembly code are for maximum performance in core mathematical routines. Bruce Lee said that a true practitioner must be like the water - able to adapt to any attacker's style and defend in the most effective manner. Since Python will never be as fast as C, you must learn C in order to become a better programmer. Don't expect anyone to change the laws of the universe for you. Richard Ian Mallett wrote: -I think it has been thoroughly established that Python cannot be as fast as C. -As far as algorithms go, intelligence is better, but I hold by using vastly simpler ones to speed development. Someone just mentioned sorting methods. In that case, obviously, a little extra coding doesn't hurt, but changing your game's architecture each time an largish optional feature is added is a bad idea. -I also still hold by wanting Python to be faster. I don't care if it is impossible; I still want it to be. I'm not going to give up on Python's great niceness just for a want of some speed. Ian
Re: [pygame] award winning pygames.
This is a really bizarre thread. It seems like you're discussing the wrong thing here. Let's talk about what really matters: 1. What makes a game FUN? It is enjoyable to play and captures your attention. 2. What are some recent award-winning commercial games? Halo 3, Portal, Super Mario Galaxy, BioShock, Gran Turismo. 2a. Can these games be made in Pygame? Hell no. Here's a fact: making a modern, commercial (somebody would shell out their $$) game takes hundreds of thousands, if not MILLIONS of dollars. Nobody playing around in their spare time can do it. So what about 10, 15, 20 years ago? People shelled out lots of $$ for Carnival, Smurf Rescue, Asteroids, Super Cobra, Super Mario Brothers, Contra, Metroid, and others. These games are nowhere near as complex as modern games, but they were still FUN. And you can make much better games than these with Pygame. And it takes less development time. People are focused on the wrong things. Go check out my Invasion 3D game: http://www.fascinationsoftware.com/FS/html/Invasion3D.html I did it in a couple of months (not with Pygame though). It's a heck of a lot of fun to play. But not many people would pay for it. Why? Because there's a lot of awesome stuff that you can get for free these days. That was not true 15 years ago. If you want to make $$ writing games, you need to get hired by a company. If you want to make some really fun games and get the pleasure of receiving compliments about a creation that was almost entirely your own, make a game with Pygame. Richard Talat Fakhri, Mathematician, MindValley.
Re: [pygame] award winning pygames.
Dave LeCompte (really) wrote: People have used Python in commercial games, but as a rule, the applications of Python are for game scripting, not access to the graphics, audio, or input subsystems. I have a friend at work who's pretty serious about a few MMORPGs. He has a bunch of kids and they all play Toon Town, and he told me this game itself was written in Python. That's pretty impressive. I've been writing C and assembly code for more than 15 years, and I'm amazed at how quickly you can crank out really sophisticated software with Python. As long as it meets your speed requirements, you can do the development much faster in Python every time. Richard
Re: [pygame] AGG library
Brian Fisher wrote: My own poor choice of phrasing notwithstanding, Maxim has put his time and energy into getting the capabilities of AGG's drawing and transformation code to places that achieve a lot more than SDL_gfx and pygame.draw transform have achieved. Since he shares his work so generously, I think it would be great for pygame and/or SDL_gfx to use his work to reach that level without having to do all the work he did. Ahh, but you're going to have to fight a C/C++ war to make that happen. Good luck with that. :) I've seen this happen several times in my professional work. In the end, it comes down to where the people really driving the project want to go with it. If the pygame authors really want the advanced functionality of AGG then they'll find a way to make it work. If they decide it's too complex and to extend their own software libraries instead, then it'll go that way. But since it's open source, anyone can make a go for it. If it's easy to cobble the pieces together and make some impressive demos with aggdraw+numpy+pygame then someone who believes in it should just do it and show everyone how cool it could be. Maybe it wouldn't require major changes to pygame.
Re: [pygame] MMX Transform for Win32
Are there other people interested in adding this kind of function to the pygame library? If there is significant interest in a 'warping' function like this, I can take the time to code it up. But be warned that it will be quite a bit slower than a pure scaling function. Richard Ian Mallett wrote: On Sat, Mar 8, 2008 at 8:03 PM, Richard Goedeken [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Regarding your previous message, I presume you are referring to transforming a rectangular pixel map into an arbitrary quadrilateral? Yes.
Re: [pygame] MMX Transform for Win32
Lenard Lindstrom wrote: Giving this more thought it is too late in the Pygame release cycle to add an Intel translation of the assembly code to Pygame 1.8.0. This would lead to four versions of each of four subroutines. The resulting conditional expressions will be ungainly. Also the Intel translations will need properly tested. The ATT assembly code has been out for awhile and shows no problems. For the moment a MinGW compiled transform.pyd can be used in the Windows binaries for Pygame 1.8.0. But it is desirable to translate the ATT assembly code to Intel at some point in the future. If the gcc x86 C compiler truly handle VC style inlined assembly, including C identifiers within assembly code, then the ATT code can be entirely replaced. Otherwise separate ATT and Intel versions will need to be maintained. It has also been discussed to reintroduce the original SSE versions of the routines. But this will involve a rethink on how MMX/SSE support is provided. A good portion of the work that I do in my day job involves writing MMX/SSE2 code, most of which needs to run in both Win32 and Linux, and on both 64-bit and 32-bit systems. So I deal with this problem a lot. To my knowledge, there is no effort to add an Intel-style inline assembly capability to GCC. If someone knows of such an effort then I would be very interested to learn about it. I agree that writing, testing, and supporting 2 or 3 implementations of the same routine with #ifdefs really sucks. The other way I deal with this problem at work is to use an external assembler such as NASM. This can be made to work under both Linux and Win32 with the same assembly source code quite easily. The disadvantage with this approach is that it introduces another tool dependency. Richard
[pygame] New transformations for future Pygame releases
Brian Fisher wrote: If were going to have something like that (a warping function) in PyGame, I would definitely want it to use anti-grain-geometry (http://antigrain.com ) rather than use a newly coded up function. AGG has been around for a very long time, is highly tested, and once you code up the basic integration issues a huge world of completely awesome 2d software rendering falls out fairly easily (gaussian blur, vector shape rendering, textured lines, etc. etc.) I was previously unaware of this project; thanks for the link. It looks quite impressive. It appears that AGG does not have a function to do what Ian was asking for though - transforming a rectangle to an arbitrary quadrilateral. What it can do, though, is transform a rectange to an arbitrary parallelogram. Does anyone else on the list have any requests for any image transformations that they would like? Something that would give their games some more flash or polish? Richard
[pygame] ASM code in pygame
Lenard Lindstrom wrote: Deciding how to handle assembly code in future Pygame releases will probably take up its own mailing list thread. But when I do a Google search on the topic of Intel assembly code and gcc I get this, http://www.acm.uiuc.edu/sigmil/RevEng/ch02.html , which claims the GNU assembler 'as' takes input as an ATT or Intel syntax asm file. Pygame's assembly routines will likely end up in there own libraries and be linked in, possibly dynamically, as needed. So gcc C will no longer be a factor for assembly language compatibility. GUN 'as' may take intel-style code, but I'm pretty sure that the compiler (GCC) will only accept the ATT style. The back end of the compiler needs to know the input/output registers, and if that information is not explicitly given in the extended-asm syntax, then the compiler must parse the ASM and extract the information by itself. This is what VC does, but I think GCC probably doesn't have support for this. If you're considering keeping separate libraries for the ASM code then I think breaking the code out into .asm files and assembling it with NASM/YASM is the right way to go. Richard
Re: [pygame] MMX Transform for Win32
Ian Mallett wrote: On Sun, Mar 9, 2008 at 9:22 AM, Richard Goedeken [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: But be warned that it will be quite a bit slower than a pure scaling function. Why? 3D engines like OpenGL can do this operation for thousands of quads each frame while maintaining a great framerate. Doing it for one quad shouldn't be too hard. Because I wrote vector assembly code in MMX to accelerate the smooth scaling function, plus I used some algorithmic simplifications. But this warping operation requires rasterization, which is a more complicated algorithm, and I was only planning to write it in C. The execution time would be proportional to the size of the transformed quad, so for a few small quads it would be fast. But scalar C code can't get close to the performance of hand-written vector code running on dedicated hardware (GPUs); not even MMX code can get close. Richard
Re: [pygame] ASM code in pygame
Hey, that's great! Are you sure that this switch allows one to write inline asm in Intel format? The man page says: -masm=dialect Output asm instructions using selected dialect. Supported choices are intel or att (the default one). Darwin does not support intel. I'll give a try some time. Richard René Dudfield wrote: hello, for your info... gcc supports intel syntax with a command line option. -masm=intel SDL uses macros for portable asm, I think.
Re: [pygame] ASM code in pygame
Yeah I was afraid of something like that. The constraints are the killer. It's really not that big of deal to translate ATT--Intel inline code; I've done lots of it. I can do the translation for the next release. Richard Lenard Lindstrom wrote: When you offered to write Intel versions of the ATT code I looked for a way to automate some of the translation process. So I tried using the -masm=intel and -S compiler options to translate the inline assembly code and write it to an .s file. The inlined instructions were simply copied. So it is unlikely gcc can handle VC like __asm statements, where the compiler definitely needs to understand assembly code. The MSDN does say the VC compiler has a built in assembler. gcc compilers only generates assembly output for the next stage in the compilation process. So I tried compiling a simple assembly code example in MSDN which calls printf, and gcc C did not recognize the __asm keyword. Finally, I just found a mingw-users thread* where Thomas Heller of ctypes fame was looking for a inline assembly formated recognized by both gcc and VC. No luck. The advice was to use assembly files and a free assembler like NASM or as. Not helpful when distutils doe not directly support assembler files. This is not promising. Lenard
[pygame] MMX Transform for Win32
VC is not clever enough to vectorize the C code and emit MMX instructions. :) If no-one else volunteers, I can translate the code to intel-style inline ASM. It might take a week or two to get it done, though. Richard On Mon, Mar 3, 2008 at 1:16 PM, Lenard Lindstrom [EMAIL PROTECTED] Slightly off topic, but one thing I remembered is that the MMX scaling code Richard Goedeken so generously donated in not used in Visual C builds. The MMX code is in ATT form, not used by masm. So the options are to add an masm translation of the code to transform.c or just use the MinGW compiled transform.pyd. Of course VC may be clever enough to do its own MMX optimization.
Re: [pygame] MMX Transform for Win32
The code is in src/transform.c in the pygame tree. The task at hand is to translate the 32-bit MMX code (I think there's 4 sections of code, each about 40-60 lines) from the ATT syntax used by GCC to the Intel style used by VC. The Intel format is compatible with masm, nasm, yasm, etc. It's pretty easy to read. The ATT style is quite powerful but very strange looking, and if you don't have an inclination to learn a bit about it then the translation would be very hard. Take a look at it and let me know if you want to take a crack at it. I could always proof-read it. Richard Jason Ward wrote: what is this MMX discussion about and the transform function? If this is to do with pygame source I may be interested. but not to solely do it, just to give a rather small helping hand. I know intel asm but I haven't really gotten into MMX so this would be a great opportunity for me to get into it. So I might be able to help you do it Richard. Just direct me in exactly what it is :)
Re: [pygame] MMX Transform for Win32
Marcus von Appen wrote: The code first needs to be brought into shape (there are some minor issues, if I remember correctly) and be sync'ed with the latest changes in SDL_gfx. At least the parts taken from it. Regards Marcus I added a new function to the transform module called 'smoothscale'; it's all computed in software and doesn't use anything from SDL_gfx. Do you have a list of the problems encountered with this function? Richard
Re: [pygame] MMX Transform for Win32
The pygame.transform.smoothscale.__doc__ gives the usage information. It scales an image smoothly (and quickly, with the MMX code) using a bilinear filter for upsampling and a novel area-based filter for downscaling which minimizes moire patterns on highly downscaled images. Each axis can be scaled independently (ie, there's no requirement to keep the same aspect ratio). My goals in writing this routine were to achieve high image quality and high speed. Regarding your previous message, I presume you are referring to transforming a rectangular pixel map into an arbitrary quadrilateral? It would be easy enough to write a C function to do this but it would be slow. Writing accelerated (MMX) code for this type of routine would be time-consuming, and it wouldn't achieve the same level of speedup that I got with the smoothscale function. Richard Ian Mallett wrote: Thanks. How can one use this with Python?
Re: [pygame] space ships (Re: Misnamed threads (Re: Posting styles (Re: Text To Speech PYTTS)))
All space vehicles use staging; the space shuttle's are just on the side. NASA also made the Saturn 5, don't forget. The space shuttle is a poor investment but an incredibly high-performance vehicle and launch system. It can lift almost as much as the Saturn 5 (including the orbiter) -- way more than any Russian vehicle. :) Richard Ian Mallett wrote: hmmm. I would not define the space shuttle as a space ship because it requires an external fuel tank and two extra rockets to get into space. In fact, all of NASA's creations, then have not been rockets because they cannot travel to and from space without incredible difficulty and sacrifice of parts.
Re: [pygame] [BUG] SRCALPHA - unexpected behaviour.
Actually, according to Wikipedia, every AMD chip since and including the original Athlon (everything after the K6) has included the MMX extensions from SSE. On the Intel side, everything since and including the P3 has SSE. Having said that, if you want to support vanilla MMX, another option is to just remove my original 'SSE/MMX' instructions, keep Mr Lindstrom's changes, and get rid of the extra config parameter. The extra makefile complexity might not be worth it, as his changes will only hurt performance on modern CPUs by a few percent. These filtering-type routines are usually highly memory-bound in performance. Richard René Dudfield wrote: yeah, sse is not everywhere yet. There are a lot of AMD chips out there without it. So I think we should leave the SSE off unless detected. cheers, On 8/23/07, Lenard Lindstrom [EMAIL PROTECTED] wrote: Glad to here about the MMX. My SSE patch requires SSE support to be explicitly turned off with a NO_SSE flag. But this is at odds with other libraries where MMX/SSE support must be turned on: SDL has MMX_ASMBLIT/SSE_ASMBLIT, smpeg has USE_MMX. These could be hold-overs from earlier days when MMX/SSE support was less common. It is probably now safe to assume MMX is available. I am less sure about SSE, thought the majority of i386 computers in use today likely support it. René Dudfield wrote: that's all I got around to doing today... I'll apply the other patches later (the mmx fixes, and the fromstring() stuff.) Cheers, On 8/22/07, Lenard Lindstrom [EMAIL PROTECTED] wrote: 24 bit surfaces do work when the flags are 0. It was the SRCALPHA flag that caused problems, whether pygame was initialized or not. It was just that when the surface depth was set to 24 bits implicitly, then the SRCALPHA flag was ignored. If explicitly then the SRCALPHA flag was processed and pygame segfaulted. René Dudfield wrote: ah, I fixed those segfaults in svn. There were problems with get_bytesize, and get_alpha too. I'm not sure why using a bitdepth of 24 doesn't work without initializing pygame... So that can still be considered a bug that needs investigation.
Re: [pygame] pygame- Installing pygame on suse linux from source
Jason, In order to make python scripts executable, put a line like this at the top of the file: #!/usr/bin/env python You can also call it directly, like this: #!/usr/bin/python For your sdl-dev problem, run 'sdl-config --cflags' from the command line. There should be an option printed which says '-I/usr/include/SDL' though the path may be slightly different. Try to see if the header file is there by doing an 'ls -l /usr/include/SDL/SDL.h' (substituting the path returned in the previous command if it was different). If either of these steps don't work, that means that your sdl-dev package is not installed. Richard Jason Ward wrote: Hi I downloaded pygame source and I've been trying to install it on my suse 10.2 linux. It says I need sdl-dev when I run setup.py from the console with the command, python setup.py install So I downloaded, the source of sdl and the src.rpm and the dev rpm and the runtime. But with any or all of these installed I still get the error message. You should put a link on the site for the required sdl files. PS. How do I make python scripts executable on linux? (My first time using linux) How do I get it so that I can open with IDLE? running scripts from console is a mission Thanks guys
Re: [pygame] [PATCH] Smooth Scaling v3
I'm glad to hear that you got the new scaling function in there. I'm not sure exactly how to fix the compiler warnings either. There are no truly unused variables - everything that could be #ifdef'd has been. It's just that GCC doesn't recognize that the values are being used in the ASM code. For the 64-bit long long constants it may be possible to get rid of that warning by appending LL to the constant itself - I believe that will make it stop complaining about that. Richard René Dudfield wrote: Hi, added the cool new smoothscale function from Richard Goedeken. I really like how nice it looks :) There's an example in examples/scaletest.py that you can play with to see it working. Committed revision 1025. I changed it for pygame subversion, as well as made it use an optional destination surface argument like the other scale functions now do. As well as releasing the GIL during processing for multiple threads like the scale functions do in subversion pygame. Also the documentation is moved into transform.doc like is done now for C functions. There's still a couple of compiler warnings about unused variables. As well as constants being too big for a long. But I'm not so sure of the code yet to fix them. Maybe it's a 64bit specific thing that can be #ifdef'd ? There's a basic unittest for it in tests/test_transform.py but it could use a few more tests. (also strangely every time I try to paste the exact compiler errors into gmail, it crashes both my terminal and firefox... weird) On 6/26/07, Richard Goedeken [EMAIL PROTECTED] wrote: Okay, this is the final version of the SmoothScale patch. I built the last one on an Ubuntu/x86_64 laptop and it crashed. I traced the problem to my input/output register handling with the crazy ATT syntax and figured out the proper way to tell the compiler what registers I have changed. The attached code works on all 3 platforms and I believe the syntax is correct now. Richard
Re: [pygame] pygame source compiling
An ambitious Windows dev could set up a SVN server to store the binary dependencies and grab the source from the seul.org server. All you have to do is set the svn:externals property on a folder of your project, to link in as a subdirectory any path from any other server. I can give someone the exact command-line syntax to do the job if wanted; I manage an SVN repository for a big project at work. Richard Michael George wrote: I think subversion has a mechanism for referencing the contents of another subversion repository, which might make this type of solution easier. I agree though, that I don't want multiple versions of everything being installed by pygame - that's what my package manager is for, and subverting it can only lead to suffering. But for you windows folk... --Mike James Paige wrote: On Wed, Jul 11, 2007 at 03:45:23PM -0700, Brian Fisher wrote: --- If you see something I am not understanding, or something I don't know about the linux way to do things that makes checked in dependencies a problem, please correct me. The whole idea of including dependencies is a *terrible* idea for linux, and for any OS with package management -- but it sounds like a *great* idea for windows. May I suggest: don't put any dependencies in the pygame subversion repository. Instead, make a separate parallel subversion repository that contains an automatically updated mirror of the main svn repository along with all dependency sources. That gives us the best of both worlds, without meddling with the existing subversion repository at all. Not only that, it can function independently and be maintained by the people who want it, without putting any extra burden on the core pygame developers. --- James Paige
Re: [pygame] multicpu machine for testing some pygame code?
Rene, I have a dual core machine at home, and 4-way and 8-way machines at work. I can get and build the SVN trunk; just email me the code or instructions. Richard René Dudfield wrote: Hello, if someone has a multicore, or multi cpu system... can you please test some code for me? I'm trying to get some code into pygame to make it work better for multicore machines... but I need to test it some more. You'll need to be able to compile subversion pygame. Cheers,
Re: [PATCH] Re: [pygame] Smooth Scaling (pygame.transform.smoothscale)
That's a good plan, but I haven't been able to find a good way to determine at compile time whether or not the compiler supports MMX. You could always dump out a small test file and compile it to test for errors, but I was hoping to find something better like running gcc with a magical parameter or testing for a magical preproc definition. Are you aware of any 'cleaner' ways of handling this detection? Richard René Dudfield wrote: Hi, that's good :) SDL does it by compiling the mmx stuff in if the compiler supports it. Then it has runtime checks to see if the cpu supports it. SDL also has a configure flag, which you can use to tell it not to even try compiling mmx stuff. So if the compiler doesn't support it, the C version is used. If the compiler supports it, and the runtime cpu detection finds mmx, then the mmx version is used. On 6/20/07, Richard Goedeken [EMAIL PROTECTED] wrote: Rene, I would be willing to add the CPU detection functions but I can't think of how it could be implemented in a useful way. The compile-time checks have to stay in because trying to compile the 64-bit code on a 32-bit architecture, or the 32-bit MMX code on a PPC or similar, will cause compile-time errors. So it's given that if someone is running an i386, PPC, Sun, Arm, etc, they will get the C code. If they're running i686, they'll get the 32-bit MMX, and for x86_64 they'll get the 64-bit MMX. So, the dilemma is that whatever build a user is running, the code is pretty much guaranteed to work on their CPU. If someone is running the i686 build on a 486 or something silly like that they'll probably have bigger problems. We could allow someone to 'downgrade' and run the C code when their CPU supports MMX, but what's the point? Regards, Richard
