On Mon, Mar 20, 2017 at 4:47 PM, Thomas Kluyver wrote:
> On 20 March 2017 at 15:13, René Dudfield wrote:
>
>> The big advantage is that it is a much smaller change than something new.
>>
>>- smaller changes reducing risk
>>- the smaller amount of resources needed to get to SDL2
>>
>> I t
In 21 March 2017 at 08:21, René Dudfield wrote:
> If people can't use SDL1 for the moment with pygame, then we will be in a
> situation where two branches are needed. Rather than that, it seems simpler
> for me with a single code base for SDL1 and SDL2.
I guess this is the core of it. To me, th
On Tuesday, March 21, 2017, Thomas Kluyver wrote:
> In 21 March 2017 at 08:21, René Dudfield > wrote:
>
>> If people can't use SDL1 for the moment with pygame, then we will be in a
>> situation where two branches are needed. Rather than that, it seems simpler
>> for me with a single code base fo
On 21 March 2017 at 10:48, René Dudfield wrote:
> It sounds like you're still not convinced though. I can make the tree
> first, and we can see what it looks like more easily. If it turns out to be
> not such a good idea afterwards we can always remove sdl1 support.
I'm not entirely convinced -
We have pygame.get_sdl_version for the SDL version number.
https://www.pygame.org/docs/ref/pygame.html#pygame.get_sdl_version
I think perhaps it's worth doing the tree, and a pre release on linux first
so more people can test their apps for compatibility. If there's too many
issues, then we might
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
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 SDL 2 to work in 3 years...all in th
On Tue, 21 Mar 2017, 12:28 Leif Theden, wrote:
>Students should be taught how textures work, where different memories
reside, and that GPUs operate differently than a CPU.
You are thinking about much more advanced students than Pygame is being
used to teach. Pygame is being taught to 9 and 10 yea
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
> not being taken serio
Leif, thanks for your emails. It could be helpful if you have a proposal,
that you put it forward.
I think you've definitely made your position, and your priorities clear
about what we should do. However, so far I don't see a clear proposal from
you with any support. Perhaps if there was one we'd
I would say that many people don't use pygame for more than simple games or
experiments, because simple graphics is largely all that it is capable of
(and remain playable). I also don't think that the situation that Ian
described is what the larger community would want, even if it is useful to
him.
I played around with pygame on top of SDL2 a long while back. In case it
helps, I thought I'd talk about the issues I had.
- Lack of support for drawing primitives. For me as an instructor,
drawing primitives are important. But SDL2 did not support drawing a 3
pixel wide diagonal line. E
Hi,
On Mon, Mar 20, 2017 at 11:55 PM, René Dudfield wrote:
> There are few people on this mailing list which have a lot of knowledge
> about GPU rendering, and Ian is definitely one of them. I think he was
> genuinely trying to be helpful. His claim isn't even controversial - GPU,
> ASIC, and
SDL2 will let you create textures from Surfaces, so you could do all your
drawing on a surface, then make a texture out if for rendering. With
Pygame's existing drawing code, you should be fine, I think. Maybe it
would be useful to build a class that uses a Surface for drawing pixel
operations, a
Ian, I read the text, and I'll just reiterate that I don't think that your
use case is what the greater community would benefit from. We agree that
option 3 is the way forward, so I'm happy we have some common ground.
On Tue, Mar 21, 2017 at 12:31 PM, Ian Mallett wrote:
> Hi,
>
> On Mon, Mar
>
>- Handling of transparent backgrounds on images. Pygame requires extra
>code for this
>- Easily scaling graphics
>- Easily rotating graphics and drawing primitives
>- Not having the graphics coordinates reversed
>- Easy 'scrolling' of games by showing only part of a large
(... just realized ... )
cvs -> svn -> hg -> git
+ bazaar for launchpad pygame ubuntu builds
All the version control systems!
(I think pygame was in the google perforce at some point too)
Hi Ian,
I think people are hung up on option 2), SDL1/SDL2 compile option,
thinking it means no SDL2 features, or no option 3), transition to SDL2
only. First, I gather René's proposal to keep Pygame development on a
single branch is not about freezing the Pygame at SDL1 only
functionality. R
18 matches
Mail list logo
