Re: [pygame] Opinions on the status of GUI libraries

Well, the beauty of OSS is that you can make a contribution to existing libraries. On Mon, Sep 20, 2010 at 1:12 AM, Thiago Chaves shundr...@gmail.com wrote: Hi, I'd like to know what is the opinion of the list members regarding Pygame website's GUI libraries. Which ones are good, which ones

Re: [pygame] more circles

if you change the size of the sprite, you need to redraw it. the bit you should move from the constructor to the updating func (or a resize func) is the bit that actually draws your circle onto the sprites buffer self.image. On Fri, Oct 8, 2010 at 11:08 AM, kevin hayes kevino...@gmail.com wrote:

Re: [pygame] keep a key pressed and then move a sprite

for my project python fighter framework (http://www.pygame.org/project-fighter+framework-1550-2747.html), i handle keyup and keydown events separately and maintain a dictionary of pressed keys. then the game can properly handle multiple key presses (though subject to the evil keyboard problem).

Re: [pygame] growing out of idle ide

I use MacVim for small projects and occasionally Eclipse+pydev for others. On Wed, Aug 17, 2011 at 1:38 PM, Sean Wolfe ether@gmail.com wrote: Looks like I'm moving towards Geany now. With a little tweaking you can get it nearly as minimalist as idle... which I like. On Wed, Aug 17, 2011

Re: [pygame] growing out of idle ide

On color scemes, I've been grey on blue for a few years in vim. On Wed, Aug 17, 2011 at 10:26 PM, Leif Theden leif.the...@gmail.com wrote: I use MacVim for small projects and occasionally Eclipse+pydev for others. On Wed, Aug 17, 2011 at 1:38 PM, Sean Wolfe ether@gmail.com wrote: Looks

Re: [pygame] pgreloaded on the move

Awesome! I look forward to trying it out soon. On Jun 26, 2012, at 2:22 PM, Marcus von Appen wrote: It got quite quiet for the last months (year) around pgreloaded. Apologies to everyone who had expectations in it. Since March I started over with moving on to SDL2, stopping the SDL1.2

[pygame] TMX support in pygame

Hello everyone! I'm a long time user of pygame and active member of #pygame under the handle bitcraft. I help many people who stumble into the channel to build their first game in pygame. I've also released and maintain a couple small libraries PyTMX and Pyscroll to help new users develop using

Re: [pygame] TMX support in pygame

support in pygame * Sent: * Thu, Sep 18, 2014 11:48:26 AM I haven't used your tools myself, but if they really work well and have a tutorial and good documentation, then I'm in favor of adding them. Batteries included! Thanks, Jason -- *From:* Leif Theden

Re: [pygame] TMX support in pygame

it could be made more usable before we go ahead and write lots of documentation/tests/etc for it. Of course, pygame hasn't done a release for a while. So you may want to take that into consideration before embarking on all this work. cu. On Fri, Sep 19, 2014 at 6:10 PM, Leif Theden

Re: [pygame] TMX support in pygame

, diliup gabadamudalige dili...@gmail.com wrote: This is great! There should be more people like you. I sincerely hope that the maintainers will take the initiative and do the needful. Looking forward to a new version of Pygame! On Tue, Sep 30, 2014 at 12:30 AM, Leif Theden leif.the

Re: [pygame] TMX support in pygame

Bart, The modules I've proposed are pure python won't need to be compiled, or even required for pygame to function. I am a supporter of the pygame project as a whole, and have no problems with maintaining this module for the use of pygame users. I think you've raised your point well enough, and

Re: [pygame] TMX support in pygame

On ven, 2014-10-03 at 12:24 +0530, diliup gabadamudalige wrote: Why can't all these add on's be separate modules or packages and leave Pygame to run it's own natural course as it has done in the past? Why this rush to include these libraries INTO Pygame? I don't see it as a rush. It may

Re: [pygame] TMX support in pygame

for Linux, Mac, and Windows across the major Pygame distributions. Paul Vincent Craven On Fri, Oct 3, 2014 at 1:53 PM, Leif Theden leif.the...@gmail.com wrote: On ven, 2014-10-03 at 12:24 +0530, diliup gabadamudalige wrote: Why can't all these add on's be separate modules or packages and leave

Re: [pygame] TMX support in pygame

I've created a new branch of my scrolling and map loading libraries with the intentions of matching the pygame documentation format, removing external library requirements, and for eventual submission into the pygame project. Based on the input from this discussion, I will just be submitting the

[pygame] IRC Moderation

Greetings, I am a regular lurker of #pygame on freenode, and as of late there have been a few instances of generally rude people on the channel. I don't know of anyone who can moderate the channel, so I'd just like to get an idea of what is considered acceptable language and if there is any

Re: [pygame] IRC Moderation

to ##pygame, and get ownership of ##pygame (I think that should be possible...) BTW, I have no idea about Leif, but as a channel operator of #python (ssbr) I can vouch for wkmanire based on our interactions there. They would be fine as an op on #pygame. -- Devin On Fri, Jan 9, 2015 at 4:16 PM, Leif

Re: [pygame] What's next for Pygame project?

I am also OK with breaking compatability if it means a better experience for developers and end users. Let's just skip 2.0 and jump to pygame 3k. :D On Wed, Jul 15, 2015 at 10:39 AM, diliup gabadamudalige dili...@gmail.com wrote: It's good to see all this interest in Pygame after all these

Re: [pygame] New Pygame 1.9.2a0 Windows x86 installers for Python 2.7 and 3.4

Great work! I love that 3.4 is supported in an official installer. On Thu, Sep 10, 2015 at 12:54 AM, diliup gabadamudalige wrote: > Don't replace Avast! It's a good ol program and does a good job leaving > only a small foot print. :) > > This version of Pygame was available

Re: [pygame] Should I use Sprites and Groups ?

I generally advocate the use of sprite groups since they tend to simplify common tasks like updating, drawing, and even adding and removing sprites from the game. Its a proven system that works well enough. These days CPUs are fast enough that its is just easiest to draw everything and not worry

Re: [pygame] Faster blitting

nderstand and > agree with why it had to be this way. Not a criticism, but a critique that > I think is apt for this discussion. > > Gumm > > > On 3/13/2016 2:06 PM, Leif Theden wrote: > > Heh, hostility is fun, right? I am not a C programmer, please pay > attention. I have used

[pygame] Faster blitting

Going through the pygame source, I've noticed that the surface blit method does a considerable amount of checking to make sure surfaces share pixel format, clipping, etc, and will even convert surfaces before blitting. Its really useful because it hides complexity and generally works as expected,

Re: [pygame] Faster blitting

How could I? I appreciate the skepticism, but if fast_blit is not implemented, how could I test the overhead? And, it is not just format checking, it is also clipping and bounds checking. On Sun, Mar 13, 2016 at 6:22 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Leif The

Re: [pygame] Faster blitting

Heh, hostility is fun, right? I am not a C programmer, please pay attention. I have used colorkey, but that is not a straightforward way to increase speed. Since it involves a check on each pixel, some images may not benefit (and in fact will lower performance) if there isn't much transparency.

Re: [pygame] Faster blitting

Thanks for taking the time Peter to do this benchmark, but I don't believe that this is testing the overhead that exists in the pygame C code. To clarify, your benchmark is slightly contrived in that it is doubling the python workload, when I am interested in seeing the results of getting lower

Re: [pygame] Faster blitting

> https://bitbucket.org/snippets/frnknstn/bKqAz > > Here is the test Python code I used: > https://bitbucket.org/snippets/frnknstn/dKqAr > > Regards, > Peter Finlayson > > > > On 2016/03/14 08:55 PM, Leif Theden wrote: > >> Thanks for taking the time Pete

Re: [pygame] Faster blitting

Not to discourage further thought down this road, but any slowness is > probably due to some other optimization problems. The OP might want to try, > python -m cProfile -s cumulative > > Also remember to do surface.convert() or surface.convert_alpha() on each > surface. > Jeff > &

Re: [pygame] Faster blitting

Lol, daniel, I'm doing that right now. On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster <pydsig...@gmail.com> wrote: > Perhaps a function to blit multiple surfaces at once would be more helpful? > > > On 03/14/2016 07:01 PM, Leif Theden wrote: > > Thanks for the ben

Re: [pygame] Faster blitting

tever. I'm sure that the code leaks or is not optimal, but it is working, strictly as a test. https://gist.github.com/bitcraft/1785face7c5684916cde On Mon, Mar 14, 2016 at 8:44 PM, Leif Theden <leif.the...@gmail.com> wrote: > Lol, daniel, I'm doing that right now. > > On Mon, Mar 14

Re: [pygame] PYGAME 2.0

Nothing wrong with being lab rats. I've played with it a bit, and while its not a "drop in replacement", it seems stable enough. More testers is better. At one time pygame1 was in a "test" stageno need to fear it. On Thu, Apr 14, 2016 at 5:42 AM, DiliupG wrote: > :-D >

Re: [pygame] Pymunk 5.0 Released

Love it! Pymunk is def. one of my favorite libraries ever. Thanks for your hard work with it. 64-bit support is great. I had problems with it in the past... Looking forward to playing with the geometry generation. On Sun, Jul 24, 2016 at 1:10 PM, DiliupG wrote: >

Re: [pygame] 1.9.2 release coming soon, last call for patches

Sprite groups act more like sets unless you are using a OrderedGroup subclass (which uses a list instead of a dict for sprite membership). In that case, I think it is appropriate that "add" is used instead of "append". In any case, groups are not lists, so I would just impress onto your students

Re: [pygame] Solarwolf on python3.6

+1 for py3.6 support! On Tue, Jan 24, 2017 at 12:01 AM, René Dudfield wrote: > Hello, > > so I started porting Solarwolf to a newer python. > > python3.6 -m venv anenv > . ./anenv/bin/activate > pip install --pre solarwolf > solarwolf > > Anyone able to give it a test run? > >

Re: [pygame] Re: Out of memory loading very large image

Just to chip in here, I've also had issues with very large files. My work around in the past was to simply resize files with imagemagick before loading them in pygame. I've also done the "large chunks and lazy load" with some success, but only after some preprocessing outside of pygame. Best of

Re: [pygame] Re: pygame with SDL2 proposal

tep (I will try and find everyone, >>but please send me your nickname on there if I haven't already found >> you?). >>The build tools should be able to be moved easily. There is a pretty good >>import from bitbucket script provided by github. I've already started to >&

Re: [pygame] Re: pygame with SDL2 proposal

trying to be helpful. His claim isn't even controversial - GPU, >> ASIC, and CPU rendering all have different trade offs. As do game libraries >> like pygame. >> > On Mon, Mar 20, 2017 at 5:18 PM, Leif Theden <leif.the...@gmail.com> > wrote: > >> Ian, you are reall

Re: [pygame] Dirty rect overlapping optimizations

imizations > for reducing over draw for now. Because that could be applied to something > like pygame zero with almost no work on their part, and no work on the > users part. For non-worst cases, like where there's < 50 rects, I guess > simply compiling an algorithm like DR0ID ha

Re: [pygame] Dirty rect overlapping optimizations

In my experience, I've found it is better to optimize the game as if the whole screen was being updated at the same time. The effect being, I never bother with dirty updates. It seems that many games will have moments of brief full or near full screen updates, and time spent optimizing the

Re: [pygame] Dirty rect overlapping optimizations

Just to clarify, this is an optimization to update the display surface? TBH, if DR0ID says that it isn't a good optimization, then I'll have to follow him. Thinking deeply about the issue, the would be better payoffs by finding way to not flip bits in the display surface in the first place. To

Re: [pygame] The long-ish pygame github migration status email.

> Github doesn't really have downloads. We could put all the files in a repo though. This is better I think . Typically "downloads" are under the releases section in github. On Sun, Mar 26, 2017 at 12:38 PM, René Dudfield wrote: > Hello, > > https://github.com/pygame/pygame >

Re: [pygame] github terms of service issues

The software as an industry seems to be moving towards age-inclusiveness. There are significant issues with allow minors to sign up for any internet-facing service, and it would likely take years of legislation on with support from many companies to provide new guidelines that protect kids and

Re: blits proposal, was Re: [pygame] Dirty rect overlapping optimizations

Pull request sent with basic functionality of Surface.blits. https://bitbucket.org/pygame/pygame/pull-requests/79 On Thu, Mar 30, 2017 at 2:44 AM, René Dudfield wrote: > Not sure. I need to do some benchmarking, and then more research into if > the API can cover everything we

Re: blits proposal, was Re: [pygame] Dirty rect overlapping optimizations

k it would likely >> be fast enough for another commonly requested case (blit the same image to >> many different spots). It would also work nicely for sprite groups. I think >> it's worth some more API discussion, before merging it in. We'd also need >> some tests and docs. >> >>

Re: [pygame] pygame with SDL2 proposal

ing excellent work in > OpenGL ES bindings and deployment on mobile, with a crude UI framework and > runtime. > > I guess all I'm saying is that we should keep Pygame simple, and let other > projects build the ecosystem on top of it. > > On Sun, 19 Mar 2017, 13:27 Leif Theden

Re: [pygame] pygame with SDL2 proposal

My comment from the Reddit: It has always been my feeling that pygame2 break compatibility with pygame1 and embrace modern computer features, namely the GPU. Shoehorning the clunky surface & blit API over sdl2 is a major regression. As is, no modern game library uses a system like this. If it is

Re: [pygame] pygame with SDL2 proposal

offer easier > to understand abstractions? Can you make games do things that would be > impossible with 1.2? And are there any downsides to the new version? I > think we need an idea of the differences to have a useful discussion on > supporting SDL 2. > > Thomas > > On 19 Mar 201

Re: [pygame] pygame with SDL2 proposal

I think that rewriting the extension modules in cython would be a great way to make the project accessible to new developers. Writing extensions in C, as it is now, requires that developers have 1. Good C skills, 2. Understanding of the Python C library, 3. Knowledge of the SDL library, 4.

Re: [pygame] pygame with SDL2 proposal

as potentially >>> things like draw.rect(...) and draw.line(...). >>> >> >> This is undoubtedly true in the case of drawing one pixel at a time, >> but are you sure it's true for lines and rectangles? > > > On Mon, Mar 20, 2017 at 12:25 PM, Leif Theden <leif.the...@gmail

Re: [pygame] Re: pygame with SDL2 proposal

I'll add, so that my comments don't seem too caustic, that the maintainers have gotten more responsive recently. The "don't accept patches" comment isn't as true as it used to be. On Tue, Mar 21, 2017 at 7:27 AM Leif Theden <leif.the...@gmail.com> wrote: > At this rate,

Re: [pygame] pygame with SDL2 proposal

I agree with Thomas; a compile time switch of SDL 1 or 2 sounds like a nightmare and source of confusion for end users. Doesn't sound like a simple way forward, and further locks the code base to a few developers who can understand how the whole thing works. The developers of pygame are currently

Re: [pygame] pygame with SDL2 proposal

For those interested, here is the SDL2 migration guide. Pygame is combination of SDL 1.2 wrapper code (surface, events), some value-added type functions (drawing code, some rect functions), and python code (like sprite module). Because of this, it is protected from some changes to the underlying

Re: [pygame] pygame with SDL2 proposal

lable. I don't mind adapting small changes to my projects where there is a great payoff for the effort. On Mon, Mar 20, 2017 at 10:06 AM, Leif Theden <leif.the...@gmail.com> wrote: > For those interested, here is the SDL2 migration guide. Pygame is > combination of SDL 1.2 wrapper

Re: [pygame] pygame with SDL2 proposal

Good points Ian, but I don't see why we need to support software drawing when OpengGL supports drawing primitives? Is there a compelling reason that drawing lines with the CPU is better then doing it on the GPU? Also, I'm a bit tired of the "python is slow so you may as well make everything slow

Re: [pygame] Re: pygame with SDL2 proposal

At this rate, we can expect SDL 2 to work in 3 years...all in the name of compatibility? It doesn't help that Rene is also maintaining the webpage... he's got no time. Let's be realistic, there are very few people who have the will or ability to deal with the pygame code base; and with the

Re: [pygame] Pygame for SDL 2, and how it may look.

The renderer should have its own class, and for simplicity, I think it should be instanced by calling a method on the window that contains it. Just preference. Renderer does not below with the draw module, because it is not for drawing lines, and primitives on software surface. It is a

Re: [pygame] https://pygame.org/

That game uses pygame_sdl2, not pygame. https://www.reddit.com/r/pygame/comments/4ck5zv/released_a_pygame_game_on_steam_after_3_years_of/ On Tue, Apr 18, 2017 at 9:00 AM, Thomas Kluyver wrote: > On 16 April 2017 at 18:19, DiliupG wrote: > >> A game written

Re: [pygame] Pygame for SDL 2, and how it may look.

Wed, Apr 19, 2017 at 1:16 AM, Lenard Lindstrom <le...@telus.net> wrote: > Hi Leif, > > On 17-04-18 09:10 AM, Leif Theden wrote: > >> The renderer should have its own class, and for simplicity, I think it >> should be instanced by calling a method on the window tha

Re: [pygame] Pygame for SDL 2, and how it may look.

RendererWindow, but I support separate Window and Renderer objects. On Wed, Apr 19, 2017 at 11:12 PM, Lenard Lindstrom <le...@telus.net> wrote: > Hello, > > On 17-04-19 04:26 PM, Leif Theden wrote: > >> While I can understand why you wouldn't like the create_ synt

Re: [pygame] Re: Playing with Flatpak packaging

+1 for python3 first. Great work, Thomas, looks interesting. On Tue, Mar 7, 2017 at 10:10 AM, Thomas Kluyver wrote: > It should be easy enough to make a base app using Python 2.7 - I just > focus on Python 3 first, because that's what I'm most interested in. > > As John

Re: [pygame] https://pygame.org/

Looks great. A good improvement. On Mon, Mar 13, 2017 at 4:37 AM René Dudfield wrote: > Thanks Diliup! I'm hoping it won't take too much time. I want to make it > as low amount of work as possible for the moderators. > > Will be in touch some time in the next week. > > cheers!

Re: [pygame] Re: pygame with SDL2 proposal

wrote: > On 21 March 2017 at 12:27, Leif Theden <leif.the...@gmail.com> wrote: > > Students should be taught how textures work, where different memories > reside, and that GPUs operate differently than a CPU. At this point I think > everyone knows where I stand, so I'll just l

Re: [pygame] Documenting the pygame C API and making the API consistent

unless you are committed to to rewriting everything, i would leave changing error handling alone alone...C is not forgiving and very few people (a dozen, maybe?) use the pygame internal C code, and unless its getting in your way and slowing down development its probably best to document the code

Re: [pygame] Opening Python project in PyCharm - Mac

I've never seen pycharm open a project from the Finder, or equivalent in Windows or Linux. However, if you pass a full path to the project folder to the pycharm.sh (linux, i think also mac osx) it will open the project. I'm a daily user of pycharm, so it is almost never closed Using that

Re: [pygame] Starting the pygame 2 series

Woo hoo! I saw the staggering number of commits and figured it would be stuck in code review for a month. Very cool to see them merged in quickly. Looking forward to helping out in any way. On Thu, Aug 2, 2018 at 8:26 AM, René Dudfield wrote: > Thanks you two :) That's very kind. > >

Re: [pygame] Draft of, Let's write a unit test

This is cool, thanks Rene. Are there any modules in pygame that don't have good coverage or tests? On Thu, Jul 19, 2018 at 2:14 AM, René Dudfield wrote: > Wow. Thanks Luke for the extensive feedback and ideas! :) > > Al, I'm just writing it with the blogger editor and hyper. I'll be moving >

Re: [pygame] Starting the pygame 2 series

Is this unrelated to the "Renderer" API? Just IMO, i'd rather use the Renderer API than trying to work with obsolete opengl and have cross-platform issues. Not worth getting working if it really has all these issues. On Mon, Aug 13, 2018 at 1:15 PM, René Dudfield wrote: > Yes! For sure. I

Re: [pygame] pygame awesome libraries?

Ahem. I'll shill more of my libraries: https://github.com/bitcraft/animation Tasks and tweening using pygame groups. No framework needed to have things execute over time. On Thu, Apr 5, 2018 at 8:39 AM, Martin Kühne wrote: > On Thu, Apr 5, 2018 at 2:40 PM, Yann

Re: [pygame] pygame.key.get_pressed() works unpredictably

mspaintmaestro: > I'm curious, can you explain why they shouldn't be used at the same time? Iterating over the event queue will pump events, which will process/check key state (as you mentioned). This may lead to small differences between what your game logic gets when checking get_pressed or

Re: [pygame] pygame.key.get_pressed() works unpredictably

:56 PM, Leif Theden <leif.the...@gmail.com> wrote: > mspaintmaestro: > > > I'm curious, can you explain why they shouldn't be used at the same time? > > Iterating over the event queue will pump events, which will process/check > key state (as you mentioned). This may lead t

Re: [pygame] Only first call to Sound.play() is working

You could consider polling the mixer until the sound stops so you can avoid hardcoding the time to wait until exit/ https://www.pygame.org/docs/ref/mixer.html#pygame.mixer.get_busy On Sun, Apr 22, 2018 at 10:07 AM, Avi Yaar wrote: > Thanks Greg and Pablo for the advice. It

Re: [pygame] how to sign up?

if you are talking about the website pygame.org, signup should be here https://www.pygame.org/register you are also invited to join the community discord witch is the unofficial server for pygame https://discord.gg/cNSnd8Jf On Tue, Apr 5, 2022 at 8:17 AM kueden lego wrote: > I am new to pygame