Re: [pygame] A quick 1.9.3 release

[René Dudfield]

I think we should rotate who does the release... so more people can get the
hang of it, and so we can better document it as we go.


Any volunteers to be the next release manager? We can guide whoever it is
through the processes (and document the bits that aren't documented)



Things for the next release I've seen so far...


FIXED - source tar ball.

https://bitbucket.org/pygame/pygame/issues/319/missing-versionpyin-in-source-tarball
- release notes
release summary, and updating WHATSNEW, posting news on the website
blog, twitter, reddit
- document build system
All the new stuff with travisci etc needs a document for them.

(These two probably shouldn't stop a release.)
- macOS/OSX issues

https://bitbucket.org/pygame/pygame/issues/320/wont-start-on-mac-os-x-10122-on-python-352
32bit support needed again
- python 3.6 testing, releases

https://bitbucket.org/pygame/pygame/issues/321/test-on-and-make-packages-for-python-36The
source tar ball needs to go

The source tar ball should be put Into the /ftp/ folder on the web, since
some of the distros look there for updates.






On Sun, Dec 25, 2016 at 6:29 PM, DiliupG  wrote:

> thanks rene! Merry Christmas! :)
>
> On Sun, Dec 25, 2016 at 3:35 PM, Thomas Kluyver  wrote:
>
>> Welcome back, René! +1 to doing a 1.9.3 release soon. Do you see how to
>> get wheels for the various platforms? I'm happy to help build them again,
>> but it won't be today.
>>
>> Have a good Christmas, everyone!
>>
>> Thomas
>>
>> On 24 Dec 2016 11:43 p.m., "René Dudfield"  wrote:
>>
>>> Hello,
>>>
>>> we need to do a quick 1.9.3 release because of the source tar ball being
>>> broken for 1.9.2. I don't think this should wait for other issues like
>>> python 3.6 updates or such.
>>>
>>> Sound like a plan?
>>>
>>
>
>
> --
> Kalasuri Diliup Gabadamudalige
>
> https://dahamgatalu.wordpress.com/
> http://soft.diliupg.com/
> http://www.diliupg.com
>
> 
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
> 
> **
>
>

Re: [pygame] pygame.pixelcopy.array_to_surface(Dest, Src) not working

[Mikhail V]

On 25 December 2016 at 05:10, Ian Mallett  wrote:

>
> Even if I'll write commercial arcade game, it would not suffer
>> much from being 8 bit color. Most of the the time it is not
>> about smooth gradients, it is about action and fun.
>>
>
> ​What I mean is, you can have an "8-bit" game emulated using 24-bit
> graphics. You just only use 256 (or fewer) colors instead of the whole
> 16777216. Once again, this is more performant, both in software (SDL,
> PyGame) and in hardware (GL, Vulkan).
>

Sure. the question is however how the data is initially generated.
E.g. if I visualize numeric data, I can transform the palette, or
switch between palette pages. So it is an elegant model
for many cases, one cannot just ignore it.
It is all very easy to implement in numpy, but I just wonder if one could
benefit from hardware acceleraton for color mapping.


> ​
>
>> > The copy buffer trick you're using looks a little suspect to me.
>>
>> But since there is no other method which is comliant with numpy order,
>> and as I see now, it works as fast as pixelcopy.
>> Look what I mean, if I use get_buffer() and then I simply copy a
>> memory chunk from one place to another(?), it works and the result
>> shows up correctly. So one numpy *row* is mapped to one image *row*
>> on the screen.
>>
>> > In particular, if the internal layouts differ at all (for example, if
>> the NumPy
>> > array is contiguous, and the SDL surface has row padding, both of which
>> are likely)
>> > then the copy will fail (fatally crash) in some cases. I don't know
>> whether PyGame
>> > is smart enough to anticipate that. Odd width/height surfaces,
>> > and especially truecolor surfaces, would be a reassuring test.
>>
>> Yes there are a lot of alignment nuances here. As as understand
>> GPU surface must be memory aligned, so odd shapes must be padded
>> into aligned rectangels. Especially 24 bit formats makes it
>> even harder to convert.
>>
>
> ​It's not alignment so much (IIRC SDL uses malloc on uint8, so it's
> byte-aligned) as row stride. If the row size doesn't work out to a nice
> number, then SDL will insert padding bytes. So copying from a contiguous
> array might create weird striated patterns, while copying from a surface
> could actually segfault the underlying NumPy backend. So it's not just
> inelegant--it's *unsafe*.
>
> Once again, I don't know if PyGame is smart enough to detect this and
> handle it *in the buffer API* (and if it *did* handle it, it would
> require an allocation+copy, which would make it slow), so I would err on
> the side of caution.
>

I have tried now: buffer write causes error if the whole array bytesize is
bigger than surface buffer:
> ValueError: 'buffer' object length is too large

So it is probably not so dangerous and if use correct shape and know how
what you
are doing, nothing bad should happen.  As for padded row length, well one
would just use arrays of specific shapes according to surface format.



>
> ​On Sat, Dec 24, 2016 at 5:12 PM, Mikhail V  wrote:
>
>> Probably there is more criterias here that I am not aware of
>> and objective arguments to prefer "FORTRAN" order, apart
>> from having more traditional [x,y] notation?
>>
> ​The argument I think comes from building/slicing matrices out of (column)
> vectors. You see this a lot in numerical work. If the row is of pointers,
> you can build sparse systems that reference underlying vector without doing
> any copying (you can do this with row data instead, but then you need row
> vectors, and that would be morally wrong). This is important since building
> sparse systems can be very slow if you're not careful.
>
> I still avoid FORTRAN order because it's not mathy. E.g., the matrix
> element "a_{0,2}" should be accessed as "a[0][2]". For an objective
> argument, I'll note that graphics hardware--in particular VGA/VBE hardware,
> which influenced latter standards, e.g. HDMI--is row-major, top-to-bottom
> raster order. This has been hugely influential, and is more-or-less
> expected today by graphics programmers. It explains everything from most
> windowing systems today having GUI controls at the top and left, to why GL
> takes padded scanlines as texture input.
>
> One way or another, at this point, changing the order in PyGame is
> probably a bad idea (backwards compatibility and suchlike). At the very
> least, it would needs to be deferred to a major update with breaking API
> changes.
>

So you kind of agree, that surfarray/pixelcopy should better deal with C
order?
I am curious, if it is worth proposing adding methods which do so.
I agree, one should not touch the existing API.

Now I have tested the performance one more time, namely
comparing 3 variants to copy data from array to surface:
1. buf = Dest.get_buffer()
buf.write(Src.tostring(), 0)
2. pygame.pixelcopy.array_to_surface(Dest, Src)
3. pygame.pixelcopy.array_to_surface(Dest, Src.T)

And it turned out that I was wrong about 

Re: [pygame] A quick 1.9.3 release

[DiliupG]

thanks rene! Merry Christmas! :)

On Sun, Dec 25, 2016 at 3:35 PM, Thomas Kluyver  wrote:

> Welcome back, René! +1 to doing a 1.9.3 release soon. Do you see how to
> get wheels for the various platforms? I'm happy to help build them again,
> but it won't be today.
>
> Have a good Christmas, everyone!
>
> Thomas
>
> On 24 Dec 2016 11:43 p.m., "René Dudfield"  wrote:
>
>> Hello,
>>
>> we need to do a quick 1.9.3 release because of the source tar ball being
>> broken for 1.9.2. I don't think this should wait for other issues like
>> python 3.6 updates or such.
>>
>> Sound like a plan?
>>
>


-- 
Kalasuri Diliup Gabadamudalige

https://dahamgatalu.wordpress.com/
http://soft.diliupg.com/
http://www.diliupg.com

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**

Re: [pygame] New pygame.org website

[Paul Vincent Craven]

Could you add 'pvcraven' as well?

I messed around with Nikola. I can recreate their main documentation site,
but I'm not super-impressed with the tool. It looks like it would require
more work to set up our website an sync with GitHub pages rather than less
work than to just skip it and raw-code some html pages. I'd be willing to
work with it, but I don't think I'm willing to sink the time into setting
it up myself.

However, I like the design of their landing page:

https://getnikola.com/

I know it is bootstrappy, but it isn't hard to find the main things a
person would want to do.

Paul Vincent Craven

On Sat, Dec 24, 2016 at 4:00 AM, Thomas Kluyver  wrote:

> I have created an org called pygame-org, and invited everyone who has sent
> me their username (if I've missed someone, please let me know).
>
> https://github.com/pygame-org
>
> I'm not going to be looking at it much for a couple of weeks, but feel
> free to start working things out.
>
> On 24 December 2016 at 00:20, Radomir Dopieralski 
> wrote:
>
>> Note that I don't have a problem with the need to have a Github (or
>> Bitbucket) account to contribute to PyGame or its website themselves --
>> you have to use the tools that the project choose to contribute to that
>> project, and in a pinch you can always send your patches by e-mail. But
>> forcing all members of the PyGame community to become Github's
>> customers somehow feels different.
>>
>
> For all the reasons you list, I don't intend that the game feed be limited
> to games hosted on Github. I would like it to work much as it does on the
> current site: game developers supply a screenshot and a link, and can host
> their game (free or commercial) wherever they like.
>
> With the system as proposed, game developers will at first need a Github
> account to list their games on the feed. I don't think that's a problematic
> requirement, any more than needing a Bitbucket account to file a bug on
> Pygame. But we may be able to avoid even that requirement in the future
> with a submission interface that talks to Github on the user's behalf.
>
> Thanks,
> Thomas
>

Re: [pygame] New pygame.org website

[Luke Paireepinart]

Rene,
Thanks for the quick reply. Guess I don't understand why you would release
the source in bits and pieces? I'm excited to see where this website
rewrite goes, I've seen so many attempts in the past and none of them went
anywhere... Won't it be stymied by the unavailability of the source?

On Dec 24, 2016 9:31 PM, "René Dudfield"  wrote:

> Hi Luke,
>
> Yes I certainly do! It's of course necessary when I've been maintaining
> the website for the past decade. The plan continues to be to release parts
> of the source code as I go. So far there are some db migration scripts,
> which include tools to help scrub the db of private info. The screenshots
> can be exported easily as they are just a folder of files at the moment.
>
> I've been non contactable for a few weeks due to personal issues. Which I
> guess was frustrating to Thomas, which has led to this latest effort to
> make a new website.
>
>- most parts of the website can be updated (by wiki, bitbucket,
>stackoverflow, etc)
>- we need to document who has access to which admin things (there are
>a few people who have access to everything, but I guess not everyone knows
>each other, and some people go inactive some times)
>- moderation, respect and spam are issues we need to work on.
>
> Looking forward to moving forward on the new website!
>
>
> best,
>

Re: [pygame] A quick 1.9.3 release

[Thomas Kluyver]

Welcome back, René! +1 to doing a 1.9.3 release soon. Do you see how to get
wheels for the various platforms? I'm happy to help build them again, but
it won't be today.

Have a good Christmas, everyone!

Thomas

On 24 Dec 2016 11:43 p.m., "René Dudfield"  wrote:

> Hello,
>
> we need to do a quick 1.9.3 release because of the source tar ball being
> broken for 1.9.2. I don't think this should wait for other issues like
> python 3.6 updates or such.
>
> Sound like a plan?
>