running pygame

[apomb]

I have installed pygame and System Python 2.5.4 and everything nicely, but how am i to run pygame?

[DtY]

you import pygame in a python program.

A basic program that just opens a window looks like:

Python:

import pygame pygame.init() scr = pygame.display.set_mode((width, height), option1|option2|..optionN) #scr is now a reference to the screen, and can have stuff drawn to it. The first argument is a double of (width, height), the second argument is a bitmask of display options like for hardware acceleration, fullscreen, etc. while True: #Main loop     pass

(Use control+C on shell to quit it. You can make the program react to the close button being pressed as well).

[apomb]

alright, so running a game written with pygame all i get are two windows that look like so:

[DtY]

The one on the left is the code window. The right is the python console, but that's not what you want. Anything you enter in there will be evaluated and give you the result. It's for testing stuff.

So are you just trying to run the program? You're not learning how to program with python?

If that's the case, you'll need to make the program executable. Make the first line in that file #!/usr/bin/python (That's a python comment, so it wont be run by the interpreter) That line tells the system how to execute that file. Close those windows, and go to the directory where the file are. You need to mark them executable, I have no idea how to do this on a Mac, google, I guess. (If you know how to use the command line, you can use the command chmod +x (filename)). The icon should change to a terminal. When you double click on it, it should run properly.

[apomb]

This is odd. I've made things executable before on my mac, but it seems like this doesnt want to work.

[DtY]

The path to python might be different on a mac, I haven't used one intensively before. Try running which python to find out where it's installed.

Or, you can start it from the command line with python (script)

[apomb]

i went to /usr/bin and python is there, but when i run potal.py it gives me "no such path "/usr/bin/python^M"

[DtY]

Ohhh, windows line endings.

Unix text files end lines with \n, windows however insists on \r\n. Now, this is rarely an issue, as I've only ever come across two programs that have an issue with this, (1) Notepad on windows, (2) Bash shell (and I assume most linux shells). Every other program will work with either correctly. So, the shell is looking for an executable called "/usr/bin/python\r".

Since it's just one line of code, make a new text file, add #!/usr/bin/python, then overwrite that original start file with it. There may also be a command line tool to fix line endings (or your text editor may do it), but I'm not sure.
You don't have to worry about the other files, python will handle it fine, it's just the shell that wont.

[andrew.]

I use TextWrangler on Mac as a text editor for programming. It has the ability to save in Unix and Windows line endings. Download it and use that to save it as a Unix file.

[apomb]

ooh that makes sense now, thanks DtY for all the help.

I've never run into this problem before.

[DtY]

Probably because of how uncommon it is
I don't know why bash wouldn't support windows line endings, I can't imagine it would be a huge modification to the source.

[DtY]

Oh, another problem you might run into is that Mac uses forward slashes to separate directories, where windows uses backslashes. If the source uses backslashes to locate files it likely wont run on Mac. I know it wont run on Linux, but Mac OS might do something fancy for it to work. There is a function though (os.path.join()) which takes a directories and joins them together using the proper delimiter so that it can find the files okay on any platform, so it may not be a problem. I don't think most schools teach it though, so unless the creator is self taught, that may be a problem.

[andrew.]

Mac OS doesn't do anything fancy for it to work. It uses bash to run Python so, like Linux, it won't work with Windows file paths and Windows line endings.

[DtY]

Path names would be independent of bash. I know some languages like Ruby, PHP, and Turing (yes, Turing of all languages) will work with Unix path names on windows (not sure about other way though). It seems like something Python would implement, since it's a big cross platform language.

[Zeroth]

Okay, explanation time! (This is what happens when I'm gone for a few days... *sigh*)

First, windows uses \r\n, because the \r is called a "carriage return", a leftover from typewriters. It made the big ink carriage go to the left side of the page. \n is a newline, forcing the carriage down one line. Unix moved on from that standard, using just \n to move to the left and down. \r is used to return the cursor to the beginning of the line, and was used to make text spinners. Linux still follows that standard today. Unix(and probably an older OS probably) decided to change things up, and save an extra two bytes in text files. This made a difference back in 16bps or less days!

Now, the #! line? Yes, the hash mark is a python comment. However, that combination is used in executable scripts. It is what is called a "hash-bang". *nix looks for that as the first line, and if it doesn't, it guesses. But *nix doesn't use the filetype, usually, to determine what to do with a file. If you were running a perl script, the hash-bang would be "/usr/bin/env perl" and *nix would know to execute the file with that program. For python, the standard(and distribution safe) hash-bang format is "/usr/bin/env python". The reason it is done this way is so that the new python interpreter has a NEW environment, rather than relying on the environment you executed it in. This way, the starting directory is always the python default, all environmental variables are at their defaults, etc. This means the programs will work properly(or should), instead of relying on being in X directory, etc.

Finally, Mac OSX. It uses freaking Unix underneath! Everyone should know this. It operates according to the POSIX standard, so it has all the familiar commands and libraries. It just has a very User friendly GUI on top. Its not that much different from Ubuntu, just much shinier, and a lot more closed down. That also means that basic GNU tools, like chmod and that are all available by default. If it weren't for the slightly different libraries and slightly different system setup where POSIX has no standards, then Mac OSX would be treated just like Linux.