Re: [pygame] Current working version of Python and pygame
You can add python to PATH by rerunning the same installer you used to install it. There will be a "modify" choice, and in the next two pages are options to adjust the parts of python installed, and to add it to "the environment"-- the PATH. I would suggest using 3.7. 3.8 is likely to work, but at this time I do not believe 3.9 has functioning pygame wheels, and this will be a pain point for students. On Fri, Oct 23, 2020 at 4:45 PM claudio canepa wrote: > > Question 1: If someone already has installed Python but did not check > this box on, is there some simple command line magic to do whatever this > checkbox does? If so, what do I need to tell my student to do? > > With a python 3.X installed they need replace 'python' by 'py -3.X' in > the cmdline. > Examples, for a python 3.7 installation: > To invoke the interactive interpreter: >py -3.7 > To run a script: > py -3.7 myscript.py > > Another difference with unix-like OSes is that the python's Scripts > directory is not on the path, so pip (and other commands in Scripts) need a > full qualified path in the command, like > c:\python37\Scripts\pip install ... > or the alternative form > py -3.7 -m pip install .. > > I don't know if it would be better to work from a venv: > > Create venv > py -3.7 -m venv venv_path > Activate > venv_path\Scripts\activate > > After that, in that console 'python' would be the python in the venv, and > venv_path\Scripts will be in the PATH, so commands like 'pip', 'pytest', > etc would work fine. > > To deactivate the venv: >deactivate > > > Question 2: If someone does not have Python installed yet (or wants to > install a newer version), what is the most recent version of Python (Mac > and Windows) that I should ask them to install today? I understand that > there is a big effort to get the 2.0 version of Pygame out, but I want my > students to use version 1.9 for now. If they install the current version > of Python: 3.9, will they be able to use pip to install a working version > of pygame 1.9? (Last time I checked, this did not work correctly? > > python 3.8 has been tested more time; also 3.9 is not compatible with > windows7, which maybe some students have in their house. > > > On Fri, Oct 23, 2020 at 7:08 PM Irv Kalb wrote: > >> I am teaching a Python class, where I use pygame to demonstrate OOP >> concepts. I need to have my students get the proper environment to run >> Python with pygame. >> >> I use a Mac, and I have Python 3.7.3, and pygame 1.9.6 installed. >> Everything works fine for me. But I have students who either have Python >> already installed and need to install pygame, or who need to install both >> Python and pygame. >> >> I am not a Windows user, and I typically don't use the command line for >> anything other than installations. My understanding is that if you are on >> Windows, and you want to use pygame, then during the installation of >> Python, when the installation puts up dialog box about installing Python, >> you must check the checkbox at the bottom that says: >> >> Add Python 3.x to PATH >> >> Question 1: If someone already has installed Python but did not check >> this box on, is there some simple command line magic to do whatever this >> checkbox does? If so, what do I need to tell my student to do? >> >> Question 2: If someone does not have Python installed yet (or wants to >> install a newer version), what is the most recent version of Python (Mac >> and Windows) that I should ask them to install today? I understand that >> there is a big effort to get the 2.0 version of Pygame out, but I want my >> students to use version 1.9 for now. If they install the current version >> of Python: 3.9, will they be able to use pip to install a working version >> of pygame 1.9? (Last time I checked, this did not work correctly? >> >> Thanks in advance, >> >> Irv >> >> >>
Re: [pygame] OpenGL stretch of a pygame.Surface
right. Before you blit. My bad. On Mon, Aug 4, 2014 at 6:03 PM, Greg Ewing wrote: > Berlioz Silver wrote: > >> You want pixels2d, which gives you a variable which _references_ the data. >> > > Yes, sorry, I got it the wrong way round. You need to start > with a normal surface that you can blit into, and then use > pixels2d to create a numpy view of it that you can pass > directly to OpenGL. > > While the reference is still there, the surface is locked (otherwise you >> could change the data mid-blit, which would be bad). Instead, you should >> use: >> >> del (variable with pixels2d in it) >> >> right before you pass it off to GL or pygame. >> > > I think you mean *after* passing it to GL, don't you? > > -- > Greg >
Re: [pygame] OpenGL stretch of a pygame.Surface
You want pixels2d, which gives you a variable which _references_ the data. While the reference is still there, the surface is locked (otherwise you could change the data mid-blit, which would be bad). Instead, you should use: del (variable with pixels2d in it) right before you pass it off to GL or pygame. Also, how are you setting up opengl? I haven't gotten that working (hence why I've looked into surfarray). Also, if you are dropping to a reasonably moniterable framerate (~120 or so and below) you can check to see what is taking too long. Simply separate your commands with calls to time.time() and check at the end. you can print out the time required (possibly on keypress?) and it'll show you what is taking so long: firstTime = time.time() (create texture) aCheckpoint = time.time() (draw your sprites) bCheckpoint = time.time() (scale) cCheckpoint = time.time() print firstTime, aCheckpoint - firstTime, bCheckpoint - aCheckpoint - firstTime [etc] This'll give you the time used (in milliseconds) for each step of the frame. While I have my own suspicions of what is taking so long, timing it will show us for certain. On Wed, Jul 30, 2014 at 9:35 PM, VertPingouin < sylvain.bousse...@vertpingouin.fr> wrote: > Ok I now create my texture once. > > I'm having some issues with this > > > You're creating an extra copy of the texture data here. > > To avoid that, you could use surfarray to create a surface > > backed by a numpy array, do your drawing into that, and > > then pass the numpy array directly to glTexImage2D. > > As I understand it, you suggest a surface with a surfarray.pixel2d bound > to it. But I can't blit on such surface beacause it's locked. Did you > mean drawing directly in surfarray or just create and update a > surfarray.2darray which involve to do a copy of the native screen also ? > > > Thanks for all your advises everyone. > > > Le mercredi 30 juillet 2014 à 11:15 +1200, Greg Ewing a écrit : > > sylvain.boussekey wrote: > > > I managed to do it in opengl but perfs are poor. > > > > A few things to consider: > > > > > textureData = pygame.image.tostring(textureSurface, "RGBA", 1) > > > > * You're creating an extra copy of the texture data here. > > To avoid that, you could use surfarray to create a surface > > backed by a numpy array, do your drawing into that, and > > then pass the numpy array directly to glTexImage2D. > > > > > texture = glGenTextures(1) > > > glBindTexture(GL_TEXTURE_2D, texture) > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, > GL_NEAREST) > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, > GL_NEAREST) > > > > * You're creating a new OpenGL texture for each frame and > > then discarding it. Try making these calls just once > > at the beginning and re-using the texture. > > > > * You're using a non-power-of-2 texture size. Not all > > OpenGL implementations support that; yours seemingly does, > > but it might be less efficient than a power-of-2 size. > > You could try allocating the next larger power-of-2 size and > > updating the part that you use with glTexSubImage2D(). > > > > >
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
OK EVERYONE.
If someone had read the python docs, they'd have known exactly why this
occurs. The difference between the keyword operator "is" and "==" is due to
the fact that:
* some people want to compare a custom class and an integer, and if the
custom class' __ methods return the same as the integer, the want a value
of true.
AND
* some people want to know if the number they got IS EXACTLY 3 and won't do
wonky stuff when they multiply it.
Thus we have 4 operators for equality comparisons:
== (eq)
=== (is)
On Mon, Jun 23, 2014 at 8:14 AM, bw wrote:
> Try:
>
> id(a), id(b)
>
> In some cases they are different objects, and "a is b" rightly evaluates
> to False.
>
> Gumm
>
> On 6/23/2014 00:39, diliup gabadamudalige wrote:
>
> when you say a=100 and b=100 it is understood that a and b are both given
> TWO values and that both are the same is a coincidence.
> BUT if that is the case how can a is b be TRUE for small integers and a is
> b False for large integers? What logic is Python using here?
>
>
> On Mon, Jun 23, 2014 at 1:07 PM, diliup gabadamudalige
> wrote:
>
>> ok
>> look at this!
>> a = 100
>> b = 100
>> a == b
>> True
>> a is b
>> True
>> a = 1000
>> b = 1000
>> a is b
>> False
>> a == b
>> True
>>
>> what on earth is this? what is this logic?
>>
>>
>> On Mon, Jun 23, 2014 at 1:03 PM, Sam Bull wrote:
>>
>>> On lun, 2014-06-23 at 11:45 +0530, diliup gabadamudalige wrote:
>>> > I called event.clear() cause it says in the Pygame documentation that
>>> > if you leave unused events on the buffer that eventually it may fill
>>> > up and cause the program to crash.
>>>
>>> Yes, but if you are getting everything from the buffer using event.get()
>>> or whatever every frame, then it's not going to fill up, as these
>>> returned events are removed from the queue. As long as you are reading
>>> the whole buffer, say every 100ms, you're going to be fine. Otherwise,
>>> you're just throwing away the events that have arrived between the
>>> event.get() and event.clear() calls.
>>>
>>> >
>>> > if x is True:
>>> > is not correct
>>> >
>>> > if x == True
>>> > is correct?
>>>
>>> This obviously depends on what x is.
>>>
>>> So, if we write:
>>> "foo" is True
>>>
>>> We can clearly see these are not the same object. One is a string, and
>>> the other is the True object. But, if we do:
>>> "foo" == True
>>>
>>> Then, we are asking if the string evaluates to a True value, when
>>> treated as a boolean. And any non-empty string will be considered True,
>>> and so it is equal to True (but not the same object).
>>>
>>>
>>> Futhermore, what Greg was saying is that some objects can be of the same
>>> value and still not be the same object. Thus:
>>> a = 4040
>>> b = 4040
>>> a == b # True
>>> a is b # Could be False
>>>
>>> b = a # b now references the a object itself
>>> a is b # Always True
>>>
>>> This becomes more obvious if we were to use mutable types:
>>> a = [2]
>>> b = [2]
>>> # Obviously, these are two distinct objects
>>> a == b # True
>>> a is b # False
>>> # Changing one, would not change the other, as they are
>>> different
>>> # objects.
>>> a.append(3)
>>> a == b # False
>>>
>>>
>>> On an interesting sidenote, it is not even required that an object is
>>> equal to itself:
>>> a = float("NaN")
>>> a == a # False
>>>
>>
>>
>>
>> --
>> Diliup Gabadamudalige
>>
>> http://www.diliupg.com
>> http://soft.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.
>>
>> **
>>
>>
>
>
> --
> Diliup Gabadamudalige
>
> http://www.diliupg.com
> http://soft.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
