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 a
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 thin
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
> it
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.
>
> Currentl
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 ra
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 turned out to be wha
i, Apr 6, 2018 at 12:56 PM, Leif Theden 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
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 the
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 Thorimbert
> wrote:
> > Not e
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 info
he back-and-forth and say that I don't support
RendererWindow, but I support separate Window and Renderer objects.
On Wed, Apr 19, 2017 at 11:12 PM, Lenard Lindstrom wrote:
> Hello,
>
> On 17-04-19 04:26 PM, Leif Theden wrote:
>
>> While I can understand why you wouldn't
your API demo suggests.
On Wed, Apr 19, 2017 at 1:16 AM, Lenard Lindstrom 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
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 in Python/Pygame released commerciall
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 cross-plat
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 want it to do. (wh
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 enab
; On Mon, Mar 27, 2017 at 6:38 PM, René Dudfield wrote:
>
>> Cool about the blit function. Since the rect and surfaces are by
>> reference, then you only need to make sprite_image_list once (if you are
>> blitting the same thing every time). Additionally, I think it would li
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
screen
d in if anyone has done any work on dirty rect optimizations
> 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 gue
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 say
> 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
>
> TLDR; git repo, a
en 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
> wrote:
>
>> Ian, you are really trying to make the case that a software renderer
>> makin
re...
>>please speak up? There are still some people on the bitbucket we haven't
>>added to the github. That's the first step (I will try and find everyone,
>>but please send me your nickname on there if I haven't already found
>> you?).
>>
gt; On 21 March 2017 at 12:27, Leif Theden 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 let it go, since my comments are
&g
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 wrote:
> At this rate, we can expect
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
maintain
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
> wrote:
>
>> Good points I
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
at is available. 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 wrote:
> For those interested, here is the SDL2 migration guide. Pygame is
> combination of SDL 1.2 wrapper code (surf
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
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
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. Underst
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 2017 6:04 p.m., "
roject
> built upon it, then that's a tight coupling.
>
> On Sun, 19 Mar 2017, 15:47 Leif Theden, wrote:
>
> I don't follow your idea about mistakes in Kivy. It's not a tight
> coupling, it supports several backends and runs on many platforms, from PC
> to Rpi. I l
tightly coupling 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 Le
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
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!
>
>
>
>
> On Mon, M
+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 pointed out, Flatpak is
+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?
>
>
> https://github.c
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
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
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:
> Excellent piece of software
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
>
> Thanks for the re
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
>
>
, whatever.
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 wrote:
> Lol, daniel, I'm doing that right now.
>
> On Mon, Mar 14, 2016 at
Lol, daniel, I'm doing that right now.
On Mon, Mar 14, 2016 at 8:15 PM, Daniel Foerster
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 benchmark, but your e
he C functions I used:
> 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
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 to
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 colorkey, but
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
wrote:
> Leif Theden wrote:
>
>> The fast_blit
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.
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,
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
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 on Bitbucket since 2
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
wrote:
> It's good to see all this interest in Pygame after all these years of
> dormancy
They
>> would be fine as an op on #pygame.
>>
>> -- Devin
>>
>> On Fri, Jan 9, 2015 at 4:16 PM, Leif Theden
>> wrote:
>>
>>> Greetings,
>>>
>>> I am a regular lurker of #pygame on freenode, and as of late there have
>>> b
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 prece
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 s
love it if that worked for Linux, Mac, and Windows
> across the major Pygame distributions.
>
> Paul Vincent Craven
>
> On Fri, Oct 3, 2014 at 1:53 PM, Leif Theden wrote:
>
>> On ven, 2014-10-03 at 12:24 +0530, diliup gabadamudalige wrote:
>> > Why can't all
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 *fe
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
not take this personally but
> would leave it outside Pygame package.
>
> Cheers
> Bart
>
> On Tue, Sep 30, 2014 at 7:17 AM, diliup gabadamudalige
> wrote:
>
>> This is great! There should be more people like you.
>> I sincerely hope that the maintainers
#x27;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
> wrote:
>
>> Any specific reason for targeting python 2.4?... It&
MX 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
>
>
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
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
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 wrote:
> I use MacVim for small projects and occasionally Eclipse+pydev for others.
>
>
> On Wed, Aug 17, 2011 at 1:38 PM, Sean Wolfe wrote:
>
>> Looks lik
I use MacVim for small projects and occasionally Eclipse+pydev for others.
On Wed, Aug 17, 2011 at 1:38 PM, Sean Wolfe 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 at 3:35 PM, Jake
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).
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 wrote:
> I put some thou
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 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 are bad, what is
71 matches
Mail list logo