Re: [pygame] Quick OS survey - 2013
99% Gentoo Linux 1% Windows 7 On Thu, Dec 5, 2013 at 8:43 PM, Jason Marshall wrote: > pygamers, which computer operating system(s) have you used this year? If > you have been using more than 1 operating system, approximately what > percentage of your time are you using each one? > > Here's my breakdown: > 0.5%Linux Mint > 0.5%Mac OS X 10.4 > 2%Windows ME > 4%Windows XP > 5%Mac OS X 10.6 > 88%Windows 7 >
Re: [pygame] Extending OpenGL support in Pygame
While not completely drop-in, I found this project a few months ago that more-or-less accomplishes the goal. http://pygame.org/project-PyGL3Display-1562-3793.html On Thu, Apr 5, 2012 at 8:15 AM, James Paige wrote: > On Thu, Apr 05, 2012 at 04:08:08PM +0100, Sam Bull wrote: > > I was wondering if there was much interest in extending OpenGL support > > in Pygame. One of the things I am implementing in my toolkit is OpenGL > > support. To do this, I am effectively creating the surface class and > > draw module in OpenGL. I am using Pygame's API to create the interface > > for it, so that it can be simply dropped into the same places and > > behaves in the same way as vanilla Pygame. > > > > If this is something of interest to other people, I'm wondering whether > > there might be some interest in integrating this code into Pygame > > (sometime after GSoC). This would (I'm envisaging) allow users to create > > a game using Pygame's standard sprite and draw module, and be able to > > run it under OpenGL by simply adding the OPENGL flag. As opposed to > > having to recreate all of the drawing code. > > Even for developing 3D games, I think this would make it a lot > easier > > for developers to create the 2D elements of a game, such as the HUD. > > > > Thanks, > > Sam Bull > > > YES! Very much! In my personal opinion, the lack of simple drop-in > OpenGL support that works the same way as the existing Surface class is > the biggest weakness of pygame. > > Although I would much rather have such a feature as part of pygame, > rather than part of a GUI add-on > > --- > James Paige >
Re: [pygame] Declaring variables in function as if at code's line-level
I wanted to make one further suggestion: I think you need a fresh from-the-ground up education in programming as well as Python fundamentals. (Especially what makes Python different from Basic and from Java--there are a lot of things.) Since others have shared resources already, I'd like to share a modern reference I've heard great things about from people new to programming or Python. It's Zed Shaw's free online book: http://learnpythonthehardway.org/book/ On Tue, Mar 13, 2012 at 5:34 PM, Brian Brown wrote: > > I started QBasic at about 12. . . > I am nearly completely "self-taught" and > I started making my ball program in Java at about 14-- I carefully thought > out the algorithms by myself-- Because I couldn't find code about how to > make balls accurately bounce off walls --at any speed without glitches. > > Yeah, I see what you mean, Chris, "global" is not necessary when: all the > variables are created outside of all the functions-- I did know that > but-- I just wanted to create or delete any variables from within a > function-- which can be called whenever from wherever-- so I could easily > control/manipulate the memory consumption and variable usage. > (Well whatever, I'll find a way I guess.) > > I admit, it was really dumb to force my opinion on all of you. > (I was Not planning on saying what I did-- but it just wasn't my day. > (if you know what I mean) I thought I would just ask one simple question > and get the answer. lol But I accidentally let my frustration show in my > replies. So stupid of me.) > > Anyways, I think I should just continue being a solo programmer. > lol I'm too wild when it comes to programming that I think I need "my own > space." If you know what I mean. > > stress_relieving_variable = 'Five-Hundred and Forty-Three Lily Hopping > Ponies All Cooking Savory Spaghetti' > dont_print(stress_relieving_variable) > > # Shshsh! Don't let anyone know I gave you > # The ultimate key to game programming! > # (Don't share it with anyone else, because > # they will only want it for themselves! >:3 ) > > lolol! > > Thanks again for all your replies, suggestions, and the links. ; ) > And sorry for making such a big scene-- > I must do some chores. > > Goodbye. > (You may abandon the thread.) > > Sincerely, Matthew > > > On Tue, Mar 13, 2012 at 3:21 PM, Daniel Pope wrote: > >> On Mon, Mar 12, 2012 at 12:27:39PM -0700, Brian Brown wrote: >> > Matthew N. Brown >> >> I googled. I guess this is yours? >> >> http://pastebin.com/kKXSgw8c >> >> > It's like"pygame.draw.line()" instead of just: "DRAW_LINE()" >> >> It's because of fallacies like this that your program would be >> completely unmaintainable for anyone other than you. >> >> Classes and modules allow us to break our code into separate concerns >> that other programmers can pick up and understand immediately (as can we >> when we come back to something having forgotten what we wrote). >> >> They also tend to allow massive amounts of code re-use. If you wrote >> only a proper 2D vector class (or downloaded one [1]) I reckon you could >> halve the amount of code you had to write for your bouncing balls >> program. >> >> To help you out, here is the A Byte of Python chapter about Object >> Oriented Programming (ie. classes): >> >> http://www.swaroopch.com/notes/Python_en:Object_Oriented_Programming >> >> [1] http://www.supereffective.org/pages/Vector-2d-Vector-Library >> > >
Re: [pygame] issue with pygame.rect.inflate_ip()
Hey David. Good catch, I was a bit too hasty in asserting a strict equality. Just goes to show the problem with truncating instead of rounding or using rationals. Scaling a line from 0->10 down to length 5 results in chopping off 5 from the width, then adding 2.5 (which gets truncated to 2) to recenter. The new line then is from 2->7 with a center at (2+7)/2 = 4.5 = 4, but it should really be 2.5->7.5 with a center at (2.5+7.5)/2 = 5. The original code is still correct in most respects, though perhaps the documentation should be changed. You can work around the issue by storing the original center and reassigning it after the inflation or by using a data structure with floats or by using your own inflate function that rounds. The devs could also change the code such that the division by 2 will round properly but there are reasons why this might not be desirable. One relatively minor reason is that the change requires a branch for negative numbers to round properly. x/2 for x>=0 turns into (x+1)/2 == x + (1-x)/2 to avoid overflow. For x < 0, it turns into (x-1)/2 == x - (1+x)/2. On Sun, Feb 5, 2012 at 2:54 PM, david BERTRAND wrote: > Hi kevin, hi Lenard, > here is my try : > > import pygame > pygame.init() > class Box(pygame.sprite.Sprite): > def __init__(self): > pygame.sprite.Sprite.__init__(self) > self.image = pygame.Surface((10, 10)) > self.rect = self.image.get_rect() > b = Box() > print "initial b.rect : %s b.rect.center : %s" % (b.rect, > b.rect.center) > b.rect.inflate_ip(5, 5) > print "inflated b.rect : %s b.rect.center : %s\n" % (b.rect, > b.rect.center) > c = Box() > print "initial c.rect : %s c.rect.center : %s" % (c.rect, > c.rect.center) > c.rect.inflate_ip(-5, -5) > print "inflated c.rect : %s c.rect.center : %s" % (c.rect, > c.rect.center) > > # outputs : > # > # initial b.rect : b.rect.center : (5, 5) > # inflated b.rect : b.rect.center : (5, 5) > # > # initial c.rect : c.rect.center : (5, 5) > # inflated c.rect : c.rect.center : (4, 4) > > I have just said it is different from what is espected ((-2, -2), (13, 13) > and (5, 5) or (0, 0), (15, 15) and (7, 7)) for b.rect and b.rect center > And he results are worse with negatives. > > > > >
Re: [pygame] issue with pygame.rect.inflate_ip()
David, The inflate() method is designed such that r1.center == r1.inflate(x,y).center. You can easily prove this to yourself by running code, it works in practice. Additionally (r1.size[0]+x, r1.size[1]+y) == r2.inflate(x,y).size. If you have a line that's 10 units long and whose start point is at 0 and end point is at 10, then the center is 5. If you inflate it by 5 units, the total width is now 15, and the line starts at point 0 and ends at 15. But now the center is at 7 instead of 5. In order to adjust you move the line over by 5/2 units, in this case 2 units, so now the line starts at -2 and ends at 13 with the center again at 5. If you used your second code section instead of the real thing, what would happen when you tried to inflate a line by 5 is that the total width changes to 12 and it only gets shifted back by 2. The new center is therefore at 4, instead of 5, which is not what you want. Also the bottomright corner is represented by x+width and y+height. On Sun, Feb 5, 2012 at 3:13 AM, david BERTRAND wrote: > Hi Lenard, > > I agree with you (and with the theory), but in practice, the new object > size and the new center position are not correct ( in both case, the error > is (x/2, y/2). > > regards, > David > > 2012/2/4 Lenard Lindstrom > >> On 04/02/12 07:12 AM, david BERTRAND wrote: >> >>> Hi, >>> >>> I'm new here but I'm working whith pygame (1.9.2) since few month. >>> When I use inflate() or inflate_ip, the resulting size and the new >>> rect.center are never as expected. >>> >>> reading the sources (1.9.1, rect.c), I found : >>> >>> self->r.x -= x / 2; >>> self->r.y -= y / 2; >>> self->r.w += x; >>> self->r.h += y; >>> >>> if (r.w, r.h) is the size of the rect this is correct. >>> But it woks like if (r.w, r.h) represents the rect.bottomright corner. >>> Andin this case, it seems better to write something like : >>> >>> self->r.x -= x / 2; >>> self->r.y -= y / 2; >>> self->r.w += x / 2; >>> self->r.h += y / 2; >>> >>> Please, excuse me if I am wrong : I am not a great C reader. >>> >> >> Hi David, >> >> A rectangle is stored as the position of the top-left corner (r.x, r.y), >> and the size (r.w, r.h). It is the same with rectangles in Python: >> Rect(left, top, width, height). >> >> Lenard Lindstrom >> >> >
Re: [pygame] Capabilities of Pygame
Or just set it to -1? (Docs are wonderful: http://www.pygame.org/docs/ref/music.html#pygame.mixer.music.play ) On Fri, Jan 13, 2012 at 7:36 PM, Zack Baker wrote: > I use it for my 'soundtracks' in the games. The only problem I run into > with it is it takes a 'loop' argument, which is how many times the song > should loop, I wish you could set this too infinite but I usually set it > too 500 and that seems to work. Assuming no one will play my game for mor > than 26 hours in a row... > > -Zack > > > On Jan 13, 2012, at 9:22 PM, Christopher Night > wrote: > > On Fri, Jan 13, 2012 at 9:15 PM, Lenard Lindstrom wrote: > >> On 13/01/12 01:43 PM, Julian Marchant wrote: >> >>> --- On Fri, 1/13/12, Lenard Lindstrom wrote: >>> >>> Also, though SDL does support streaming, Pygame does not. Everything must be loaded before played. >>> Um... that's not true. pygame.mixer.music is Pygame's streaming module. >>> >> Oh right, I forgot about file like objects. Has anyone managed to use the >> music module to play streaming audio? >> > > I feel like I'm misunderstanding you, but yes I use pygame.mixer.music to > stream audio from an OGG file all the time. I've never had a problem with > it. Is that what you're asking? > > -Christopher > >
Re: [pygame] Capabilities of Pygame
It should also be noted that C++ itself isn't fundamentally a fast language from a design perspective (and if you make the mistake of having a lot of "new"s and "delete"s going off at inopportune times you'll see its true potential sluggishness). Its primary benefit is that it lets you talk to hardware more-or-less directly which lets you the intelligent programmer (with the help of the compiler) align the interests of the hardware with the interests of the problem you're trying to solve, whereas Python is mostly about just solving the problem even if it takes a long time to compute. Which makes it an excellent platform to learn anything abstractly (like game design) off of while not simultaneously fighting with the language on account of hardware being a particular way. You can focus on learning algorithms and data structures that improve efficiency in a language-agnostic way and with Python's flexibility you can also explore algorithms that don't usually get mentioned in the C++ world that may fit your particular case (and learn to love native dictionaries/hash tables and lists). Sufficiently smart compilers have been able to compile Haskell and (slightly annotated) Common Lisp to code that beats C++ for a long while now, and FORTRAN is still used in some circles because it's still very fast for number crunching. Projects others mentioned like PyPy continue to narrow the margins though they've got a ways to go. Unfortunately talking to hardware directly with Python usually means doing it with C/C++ then talking to those libs from Python. (As is the case for PyGame's core (SDL in C), PyOpenGL, etc.) I'd like to say this is the standard approach for most Pythonistas: write everything in Python, then rewrite the slow bits in C/C++. Fortunately a lot of the reasons we might need to talk to the hardware (graphics drivers, screens, fast number crunching) are general enough that other people have done most of the work for you to take advantage of. Even in the FPGA world where you get to design your own hardware with code, there's the MyHDL project which provides Python with nice sugar for HDL code and compiles your source to Verilog or VHDL which you'd normally write instead at your own peril and frustration.
Re: [pygame] man oh man Java is painful
I don't see why anyone would start a new project in C++ these days. There
are just so many better alternatives. Perhaps you could look at a Lisp;
Common Lisp can compile to machine code, and Clojure's really nice and runs
on the JVM and can run on Android. Haskell's cool too but a bit hard. ;)
On Sat, Nov 5, 2011 at 8:00 PM, Toni Alatalo wrote:
> On Nov 6, 2011, at 4:04 AM, Toni Alatalo wrote:
> > On Nov 6, 2011, at 2:15 AM, Greg Ewing wrote:
> >>> Absolutely not sure it fits the bill... but have you had a look at go?
> >>> http://golang.org/
> >> I looked at it. My first impression was "this is ugly". I'm pretty
> >> sure it's not the language I was talking about.
> > No, that is indeed the google Go thing.
>
> Ah, sorry - misread that earlier :p (you said 'I' whereas I thought you
> referred to someone else talking about google's cool new lang, and you
> thinking that something so ugly as what's behind that link wouldn't be that
> one .. was tired)
>
> I haven't realliy studied it, but also am not too convinced. Dunno,
> perhaps should look more though if need compiled stuff.
>
> ~Toni
>
> > Which they support on the app engine to have something faster than py,
> but nicer than c. But is somewhat close to c I guess.
> >
> > The fibonacci example is:
> >
> > package main
> >
> > // fib returns a function that returns
> > // successive Fibonacci numbers.
> > func fib() func() int {
> > a, b := 0, 1
> > return func() int {
> > a, b = b, a+b
> > return b
> > }
> > }
> >
> > func main() {
> > f := fib()
> > // Function calls are evaluated left-to-right.
> > println(f(), f(), f(), f(), f())
> > }
> >
> >> Greg
> >
> >
> > ~Toni
> >
>
>
--
"NORMAL is a setting on a washing-machine." -- Nikolai Kingsley
Re: [pygame] growing out of idle ide
On Thu, Aug 11, 2011 at 3:30 PM, Justin Hamilton < justinanthonyhamil...@gmail.com> wrote: > I'm a huge Emacs + python-mode + rope + yasnippet guy, but if you don't > already know Emacs its probably a bit much to jump into. I've never used > IDLE. > I'll be the vim guy. :) "Linux is my IDE, vim is my editor." I agree both vim and emacs have a fairly substantial learning curve price that may not be worth it for certain people/cases. I played with SPE (Stani's Python Editor) a while back, it was pretty neat: http://pythonide.stani.be/
[pygame] Who else uses pyinstaller?
I haven't used py2exe in a long time, but judging from the occasional mailing list or IRC questions I read people still have issues with it. Personally I've always just used PyInstaller ( http://www.pyinstaller.org/), since it's dead simple and I typically only have to compile once; I can fix errors in my imported .py files without needing to recompile the exe. Not that compiling is particularly hard or time consuming: $ winpython Makespec.py --onefile main.py $ winpython Build.py main.spec and then I just copy the generated EXE to my game folder. So does anyone else use PyInstaller? Does anyone else have experience in both PyInstaller and py2exe to make a good comparison of the two?
Re: [pygame] Show text on screen for a limited time
Are you using sprite Groups? In any case, a simple solution to me would be having the "Try Again" surface wrapped up in a sprite class along with a "lifetime" attribute you can set, then in the update() loop check to see if it's time to kill it or not, where killing could mean removing from a sprite group or setting a "visible" flag or however you're controlling which sprites get rendered when. "lifetime" can either be a number of frames, in which case you'd just decrement it on update(), or a number of seconds, which you can then compare with an initial "last_time" variable initialized with pygame.time.get_ticks(), and you just compare your lifetime var with (pygame.time.get_ticks() - self.last_time) to determine if it's time to kill it or not. If you re-add the sprite to a group later, you can reset/initialize the "last_time" var then. Hope this helps, -Kevin On Mon, Jun 7, 2010 at 9:36 AM, Dan Ross wrote: > Hi all- > > I have a spelling game that has the user spell a word that matches the > picture shown. > > When they press enter, the picture changes when correct and displays "Try > Again" if incorrect. > > I can't seem to figure out a way to have "Try Again" display for only a > set time. > > Any help would be appreciated. > > Thanks, > > Dan >
Re: [pygame] Is PyGame dying?
I think the "slowness" of PyGame development is simply due to the slowness of SDL development. I think everyone's just waiting for 1.3 to mature, and with it comes a lot of nice features. What is it you think the PyGame devs should be working on with all haste? I've found the level of development is pretty good, and PyGame's done a few GSoC projects. I'm also frankly amazed at how many projects are listed on the pygame website. I've looked at the Panda3D engine and it just didn't compare in that respect; the amount of source code available for pygame apps just amazes me. As for your second question of user support, I have no idea. I've asked a couple questions here before but I mostly find answers googling around or using one of the pygame books I have.
Re: [pygame] author & license of the pygame_logo (the snake) ?
If the snake is just being used in a tutorial then you could probably make a Fair Use case out of it, anyway. > When an item is distributed freely without any mention to licenses, it is > considered of public domain, so you can use it as you please. That is, if > really there is no copyright on it. > Where can i find the author & exact license of the pygame snake > graphic ? It's the logo on top of the www.pygame.org website and can be > downloaded at http://www.pygame.org/download.shtml but i see no license > information. I want to put the snake graphic as sprite in some python / > pygame tutorials. > > greetings, >-Horst >
Re: [pygame] Erratic behavior with pygame.font.SysFont
I can second the program works fine on my Linux install as well. (Python 2.6.4, PyGame 1.9.1, 64-bit Gentoo) On Tue, Dec 29, 2009 at 11:02 PM, Mark Reed wrote: > On XP with 1.9.1 I freeze up on the ~10th font called impact. Fresh > Ubuntu install clicks through all fonts without freezing. > >
Re: [pygame] Ncurses RTS?
So build for 2.5? I know PDcurses is cross-platform, but I'm doubtful there's a Python wrapper for it. On Mon, Dec 7, 2009 at 9:11 AM, Yanom Mobis wrote: > wcurses only goes up to python 2.5. my system is 2.6 > > > > >
