Re: [pygame] Do you support The #Python Software Foundation making a statement in support of peace?

[Ian Mallett]

Hi,

As technologists, we hold a great deal of de-facto power, and therefore I
think it is reasonable, if not morally obligatory, to be careful and
conscientious, as well as promulgating kindness and respect for human life
and our world.

Therefore, I do not oppose any "statement for peace" (even besides the very
one-sided situation with Russia/Ukraine it obviously alludes to, I think
everyone sane agrees that mechanized mass death is generally bad). However,
I do feel like a "statement" is nothing but virtue-signaling (and rather
vacuous virtue-signaling, at that).

If one truly supports peace, hand-wringy futzing about on mailing lists
will accomplish nothing; the least one could do to make their word
meaningful is to, for example, contribute to humanitarian efforts relieving
human suffering in the region. Furthermore, the tools of computer science,
together with the general privilege afforded by the technology jobs I and
most of you have, give us opportunity to make real positive change beyond
this. I hope that everyone thinking about ways to help will consider such
more-meaningful efforts.

I regret I could not comment any of this on Twitter. I have been blocked
pre-emptively from the account, and actively refused explanation as to why.

Ian

Re: [pygame] Re[2]: [pygame] Can the pygame infrastructure be used for non-graphical text-mode games?

[Ian Mallett]

On Thu, Jul 16, 2020 at 3:49 AM  wrote:

> How do i unsubscribe?
>
The same way you subscribed. See directions here:
https://www.pygame.org/wiki/info

Re: [pygame] Can the pygame infrastructure be used for non-graphical text-mode games?

[Ian Mallett]

This is a puzzling question to me since it's not clear what one expects.
Pygame is, after all, the Python wrapper around SDL—the Simple DirectMedia
Layer. In a text-based game, you don't really have media, so it's not
really clear to me what you'd expect pygame to do for you? By definition,
you wouldn't be blitting images or getting input from a graphics window,
which are the main features of pygame. Stuff like font rasterization, color
conversion, masking, etc. are handled for you in a terminal. I guess you
could use pygame to play music and sounds.

One could also write a *graphics-based* program that *looks like* a
terminal but *isn't*, and write a "text-based" game that way. Pygame would
be a good choice for this, but the broader choice of reinventing the
terminal would probably be a bad choice (for being a waste of time).

Ian

Re: [pygame] Raycasting question for pygame

[Ian Mallett]

Hi,

You probably don't want to use raycasting. Raycasting is a specific
graphics technique which is more-complicated, harder, and slower on modern
hardware, though people still use it sometimes for the aesthetics it can
produce. The two methods people mainly use today are "rasterization" and
"raytracing".

You should understand that 3D graphics programming is fairly difficult.
It's certainly doable by a complete neophyte in a semester-/year-long
project, though. I recommend using raster graphics via PyOpenGL; this is,
in fact, how I got my start in graphics. Here's some basecode that should
get you started drawing a 3D triangle:
https://geometrian.com/programming/tutorials/OpenGL%20Program%20Shell.py.txt

Ian

Re: [pygame] pygame.display.flip slow

[Ian Mallett]

Hi,

To me, these results suggest that the faster-framerate machine is running
with VSync enabled for some reason and the slower-framerate machine is
running without. Also, what I said about setting pixels on the CPU still
goes, albeit that's not the issue here.

Offhand, I would guess that the faster-framerate machine is running
Windows, which doesn't enable VSync, and the slower-framerate machine is
running something else. But I don't know.

In general, faster framerates are pointless (you can't even display them),
so one should be satisfied with ~60Hz refresh, and make the logic
independent of timestep (locking the framerate to the refresh rate is a
*good* thing; the fascination with faster framerates is due to modern video
games running <60Hz, or to gamers running >60Hz with tearing (and without
VSync).). There are platform-specific ways to disable VSync. It's not even
that hard for OpenGL contexts. But it's sortof an X-Y problem that doesn't
need solving.

Ian

Re: [pygame] pygame.display.flip slow

[Ian Mallett]

Hi,

First, there are some problems with this test code:

- The first ten framerates will be 0.0 due to what I consider a misfeature
in the way pygame reports framerate; this drags down your average. Even if
you ran at a nominal 60Hz, the highest reported framerate is going to be
54fps (wherefore, I'm somewhat confused that you say you got 60Hz on a
different machine; perhaps you were running a bit faster; e.g. I see 62Hz a
lot on certain machines).

- Averaging the framerates is a bit problematic because that is a
reciprocal measure. It is better to average the frame latencies and then
reciprocate that to get the average framerate.

- You're attempting to synchronize the framerate to 60Hz, this can cause
aliasing issues since pygame is software-backed, not graphics backed,
exactly. E.g., if your code is actually 59fps, then the fastest it can
update will be 30fps. It would be better to not include the argument to
`.tick(...)` at all.

Which brings us to the main reason:

- Setting millions of pixels is not a job for the CPU; it's a job for the
graphics card. However, pygame runs on the CPU. As you observe, larger
displays run slower. If you want good refresh-bound performance, you
probably want to make a GL context and draw with that, without disabling
VSync. This is, in fact, what glxgears does, which is why it's running at a
reasonable framerate.

Ian

Re: [pygame] pygame.event.set_grab(True) ineffective under GNOME shell

[Ian Mallett]

I don't know specifically about whether there is a way to capture this in
pygame (though I suspect not; I bet it's possible through platform-specific
APIs, though), but I would comment that even if it were possible, it would
be the Wrong Thing. This is an OS-level keypress; as you see, it exists so
that the user can switch among applications; one application ought not (and
indeed, should not be allowed to) capture this keypress.
Ian

Re: [pygame] Practice Game code ?

[Ian Mallett]

There are also many, many games of varying quality and complexity on the
pygame website itself.

Re: [pygame] Issue with Pygame + Waveshare 3.5" HDMI display

[Ian Mallett]

According to the linked issue, you say it segfaults. That should definitely
not happen; can you provide a stack trace?

Re: [pygame] How to do some action while a joystick is in motion?

[Ian Mallett]

Perhaps have your "start" and "stop" commands affect the presence/absence
of an acceleration for the camera. This way, the camera will smoothly
accelerate up to a top speed, and decelerate back down from it smoothly
when control is released. (Obviously "speed" can mean "angular speed" as
well as translational.)

Re: [pygame] Newbie performance question

[Ian Mallett]

​I think OP is confusing framerate with jitter due to lack-of-VSync.

Re: [pygame] Help? pygame for python 3.7 windows

[Ian Mallett]

​Hi,

Install seems to go okay (using amd64 version)​

On Sun, Jul 15, 2018 at 3:37 PM, René Dudfield  wrote:

> python -m pygame.tests
>

pygame 1.9.4.dev0
Hello from the pygame community. https://www.pygame.org/contribute.html
skipping pygame.tests.cdrom_test (tag 'interactive')
skipping pygame.tests.font_test (tag 'subprocess_ignore')
skipping pygame.tests.midi_test (tag 'interactive')
loading pygame.tests.base_test
loading pygame.tests.blit_test
loading pygame.tests.bufferproxy_test
loading pygame.tests.camera_test
loading pygame.tests.color_test
loading pygame.tests.compat_test
loading pygame.tests.cursors_test
loading pygame.tests.display_test
loading pygame.tests.draw_test
loading pygame.tests.event_test
loading pygame.tests.fastevent_test
loading pygame.tests.freetype_test
loading pygame.tests.ftfont_test
loading pygame.tests.gfxdraw_test
loading pygame.tests.image__save_gl_surface_test
loading pygame.tests.image_test
loading pygame.tests.imageext_test
loading pygame.tests.joystick_test
loading pygame.tests.key_test
loading pygame.tests.mask_test
loading pygame.tests.math_test
loading pygame.tests.mixer_music_test
loading pygame.tests.mixer_test
loading pygame.tests.mouse_test
loading pygame.tests.overlay_test
loading pygame.tests.pixelarray_test
loading pygame.tests.pixelcopy_test
loading pygame.tests.rect_test
loading pygame.tests.rwobject_test
loading pygame.tests.scrap_test
loading pygame.tests.sndarray_test
loading pygame.tests.sprite_test
loading pygame.tests.surface_test
loading pygame.tests.surfarray_test
loading pygame.tests.surflock_test
loading pygame.tests.sysfont_test
loading pygame.tests.threads_test
loading pygame.tests.time_test
loading pygame.tests.transform_test





..E.



==
ERROR: test_scrap_put_text (pygame.tests.scrap_test.ScrapModuleTest)
--
Traceback (most recent call last):
  File "C:\dev\Python37\lib\site-packages\pygame\tests\scrap_test.py", line
133,
 in test_scrap_put_text
scrap.put (pygame.SCRAP_TEXT, as_bytes("Another String"))
pygame.error: content could not be placed in clipboard.

--
Ran 712 tests in 58.610s

FAILED (errors=1)


> python -m pygame.examples.aliens
>

​Seems to work.​


> python -m pygame.examples. ...
>

​Didn't find anything amiss.​


> Also, if there is a pygame app that you know, then seeing if that works as
> before would be a good test.
>

​I ran a few of my games. While they seem to work, the output:

pygame 1.9.4.dev0
Hello from the pygame community. https://www.pygame.org/contribute.html

Seems to be hardcoded. This should be removed.

Ian

Re: [pygame] Help? pygame for python 3.7 windows

[Ian Mallett]

​Anything in-particular that needs testing?

Re: [pygame] Help? Alpha changes (regressions?) in 1.9.3 vs 1.9.2?

[Ian Mallett]

​Hi,

As to finding the commit, can't one find the place where the behavior is
implemented, and then check the logs for that line/file to see which commit
introduced it? A trivial search of my email for "SRCALPHA" produces the
thread "trouble w/ SRCALPHA in 1.9.2-cp27
", where this
same issue was raised (ref. issue #340

on Bitbucket, by presumably-same user even). At the time no one stepped
forward to address it significantly.

As to whether the behavior is good, I contend it is bad. SRCALPHA and
per-surface alpha are *very* different, and confusing them is a classic
newbie mistake. Now, I don't use the flags myself, and even presuming
pygame uses them internally, I use per-surface alpha rarely at-most, so it
doesn't really affect me. But it is semantically incorrect.

Ian

Re: [pygame] Can't install pygame on Windows. Please help!

[Ian Mallett]

On Sun, Jul 1, 2018 at 11:18 AM, John Salerno  wrote:

> Hi all. I just tried installing pygame on my Windows system using the
> following on the command line:
>
> python -m pip install --user pygame
>
> but it seems to have failed.
>

​I can reproduce this. I suspect it's a bug; Python 3.7.0 came out just
four days ago. Perhaps try Python 3.6 for now?​

Re: [pygame] Iterate over list and delete

[Ian Mallett]

On Sun, May 20, 2018 at 11:20 PM, Daniel Foerster 
wrote:

> I would guess that a significant amount of the gain is that he doesn't
> have to len() the list every iteration, plus the item unpacking occurs in C.
>
​`len(...)` should be constant-time (stored with array), but indeed caching
it in a variable seems to help significantly.​ I think the fact that more
of the algorithm occurs in C is the main driver, though. It also explains
why the list comprehension is fastest.

It's also worth noting that the performance of all these algorithms is
milliseconds or tens of milliseconds, even for thousands of elements. This
means that which one is chosen probably doesn't matter—but it also means
that the profiling is necessarily more-approximate. I'd hesitate to read
too much into results on smaller element counts, even if they're fairly
repeatable.


> I don't know how much JIT would affect anything unless you ran the tests
> in PyPy.
>
​This was incorrect terminology on my part. I meant the interpreter, as my
tests at least were in CPython. I was thinking of the optimizations that
are done in the translation to bytecode, more than the fact that this is
interpreted bytecode instead of executed machine code.

Ian

Re: [pygame] Iterate over list and delete

[Ian Mallett]

On Sun, May 20, 2018 at 9:25 PM, Daniel Foerster 
wrote:

> The relevance of N exponent versus the discarded coefficients depends on
> how big N may be. With the likely sizes of N in a Pygame class, the
> difference between the algorithms seems probably negligible. A quick test
> with 20% deletion shows that your algorithm becomes more efficient around
> N=7000, but either can handle well over N=2 in 10ms. Of course, a list
> comprehension can handle almost 100,000 in the same 10ms so the point is
> all rather moot in real-world code ;)
>

​These results were surprising to me, so I coded up a test (see attached!).

I measure the breakeven point at a similar level, 5500 elements. MrGumm's
version is functionally equivalent to mine, but seems to run much faster
than either of ours (mine and Daniel's)—almost as fast as the list
comprehension, which I confirm to be fastest. My guess is that my `while`
loop (instead of `for` over the elements explicitly) is confusing the
Python JIT into not optimizing somehow.

Also, this discussion on StackOverflow is relevant

.

Ian​
import timeit


def listcomp_remove(my_list, delete_predicate):
my_list[:] = [item for item in my_list if not delete_predicate(item)]
def daniel_remove(my_list, delete_predicate):
index = 0
while index < len(my_list):
if delete_predicate(my_list[index]):
del my_list[index]
else:
index += 1
def ian_remove(my_list, delete_predicate):
i_read  = 0
i_write = 0
while i_read < len(my_list):
item = my_list[i_read]
i_read += 1
if delete_predicate(item):
pass
else:
my_list[i_write] = item
i_write += 1
while len(my_list) > i_write:
my_list.pop()
def mrgumm_remove(my_list, delete_predicate):
i_write = 0
for item in my_list:
if not delete_predicate(item):
my_list[i_write] = item
i_write += 1
del my_list[i_write:len(my_list)]
def tyler_remove(my_list, delete_predicate):
for val in reversed(my_list):
if delete_predicate(val):
my_list.remove(val)

def delete_third(item):
return item%3 == 0
def delete_fifth(item):
return item%5 == 0

def run_test_10(remove_alg, delete_predicate):
my_list = list(range(0,10,1))
print("Before: "+str(my_list))
remove_alg(my_list,delete_predicate)
print("After:  "+str(my_list))
run_test_10(listcomp_remove,delete_fifth)
run_test_10(daniel_remove,  delete_fifth)
run_test_10(ian_remove, delete_fifth)
run_test_10(mrgumm_remove,  delete_fifth)
run_test_10(tyler_remove,   delete_fifth)

def run_test_n(remove_alg, delete_predicate, n):
my_list = None
def setup_list():
nonlocal my_list
my_list = list(range(0,n,1))
def remove():
nonlocal my_list
remove_alg(my_list,delete_predicate)
stats = timeit.repeat(stmt=remove,setup=setup_list, repeat=50,number=1)
print(sum(stats)/len(stats))
run_test_n(listcomp_remove,delete_fifth, 5500)
run_test_n(daniel_remove,  delete_fifth, 5500)
run_test_n(ian_remove, delete_fifth, 5500)
run_test_n(mrgumm_remove,  delete_fifth, 5500)
run_test_n(tyler_remove,   delete_fifth, 5500)

Re: [pygame] Iterate over list and delete

[Ian Mallett]

On Sun, May 20, 2018 at 8:35 PM, Daniel Foerster 
wrote:

> The third, and probably most convenient based on where you seem to be at
> in the curriculum, is to do something like Ian suggested. I think there's a
> simpler way to do it with similar performance though I've not benched to
> find out; I don't think autoresizing should be too much of a concern,
> especially early in a class like this.
>
> index = 0
> # Could also use a for loop to avoid repeatedly len()ing:
> ## for _discarded in range(len(my_list)):
>
> while index < len(my_list):
> if need_to_delete(my_list[index]):
> del my_list[index]
> # We don't need to update the index after deleting because now the
> next
> # item is sitting in the current slot
> else:
> index += 1
>
>
​The `list` type is an array, so the `del` operation is implicitly copying
the remaining elements of the list forward. This will be O(n^2) operations
over the whole algorithm. My example copies each element at most once, so
there are only O(n) operations total. This version may be more clear,
though.

Ian​

Re: [pygame] Iterate over list and delete

[Ian Mallett]

On Sun, May 20, 2018 at 5:55 PM, Irv Kalb  wrote:

> Is there a way to do that without the list comprehension? I'm building
> this as part of a class, and I will not have talked about list
> comprehensions up until that point.
>

​A list comprehension is the clearest and most-pythonic way to do this (it
would have been my suggestion if Daniel hadn't beat me to it).

You could modify and unroll the initial algorithm you started with to make
it work. It's a lot less pretty, but it's clear algorithmically (which is
the point pedagogically). It also has the advantage of being the most
efficient algorithm for deletion in an array (no reallocation should be
necessary, and copying is minimized).

i_read  = 0
i_write = 0
while i_read < len(myList):
item = myList[i_read]
i_read += 1
if needsToBeDeleted(item):
pass
else:
myList[i_write] = item
i_write += 1
while len(myList) > i_write:
myList.pop()

Ian​

[pygame] Re: `pygame.draw.line(...)` `width`

[Ian Mallett]

​By the way, a solution doesn't even need to use any trigonometry, because
a squared-off miter joint is by-definition orthogonal to the line. Here's
some proof-of-concept code:

def rndint(x): return int(round(x))
def cappedline(surface, color, p0,p1, width=1, rounded=True):
radius = width * 0.5
delta = ( p1[0]-p0[0], p1[1]-p0[1] )
orthog = [ delta[1], -delta[0] ]
scale = radius / (orthog[0]*orthog[0] + orthog[1]*orthog[1])**0.5
orthog[0]*=scale; orthog[1]*=scale
points = [
( p0[0]-orthog[0], p0[1]-orthog[1] ),
( p0[0]+orthog[0], p0[1]+orthog[1] ),
( p1[0]+orthog[0], p1[1]+orthog[1] ),
( p1[0]-orthog[0], p1[1]-orthog[1] )
]
pygame.draw.polygon(surface, color, points)
if rounded:
#Could have added these to the polygon points instead, but then
we'd have had to choose a subdivision accuracy.
pygame.draw.circle(surface, color, (rndint(p0[0]),rndint(p0[1])),
rndint(radius))
pygame.draw.circle(surface, color, (rndint(p1[0]),rndint(p1[1])),
rndint(radius))
pygame.draw.cappedline = cappedline

Note that this also supports rounded corners by drawing circles on the
ends, although this is rather limited by the (poor) accuracy of the circle
drawing routine, and doesn't look fabulous at small widths.

Ian

[pygame] `pygame.draw.line(...)` `width`

[Ian Mallett]

Hi,

I don't remember noticing this behavior before, but it seems that the
lines' widths are chosen so that the ends, which are also axis-aligned, are
the given width. Thus, the lines can be up to about 29% thinner than one
would expect.

Here's an example image; note esp. how the diagonal line appears too thin:

The code that generates this is attached.

This doesn't seem very useful behavior, and it make it hard to e.g. add
endcaps yourself. At the very least, it's *weird* and the documentation
doesn't lead one to expect it. Having squared-off miter joints, and the
line's thickness refer to the thickness of the actual line, would be a vast
improvement.

Ian
import pygame
from pygame.locals import *
pygame.init()

screen_size = [600,600]
surface = pygame.display.set_mode(screen_size)

def cappedline(surface, color, p0,p1, width=1):
pygame.draw.line(surface, color, p0,p1, width)

def get_input():
for event in pygame.event.get():
if   event.type == QUIT: return False
elif event.type == KEYDOWN:
if   event.key == K_ESCAPE: return False
elif event.key == K_s: pygame.image.save(surface,"test.png")
return True

def draw():
surface.fill((0,0,0))

width = 50
pygame.draw.line(surface, (255,0,0), (300,100),(500,100), width)
pygame.draw.line(surface, (255,0,0), (200,100),(500,300), width)
pygame.draw.line(surface, (255,0,0), (200,200),(500,500), width)
pygame.draw.line(surface, (255,0,0), (100,200),(300,500), width)
pygame.draw.line(surface, (255,0,0), (100,300),(100,500), width)

pygame.display.flip()

def main():
while True:
if not get_input(): break
draw()
pygame.quit()
if __name__ == "__main__": main()

Re: [pygame] Error pygame with timidity.cfg

[Ian Mallett]

​Also, and not to put too fine a point on it, but (1) trying obvious things
and (2) telling us what you tried are just *foundational* netiquette when
asking for help.

For example, the error says "timidity.cfg: line 30: syntax error". Did you
look in timidity.cfg for a syntax error on line 30?

Ian

Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math

[Ian Mallett]

On Thu, Mar 1, 2018 at 1:43 AM, Greg Ewing 
wrote:

> No, no, no. Z points up in real physics!


Oh, and I expect "j" is the imaginary unit, "Σ"s can be omitted, gravity is
exactly 10 m/s, without the square, and anyway one can drop units whenever
one feels like it?
( Must. Resist. Temptation. To. Rant. . . )

Re: [pygame] Re: removing 'experimental' notice from pygame.math

[Ian Mallett]

​(Skims discussion)

For e.g. `abs(Vector2(2,-1).elementwise())`, my (C++) library instead
handles this as `abs(Vec2(2,-1))`, returning another `Vec2`. In C++, if you
weren't expecting that, you get a compile error on whatever happens next,
whereas in Python you'll get a `TypeError`, so it's well-defined.

If you want the vector's length, I use a function, but perhaps it's more
pythonic to use a method: `Vec2(2,-1).getLength()`, or
`Vec2(2,-1).getLengthSq()`.

If your vector represents a complex number and you're wondering why
`abs(...)` shouldn't return a complex modulus, then I ask why you aren't
using the built-in `complex`, which is designed for this.

Ian

Re: [pygame] Last Frame of Animation/Game Loop Problem

[Ian Mallett]

​Hi,


​
On Tue, Jan 16, 2018 at 10:37 AM, dejohnso  wrote:

> I have having trouble with a basic game/animation loop.
>
> It seems like the final frame doesn't show up until after the game loop is
> done and pygame.quit() is called. An example is below - if it is run, I see
> the "Out of loop" output, then a pause, then the final frame, then the
> final pause.
>

​Great self-contained example!

On Win 7 x86-64, Python 3.5.1, PyGame 1.9.2a0, I see 5 frames of animation,
with the last frame being presented an instant before "Out of loop" is
printed. This is the behavior I would expect, but it sounds like your last
frame comes 1s after printing?


> Am I doing something wrong?


​Everything here looks good to me. I would prefer the drawing code
(including display update) all in one place (idiomatically, at the end of
the frame). I also prefer `pygame.display.flip()`. Also, in this case,
`time.sleep(...)` instead of `.tick(...)` (due to the low framerate, see
below). But these are all suggestions; nothing as-is looks wrong.​


> Is this specific to my setup/machine?
>

​Since I can't reproduce it myself, this seems likely. What is your
setup/machine?

I have a few vague suspicions. If the input polling rate is very low, some
windowing systems will conclude the process is hung, and possibly draw some
kind of grayed-out overlay on the window, which can make it drop a frame or
two. Also, `.tick(...)` does some internal timekeeping history
measurements, meaning that the framerate provided is rather inaccurate,
especially on startup. That's why I'd prefer `time.sleep(...)` (OTOH, *slow*ing
the framerate should work just fine, so . . .).


> import pygame, sys
>
> def main():
> pygame.init()
> screen = pygame.display.set_mode((600, 400))
>
> frame_count = 0
>
> # The clock helps us manage the frames per second of the animation
> clock = pygame.time.Clock()
>
> square = pygame.Rect((0,100),(50,50))
> done = False
> while not done:
> # Erase the screen
> screen.fill((50, 50, 50))
> # Process events
> for event in pygame.event.get():
> if event.type == pygame.QUIT:
> done = True
> # The main snake code
> square.move_ip((50,0))
> pygame.draw.rect(screen, (200,50,50), square)
> print(square)
> frame_count += 1
> if frame_count >= 5:
> done = True
> print(done)
> # set fps
> clock.tick(1)
> # Bring drawn changes to the front
> pygame.display.update()
>
> print("Out of loop")
> pygame.time.delay(2000)
> # This also works to bring up the last frame.
> #pygame.event.clear()
> #pygame.event.wait()
> pygame.quit()
> print("After quit")
> pygame.time.delay(2000)
> sys.exit()
>
> main()
>
>
​(Waves from SoC)

Ian​

Re: [pygame] Building paths & pygame.image.load documentation

[Ian Mallett]

On Nov 25, 2017 16:53, "Irv Kalb"  wrote:

Thanks Ian.

I'm not worried about the os module being available.  I use pygame in
classes that I teach, and it seems like its just one more thing for
students  to understand and remember.  I teach mostly art students, very
few computer science students.  I've used relative path like this:

pygame.image.load('images/ball.png')

for a long time and they had always worked for me.  Sounds like you have
seen this too.  Unless I hear otherwise, I will use this approach as it is
easier for students to comprehend.


Understood and agreed. I generally recommend relative, forward-slashed
paths in every case, until and if some Windows utility decides to complain,
which they usually don't anymore. The main holdout is the shell, which
Windows continues, I assume just to be pissy. Fair enough; the UNIX
equivalent, Bash, deliberately pretends to uncomprehend "\r".

I never use hardcoded absolute paths, since a relative path or a
user-specified path is always (can't think of counterexample, and never ran
into one) better.

As an aside ... I did development in another language/environment (Adobe
Director/Lingo) for many many years.  Whenever we needed to specify a path,
we had to build the full path including the folder delimiter character.  I
started working in that environment in the days of Mac OS9.  At that time,
the Mac folder separator character was the ":" colon character.  I didn't
realize it but the character on a Mac is now the "/", same as the Unix
character - probably changed when OS X came out.  I think either one will
work on a Mac.


Hmm I didn't know this, never really viewing Macs as suitable for
development. It's good it has converged to the forward-slash convention
though.

When I started using Python, I thought it was very clever that I can use
just the "/" character in Python, and Python seems to do whatever
translation it needs to do to make the path work on the target system.


You'll see the same behavior in C, so either the standard library does the
appropriate conversion before the ultimate syscall, or the syscall itself
understands forward-slashes.

Thanks,

Irv


Ian

Re: [pygame] Building paths & pygame.image.load documentation

[Ian Mallett]

As far as I know, the os.path version does a string conversion to the
platform-preferred way of specifying paths. So e.g. on Windows it replaces
"/" with "\".

This is intended for compatibility with very Windows-focused apps that
(deliberately?) don't understand "/". However, for the system-level
application of loading files, "/" is a de-facto standard that all systems
recognize.

The upshot is that either one will work. I personally use "/" because "\"
was just not a good idea, and Windows ought to give up already--but it
would be slightly more correct semantically to use the os.path conversion.

Regarding the extra dependency, os is built into every distro, so I
wouldn't worry about it.

On Nov 25, 2017 12:01, "Irv Kalb"  wrote:

> Here's my second question about pygame.image.load.  Actually it's a
> question about specifying paths in pygame.
>
> In my classes, I talk about the concept of a path for loading images,
> sounds, etc.  I suggest that students create an "images" folder and if
> needed, a "sounds" folder in their project folder.   I explain the
> difference between absolute and relative paths, and I point out the reasons
> why relative paths are generally easier to use for loading such assets.
>
> I then explain that with this type of structure, that building a path to
> each asset is a matter of specifying the folder name (and optional
> subfolder name, etc.) and the file name.  I talk about how the different
> operating systems use different characters as the folder separator
> character.  But then I point out how Python solves this issue by allowing
> programmers to use the "/" character as the folder separator character -
> and how Python maps that character into the appropriate character for the
> operating system on which the program is running.  I give an example that I
> create my demo programs on a Mac, then bring them into class and run them
> on a Windows machine.  As long as I create paths like:
>
> ball = pygame.image.load('images/ball.png')
>
> This line will work on Macs and Windows (and I assume on Linux/Unix too).
>
> However, when I look at the documentation for pygame.image.load as an
> example, the documentation says:
>
>
> You should use os.path.join() for compatibility.
>
> eg. asurf = pygame.image.load(os.path.join('data', 'bla.png'))
>
>
>
> My question is: Is there any reason to do it this way?  This requires
> bringing an additional package (the os package), an extra call (to
> os.path.join), and it would require much more of an explanation of what
> os.path.join does.
>
> I have also seen many other books/articles/other people's code where they
> do the same thing by building an absolute path on-the-fly.  This all seems
> like a great deal of overkill.
>
> Any reason NOT to use:
>
> ball = pygame.image.load('images/ball.png')
>
> Irv
>
>
>
>
>

Re: [pygame] Delay in MOUSEBUTTONUP after application start

[Ian Mallett]

​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to
print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over
SDL's—so for platform-specific issues in PyGame it's commonly the
underlying SDL that's at fault. Notwithstanding that SDL is fairly
well-tested, but Mac tends to be a lower priority for testing, on account
of Apple making game development on OS X difficult in a variety of ways. My
*guess* is that it's a minor hiccup in older SDL on MacOS that no one ever
noticed before, additionally because MOUSEBUTTONUP is often ignored—in
which case you're most likely to get closure from the SDL community, unless
someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving
better on startup?

Ian

Re: [pygame] Is there any reason to call sys.exit() to close a pygame program?

[Ian Mallett]

On Sun, Aug 13, 2017 at 2:29 AM, Sam Bull  wrote:

> On sab, 2017-08-12 at 18:23 +, skorpio wrote:
> > I usually quit pygame by breaking out of the main loop and calling
> > pygame.quit() followed by sys.exit(), but I can't remember anymore
> > where I learned to use sys.exit and why it should be used.
>

​For a while (Python 2.3, 2.4) I vaguely remember `sys.exit(...)` was also
useful for killing dangling PyGame windows that would persist after
exceptional program termination when debugging in IDLE (i.e., put your
whole program in `try`/`except`, and put `sys.exit(...)` in the `except`).
This may have been where the original suggestion to use it comes from.
However, that usage no longer seems to be required.
​


> If you need to use an exit function, then I've found using the built-in
> exit() function gives an error if you use pyinstaller to create a
> frozen binary. That's the only reason I try to use sys.exit(). I've not
> had any problems just allowing the execution to reach the end of the
> file and completing naturally though.


​AFAIK the only current advantage of using one of the exit calls in Python
is to be able to supply an exit code to the parent process. In C++, I
typically return the code from `main(int,char*[])` instead because it's
clearer OO encapsulation, but this isn't possible in Python.

Ian​

Re: [pygame] How to prevent mouse initialization in Pygame

[Ian Mallett]

On Fri, Jun 30, 2017 at 12:28 PM, Роман Мещеряков <
roman.mescherya...@gmail.com> wrote:

> In my Python application running on Raspberry Pi under Raspbian I use
> Pygame to display some software-generated images via framebuffer. I don’t
> need any input from mouse, keyboard or any other devices, all I need is a
> convenient way of using framebuffer.
>
>
>
> I initialize Pygame in the following way:
>


> Problem #1: I have mouse pointer at the top left corner of Pygame-drawn
> images. I want mouse pointer to be hidden.
>
> I know that I can disable mouse pointer using pygame.mouse.set_visible,
> but here comes
>
> Problem #2: I have to run my application with sudo in order for pygame to
> not raise “
> ​​
> unable to open a console terminal” exception. But I want to run my
> application without root rights, because this increases my application’s
> security.
>
> There are some posts on forums that recommend setting SDL_NOMOUSE=1
> environment variable before initializing pygame which should skip mouse
> initialization and maybe make it possible to get rid of sudo, but this
> doesn’t work for me: I still need to use sudo and mouse pointer is still
> there.
>
> If this makes any difference, I have no mouse or keyboard attached to the
> Raspberry Pi, I connect to it using SSH.
>
> I use
>
> Pygame version 1.9.2~pre~r3348-2~bpo8+rpi1
>
> libsdl-image1.2 version 1.2.12-5+b1
>
> libsdl1.2debian version 1.2.15-10+rpi1
>
>
>
> Does SDL_NOMOUSE work for anyone using recent Pygame versions?
>
> Is it possible to skip mouse initialization in Pygame?
>
> P.S. This question was originally posted on StackExchange
> ,
> but it seems I chose the wrong section. For this reason or another, I
> haven’t got any straight answer yet, so I write here and hope for the best
> :)
>
​Hi,

It's not exactly clear to me what you're trying to do. It sounds like:

*I want to SSH into a RPI, open a fullscreen window on it, and disable user
input on that window entirely. However, the mouse cursor still shows on
that window, and I can't disable it with `mouse.set_visible(...)` because
that makes my program require root privileges.*

If this is so, your code and attempts are more-or-less what I would have
tried. I don't know enough about Debian to know if that permission error is
insurmountable (I can think of a fairly good reason it should be; you don't
want random users to be able to hijack already running graphical sessions,
although I'd expect opening a fullscreen window would also require root
privileges for the same reason).

If it does turns out to be unworkable, is SSHing into the RPI and uploading
images to an already-running daemon an answer? What exactly are you trying
to do?

Ian​

Re: [pygame]

[Ian Mallett]

On Tue, Jun 20, 2017 at 12:51 AM, Peter Irbizon 
wrote:

> help
>

​You appear to be subscribed.​

Re: [pygame] How much blit costs?

[Ian Mallett]

​Hi,

There was rather a lot of discussion on the mailing list archive about
related topics recently, so searching the archives might prove informative.
However, the main things to know are:

(1) PyGame is essentially CPU-bound rasterization. The fastest way to do
this is with the Sprite module, or so I'm told.

(2) Using PyOpenGL instead of PyGame (for blitting, anyway), you instead
use the GPU, which is deigned for doing just this. You have to know what
you're doing, but it will probably be faster.

In your case, most of your objects are off the screen, so you're probably
CPU-bound anyway. If you really need more performance, and you really need
to process every object every frame, you'll need to switch to a language
with less overhead, like C++, or jitted like PyPy.

Ian

Re: [pygame] Installing Python 3 and pygame

[Ian Mallett]

On Tue, May 16, 2017 at 5:28 PM, Irv Kalb  wrote:

> 1)  What does the error message associated with the:  "python3 -m pip
> install pygame -- user "  mean?
>
​Exactly what it says. It's not recognized as a program. This means that it
can't find "python3.exe", "python3.bat", or anything else named "python3"
on your PATH.​

> Obviously it is not recognizing 'python3' - what do I do to fix that?
>
​Since you clicked the add-to-path option in the installer, probably Python
is already on your PATH. I think the issue is, on Windows, it's
"python.exe", not "python3.exe". Does using "python" instead of "python3"
work?

> Is fixing that important if I don't intend to use the command line for
> development?
>
​Not really, no. If you want to "fix" it, you can make a symlink to the
"python.exe" named "python3.exe", or something. Something like:
cd C:/Python36
mklink /D python3.exe python.exe
I personally have it set up a little differently, with subversions for
testing: I have e.g. "python27.exe", "python35.exe", etc..
​

> 2)  Why do the instructions on the official pygame site tell users to use
> this command, which generates an error, when the "pip install pygame" or
> "pip3 install pygame" commands seem to do the job?
>
​I don't know, but I suspect that these are UNIX-compatible commands,
instead of Windows-.

3)  (Suggestion) Perhaps the wording for Windows installations could be
> modified to include the extra step that tell users how to bring up the
> command line (for people like me and my students who might now have a clue
> about this).   The documentation for the Mac installation could also be
> modified to say that you need to bring up the terminal program to enter
> commands.
>
​I think it's a bit trivial (although for absolute newbies, I understand
perhaps not), but I don't see any reason why not.​


> 4)  Finally, is running Python 3.6.1 in 32 bit mode appropriate with
> pygame?
>
​On a 64-bit OS, it's not ideal, but it's probably fine, so long as it
works. The important thing to note is that the Python bitiness and the
PyGame (or any other package) bitiness need to *match*, or you'll get
cryptic errors at runtime.​

> Since I have a 64 bit operating system, should I really go through the
> steps again and find and install the 64 bit version of python instead?
>
​Ideally, yes. Probably, you want to uninstall the 32-bit version first.

> Why would default download default to a 32 bit version?  (I understand
> that these questions are out of the control of the pygame area, but I want
> to make sure that I have the correct environment, and that I tell my
> college how to get the correct environment for all the computers at the
> school.)
>
​Unsure. 32-bit will work on 64-bit (but not vice-versa), so it's a safer
default in some sense. Still, 32-bit computers are pretty old today, and
people who have them usually know about it. I'd make the user actively
choose, without a default available—but it's sortof a UI question.
​

> Sorry for the length of the post, but I expected that getting this
> environment set up would be a lot easier.  If my students were to face
> these problems trying to install it themselves, they would be completely
> lost and complain bitterly.
>
> Irv
>
​Ian​

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

[Ian Mallett]

On Thu, Apr 20, 2017 at 5:38 PM, Greg Ewing 
wrote:

> Ian Mallett wrote:
>
>> ​I like this idea a lot, modulo that you should also store the reference
>> to the window.
>>
>
> The Renderer would hold a reference to the window itself,
> so you would only need to keep a separate reference to the
> window if you wanted to use different renderers with it
> at different times, or switch one renderer around between
> different windows.
>
> You might actually want to do the latter. If the Renderer
> encapsulates an OpenGL context, using just one Renderer
> would make it easy to share the same set of textures etc.
> for all of your drawing.
>
> So we have two use cases. If you have just one window:
>
>r = Renderer(window = Window())
># do some drawing with r
>
> If you have multiple windows and want shared rendering
> state:
>
>w1 = Window()
>w2 = Window()
>r = Renderer()
>
>r.window = w1
># do some drawing with r
>r.window = w2
># do some drawing with r


​The second use-case is more-or-less exactly what I was thinking. (I'm
still unconvinced the first use case really warrants a dedicated
constructor.)

I'm not sure if SDL 2's hardware renderers support being shared. I assume
they do, just from the API they export, but I don't know.
​

> --
> Greg
>
​Ian​

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

[Ian Mallett]

​Hi,

I dug around in the SDL 2 source (mostly "src/render/*"). As I suspected,
for hardware renderers, a renderer is essentially a graphics context. This
means that:

1: A renderer is more-or-less decoupled from a window. Each window can be
bound to up to one renderer, and each renderer can be bound to up to one
window.
2: There can be many renderers and many windows.

On Thu, Apr 20, 2017 at 12:30 AM, Greg Ewing 
wrote:

> If that's true, then it might make sense for the Renderer to have
> a 'window' attribute. The Renderer would then be the thing you
> keep a long-term reference to, and you would obtain the Window
> from it when needed.


​I like this idea a lot, modulo that you should also store the reference to
the window.

If draws are done through the renderer, then to change the window, you need
to change the renderer's pointer. This makes the problem I described a few
days ago less hidden to the user. Exposing things in this way feels somehow
"right" to me.

Ian

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

[Ian Mallett]

On Mon, Apr 17, 2017 at 4:28 PM, Lenard Lindstrom  wrote:

> I agree that a window and its renderer or a window and its display surface
> belong together as a single object. And I am looking at doing that now. It
> is just I am now running into the limitations of Python and Cython.
> Extension types only support single inheritance. To add full window
> support—title, hiding, resizing, brightness, and more—to both a Surface
> subclass and a Renderer subclass means duplicating all that window specific
> code for both subclass declarations. If Cython supported mixins (and I
> thought it could, but no such luck), it would be easy. It just seemed safer
> avoid code duplication with a Window class instead.
>

​Unfortunately, I know next to nothing about interfacing Python with C, so
I cannot suggest anything useful.​

It's worth noting that switching the graphics context between
>> windows (to do hardware draws) isn't free, and simple code
>> (that e.g. draws a bunch of things on two windows, switching
>> every draw call for code clarity) might not run very well.
>> Perhaps the API should discourage this somehow, especially if
>> full HW drawing is encouraged.
>>
>>
>> Again I don't understand. Given a window, its renderer, and a
>> bunch of textures: render the textures to various locations on the
>> window, update (expose) the renderer, then repeat. How is this not
>> hardware drawing. What am I missing?
>>
>>
>> ​Mmm I realize I was not very clear. Let me try again: whenever you
>> /transition/ from HW drawing in one window to HW drawing into another, the
>> windowing system (SDL, SDL2, etc.) needs to internally call something like:
>>
>> ​​
>> wglMakeCurrent(window,context); //(on Windows)
>> glXMakeCurrent(display,window,context); //(on X11)
>> //Other platforms similar
>>
>> This call does a bunch of bureaucratic stuff, mainly to rebind the GPU's
>> destination framebuffer onto the new window's HW surface. To the point,
>> that call is actually fairly expensive, and if you did something in a
>> revamped pygame like:
>>
>> for i in range(100):
>> window1.draw(lines[i])
>> window2.draw(lines[i])
>>
>> Then the windowing system needs to insert 199 calls to it.
>>
>> There are two options that occur to me:
>>
>> 1: Set up a graphics context that will be shared by all windows created.
>> Draw calls go to a per-window hardware buffer. Then display.flip() iterates
>> through all extant windows, binds to the window, and draws the hardware
>> buffer into it. This adds the overhead of a second pass, but would perform
>> okay. (It is /critical/ that the graphics context be shared, or else draws
>> will incur the cost of binds also and we're back to square 0. It's not hard
>> to make graphics contexts shared, but IDK if/what SDL2 does.)
>>
> I don't see anything in SDL 2 for binding contexts. Maybe SDL does that
> for you. I don't know. If there is a way to do this in the SDL api, it will
> get exposed in the Pygame API at some point. The OpenGL stuff will also be
> added at some point.
>
​
I think you misunderstand. This isn't a feature to be exposed; it's a
syscall fundamental to how windowing systems work. SDL (or any other
HW-drawing-supporting library) categorically *must* do this, because this
is simply how the GPU writes to the screen.

In SDL 1.2.15, you'll find "wglMakeCurrent(...)" in
"src/video/wincommon/SDL_wingl.c" and in SDL 2.0.5, in
"src/video/windows/SDL_windowsopengl.c". I don't offhand know the
equivalents for Direct3D / Vulkan / GLES / Metal / Mantle / etc., but I
guarantee that they exist and are called, iff interfacing to the GPU
through that API on that platform is supported. As the documentation for
e.g. "SDL_CreateRenderer(...)" hints, a renderer is (apparently) a hardware
graphics context (possibly) tied to a target window.

When you use a windowing system, you shouldn't need to call this yourself,
because the whole point of a windowing system is that it handles
adjudicating the OS's compositor against the GPU for you. However, I bring
it up because certain use cases will lose performance because of it, if one
is unaware this is happening behind your back.

It boils down to figuring out (or testing) what SDL does. Something like
seeing whether this:
for i in range(100):
window1.hw_draw(lines[i])
window2.hw_draw(lines[i])
...is as fast as this:
for i in range(100):
window1.hw_draw(lines[i])
for i in range(100):
window2.hw_draw(lines[i])
If it is, no problem. If it isn't, then the above is why.

The TL;DR of this whole discussion, I guess, is simply:

*Repeatedly switching the target window for draw calls during the frame is
slow. However, if SDL's implementation anticipates this (and someone should
check that), or if such can be configured during SDL setup, it will be less
bad. Maybe we can sidestep investigating by exposing a different API.*

Ian

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

[Ian Mallett]

On Mon, Apr 17, 2017 at 12:01 AM, Lenard Lindstrom  wrote:

> ​Is it possible to combine the renderer with the window? I don't see why
>> the renderer needs to be pulled out of the pygame.draw module, and indeed,
>> this could be confusing for existing code.
>>
>> I don't quite understand. The renderer associated with the RendererWindow
> instance is returned by the window's renderer property.
>
> Why are the window and the renderer separate objects? There is a
> one-to-one relation between a window and its renderer or a display surface.
> And a window cannot have both. To avoid duplicating a bunch of window
> specific methods I created a Window class, with RendererWindow and
> SurfaceWindow (not shown) as subclasses. Also, a surface can have a
> renderer, and a combined surface-renderer object makes no sense. Still, I
> haven't ruled out renderer-window and surface-window types yet. However it
> is done, I don't see an elegant representation of the relationships among
> SDL windows, surfaces, renders, and textures.
>

​I guess I'm asking why they have to be separate objects. At the OS level,
there's a region of the screen which is backed either by a software buffer
and managed by the compositor or a GPU buffer managed by the compositor via
the graphics context. It's a buffer either way, and the difference is
sortof only where it lives and what operations are fast on it.

So, it's not really clear to me what a "renderer" is (I guess it's supposed
to wrap the graphics context?).

Separately, I was thinking also that anything that does "rendering" ought
to be combined with pygame.draw, because principle of least astonishment.
However, this sortof depends on the new drawing API, and whether it
can/should remain backward compatible with pygame.draw.

For maximum backcompatibility, something like the following would seem to
>> fit better with the existing API:
>>
>> surf1 = pygame.display.Window(rect1,flags)
>> surf2 = pygame.display.Window(rect2,flags)
>> #...
>> surf1.blit(...)
>> surf2.blit(...)
>> #...
>> pygame.display.flip()
>>
>> I don't recall what was decided about the feasibility of implementing
>> SDL2-style or hardware-accelerated rendering, but I'd hazard that this sort
>> of API wouldn't map well to it. OTOH, I don't think the decision to
>> implement a modern graphics interface was decided in the first place (just
>> that we're currently adding some SDL2 stuff).
>>
> The user can choose either a renderer or a display surface for a window.
> And pixels can be copied between textures and surfaces. So hardware
> accelerated rendering is available, as shown in the example.
>
> As for set_mode(), flip(), and update(), they remain in Pygame SDL 2.
> Keeping as much of the Pygame SDL 1 API in Pygame SDL 2 is a priority. This
> example explores how new SDL 2 specific capabilities can be added to
> Pygame. It uses a Python feature unavailable when Pygame was created, the
> new-style class.
>

​My point was more that the proposed API substantially changes the way
programming in pygame feels. I don't know; maybe this is necessary.​

It's worth noting that switching the graphics context between windows (to
>> do hardware draws) isn't free, and simple code (that e.g. draws a bunch of
>> things on two windows, switching every draw call for code clarity) might
>> not run very well. Perhaps the API should discourage this somehow,
>> especially if full HW drawing is encouraged.
>>
>
> Again I don't understand. Given a window, its renderer, and a bunch of
> textures: render the textures to various locations on the window, update
> (expose) the renderer, then repeat. How is this not hardware drawing. What
> am I missing?
>

​Mmm I realize I was not very clear. Let me try again: whenever you
*transition* from HW drawing in one window to HW drawing into another, the
windowing system (SDL, SDL2, etc.) needs to internally call something like:

wglMakeCurrent(window,context); //(on Windows)
glXMakeCurrent(display,window,context); //(on X11)
//Other platforms similar

This call does a bunch of bureaucratic stuff, mainly to rebind the GPU's
destination framebuffer onto the new window's HW surface. To the point,
that call is actually fairly expensive, and if you did something in a
revamped pygame like:

for i in range(100):
window1.draw(lines[i])
window2.draw(lines[i])

Then the windowing system needs to insert 199 calls to it.

There are two options that occur to me:

1: Set up a graphics context that will be shared by all windows created.
Draw calls go to a per-window hardware buffer. Then display.flip() iterates
through all extant windows, binds to the window, and draws the hardware
buffer into it. This adds the overhead of a second pass, but would perform
okay. (It is *critical* that the graphics context be shared, or else draws
will incur the cost of binds also and we're back to square 0. It's not hard
to make graphics contexts shared, but IDK if/what SDL2 does.)

2: Discourage this pathological situation in t

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

[Ian Mallett]

On Thu, Apr 13, 2017 at 3:25 PM, Lenard Lindstrom  wrote:

> """Render an image to a window
> This is adapted from the SDL 2 example at
>  >.
> """
>

​Heh, I'm friends with Will. We're at the same university.​

import pygame
> from pygame.display import RendererWindow
> import os
>
>
> def get_resource_path():
> my_dir = os.path.dirname(os.path.abspath(__file__))
> return os.path.join(my_dir, 'data')
>
>
> def run():
> pygame.display.init()
> title = "Hello World!"
> rect = (100, 100, 640, 480)
> flags = RendererWindow.SHOWN
> with RendererWindow(title, rect, flags) as win:
> ren = win.renderer
> flags = (ren.ACCELERATED  |
>  ren.PRESENTVSYNC   )
> ren.open(flags)
> image_path = os.path.join(get_resource_path(), 'hello.bmp')
> bmp = pygame.image.load(image_path)
> tex = ren.new_texture_from_surface(bmp)
>
> for i in range(3):
> ren.clear()
> tex.copy_to_renderer()
> ren.update()
> pygame.time.delay(1000)
> pygame.quit()
>
> if __name__ == '__main__':
> run()
>
>
> A window with renderer and a window with surface are implemented as
> distinct subclasses of a standard Window extension type. Each Window
> instance is an open window on the display. Window updates are perform by
> methods on the corresponding renderer or surface. Window and renderer
> specific constants, such as SDL_WINDOW_SHOWN and SDL_RENDERER_ACCELERATED
> are class attributes, though they could also be included in pygame.locals.
>
> This is preliminary design work, so feedback is not only welcome but also
> necessary.
>

​Is it possible to combine the renderer with the window? I don't see why
the renderer needs to be pulled out of the pygame.draw module, and indeed,
this could be confusing for existing code.

For maximum backcompatibility, something like the following would seem to
fit better with the existing API:

surf1 = pygame.display.Window(rect1,flags)
surf2 = pygame.display.Window(rect2,flags)
#...
surf1.blit(...)
surf2.blit(...)
#...
pygame.display.flip()

I don't recall what was decided about the feasibility of implementing
SDL2-style or hardware-accelerated rendering, but I'd hazard that this sort
of API wouldn't map well to it. OTOH, I don't think the decision to
implement a modern graphics interface was decided in the first place (just
that we're currently adding some SDL2 stuff).

It's worth noting that switching the graphics context between windows (to
do hardware draws) isn't free, and simple code (that e.g. draws a bunch of
things on two windows, switching every draw call for code clarity) might
not run very well. Perhaps the API should discourage this somehow,
especially if full HW drawing is encouraged.

Lenard Lindstrom
>

​Ian​

Re: [pygame] Does pygame execute on a separate process/thread?

[Ian Mallett]

On Thu, Apr 6, 2017 at 7:57 AM, Deven Hickingbotham 
wrote:

> When playing an audio file (pygame.mixer.music.play()) I have always
> assumed that this executed in a process or thread separate from the main
> thread since the call to play was non blocking.
>
​AFAIK, pygame is singlethreaded. For sound at least, the syscall that
starts the audio device is asynchronous (i.e., the CPU doesn't babysit the
sound card for every byte it plays; this wouldn't perform acceptably).

Re: [pygame] website comment moderation

[Ian Mallett]

I don't really have time to help systematically, but if I were a moderator
and it were easy enough, I'd nuke spam when I saw it.

Re: [pygame] Dirty rect overlapping optimizations

[Ian Mallett]

On Tue, Mar 28, 2017 at 8:20 AM, Leif Theden  wrote:

> 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 updates is effectively wasted.
>
​I've already said this, but it bears amplifying: this has been my
experience also. If you're fillrate-bound enough to be worrying about
overdraw and minimal blit updates, you're probably fillrate&fragment-bound
enough to want to invest in a GL renderer anyway.
Ian​

Re: [pygame] Dirty rect overlapping optimizations

[Ian Mallett]

On Mon, Mar 27, 2017 at 5:26 PM, Greg Ewing 
wrote:

> Ian Mallett wrote:
>
>> Unfortunately, computing those rectangles is annoying, and also O(n^2) in
>> the number of rectangles
>>
>
> With the right data structures and algorithms, it doesn't have to be.
>

​I mean this in a fundamental, mathematical sense. With O(n) rectangles,
you can produce O(n^2) regions that cannot be decomposed into fewer than
O(n^2) disjoint rectangles.

Ian​

Re: [pygame] Dirty rect overlapping optimizations

[Ian Mallett]

On Mon, Mar 27, 2017 at 12:34 PM, René Dudfield  wrote:

> On Mon, Mar 27, 2017 at 8:08 PM, Ian Mallett  wrote:
>
>> --IDK if pygame does this, but I expect blitting, with overdraw, to a
>> fullscreen temporary surface, and then sending the whole surface every
>> frame to the GPU would be faster than updating multiple smaller portions of
>> the GPU memory with CPU data.
>>
>
> Double buffering works like that. Except with update you can tell it to
> update only parts of the back buffer. When you display.flip()/update() it
> sends the data. It's faster because less data is sent over the bus. But
> even on OpenGL slower implementations (or with higher resolutions) you can
> gain benefits by only updating part of the buffer(s). Not on monster
> dedicated cards at lower resolutions of course.
>

​I suppose. Still, this should be asynchronous. Maybe making it work in
Python isn't possible.​

--IIRC the fastest algorithm for rect-rect collision detection is the
>> max-of-mins/min-of-maxes method, which is widely known. It maps nicely to
>> SSE too.
>>
>
> Sounds interesting. Maybe that's what we're using now for rect
> collision... I'm not sure of the algo name. It's only in C however.
>

​Yeah I'm not sure it has its own name. And definitely you'd want it in C
or equivalent.​


> Below is one of the cases that benefits the most. (actually after drawing
> this I'm not sure if this is actually true or I dreamed it up... but I drew
> the diagrams... so it feels a waste to delete them).
>
> Currently the update method combines two rects like this:
> ___
> | |
> |   __|
> |___|_|   |
> | |
> | |
> |_|
>
> Into a big rect like this:
> ___
> | |
> | |
> |   XX| # - updated, but no need.
> |###  | X - over drawn.
> |###  |
> |###__|
>
>
> Note in these crude diagrams the # area is drawn even though it doesn't
> need to be, and the XX is over draw. When there are some overlapping rects
> like this that are large, that can be quite a saving of pixels not needed
> to be drawn.
>

​Right.

the thing to consider is what you do about it. You can't just "not draw"
those pixels, because you still have to iterate over them, which defeats
the point. Instead, you have to decompose the combination of rects into
disjoint subrects that span the region that needs to be updated. For your
example:

┌┐
││
│  ┌─┼──┐
└──┼─┘  │
   ││
   └┘

. . . the decomposition could be something like:

┌┐
││
│├──┐
└──┬─┤  │
   │ │  │
   └─┴──┘

The key point is that doing this decomposition needs to be faster than just
drawing. Unfortunately, computing those rectangles is annoying, and also
O(n^2) in the number of rectangles (whereas the number of overdrawn pixels
you save can be linear-ish).

Ian​

Re: [pygame] Dirty rect overlapping optimizations

[Ian Mallett]

Hi,

On Mon, Mar 27, 2017 at 12:16 PM, DR0ID  wrote:

> On 27.03.2017 20:08, Ian Mallett wrote:
>
>> max-of-mins/min-of-maxes method
>>
>
> Hi Ian
>
> Could you share more about this method? Seems I can't find something
> related to dirty rects with that.
>
>
> ~DR0ID
>

It's a rect-rect collision detection algorithm, which could be applied to
detect which rects overlap (and gives the overlapping rect also). It's the
standard algorithm people use for this purpose, although people tend to
think of it in terms of multiple tests, which is less intuitive (to me,
anyway) and slower.

The test is basically (from memory):

collided = max(rect1.min,rect2.min) < min(rect1.max,rect2.max)


In 1D, you can think of "rect.min" as being "rect.left" and "rect.max"
being "rect.right". In nD rect.min is a vector [left,bottom,back,...] and
rect.max is a vector [right,top,front,...] and the "<" must apply along all
axes. That's why it's great for SSE. You can also subtract the terms to get
the dimensions of the overlapping area.

On Mon, Mar 27, 2017 at 12:23 PM, Radomir Dopieralski 
 wrote:

> On Mon, 27 Mar 2017 12:08:10 -0600
> Ian Mallett  wrote:
>
> > --There are two key cases to think about: (1) You have 1x1 pixel
> > rects for each pixel on the screen. No overdraw, so the algorithm is
> > complete waste.
>
> I think it would make sense to merge dirty rectangles even if they don't
> actually overlap, but simply touch. This would improve this use case
> (and a common use case of a tiled map) greatly.
>
> --
> Radomir Dopieralski
>

​I agree; this is desirable.​

Ian​

Re: [pygame] Dirty rect overlapping optimizations

[Ian Mallett]

Hi,

Just a couple quick, miscellaneous notes on this problem:

--IDK if pygame does this, but I expect blitting, with overdraw, to a
fullscreen temporary surface, and then sending the whole surface every
frame to the GPU would be faster than updating multiple smaller portions of
the GPU memory with CPU data.

--Dirty rects were never really a performance issue for me. This is partly
because I usually implement the scheme above, more-or-less, partly because
I avoid it algorithmically, and partly because blitting is inexpensive and
typical overdraw rates are low (as they would be in a good GPU renderer
too).

--IIRC the fastest algorithm for rect-rect collision detection is the
max-of-mins/min-of-maxes method, which is widely known. It maps nicely to
SSE too.

--I don't doubt there's no clear performance gain for current
implementations, especially if the algorithm is in Python.

--There are two key cases to think about: (1) You have 1x1 pixel rects for
each pixel on the screen. No overdraw, so the algorithm is complete waste.
(2) You have a bunch of fullscreen rects that of course all overlap 100%.

Ian

Re: [pygame] Re: pygame with SDL2 proposal

[Ian Mallett]

​​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 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
> making simple shapes around the on the screen is better than a GPU?  Why
> then are basically all games these days using a GPU?  Please, don't answer
> it, because I'm not sure if you are trolling or not, and don't want to risk
> derailing the tread with this...honestly quite ludicrous assertion you've
> made.  The proof is in the pudding, so to speak, and the pudding is
> certainly not software rendering anything.
>
Thanks René! And to clarify: (1) Leif, the answers to your objections are
in that wall of text, which is of course why I wrote it. (2) I do not
troll. (3) You're right that if hardware acceleration is off the table,
then this conversation is orthogonal here. But, it's unclear to me if it
*is* off the table.

At the risk of over-simplification, but in the interest of moving the
conversation forward, let's try to put the current issues in context. As I
understand it, the proposals vis-à-vis SDL2 are:

1: Do nothing

2: (Progressively) integrate SDL2 patch into existing pygame with goal of
eventual SDL1/SDL2 compile option (René and Lenard OP, many detailed
variations)

3: Transition (as above or rewrite) to use SDL2 only (various)

. . . any of which implemented with the following options, which are not
necessarily mutually incompatible:

A: Share/relicense pygame_sdl2
B: Expose a different API designed for performance (for graphics especially)
C: Base largely on hardware acceleration for performance

D: Expose new SDL2 features in the pygame API

​. . . and under the following serious constraint, which I think is
accurate:​
On Tue, Mar 21, 2017 at 6:27 AM, Leif Theden  wrote:

> Let's be realistic, there are very few people who have the will or ability
> to deal with the pygame code base
> ​​
>

I'll keep my opinion short: personally, I'm okay with any proposal, 1, 2,
or 3, though I'd pick 3 over 2, despite being a bit dangerous. At the same
time, I think option B implies we want to leave our niche (which I'm
vaguely against) and option C is implausible (again, for our niche). Saving
work is preferable, but otherwise I don't know enough to say anything about
A. I support D.

Ian

Re: [pygame] pygame with SDL2 proposal

[Ian Mallett]

​On Mon, Mar 20, 2017 at 3:52 PM, Greg Ewing 
 wrote:

> Ian Mallett wrote:
>
>> Per-pixel drawing operations, if they must be individually managed by the
>> CPU, will always be much faster to do on the CPU. This means things like
>> Surface.set_at(...) and likely draw.circle(...) as well 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  wrote:

> 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?
>
​Oh yes!

Basically, it's because a GPU runs well when it has a big, parallelizeable
workload, and terribly when not. Flexible, small workloads, such as you see
in a typical indie game or small project, are basically exactly this worst
case. They are small (rendering dozens to hundreds of objects), and they
are dynamic in that the objects change positions and shading according to
CPU-hosted logic. Heuristic: if you've got a branch deciding where/whether
to render your object or what color it should be, then the GPU hates it and
you.*

If that made sense you to, you can skip this elaboration:


The GPU is basically a bunch of workers (thousands, nowadays) sitting in a
room. When you tell the GPU to do something, you tell everyone in the room
to do that same thing. Configuring the GPU to do something else (saliently:
changing the shader) is slow (for technical reasons).

I have a GTX 980 sitting on my desk right now, and it has 2048 thread
processors clocked at 1126 MHz. That's ing *insane*. I can throw
millions and millions of triangles at it, and it laughs right back at me
because it's rendering them (essentially) 2048 at a time. The fragments (≈
pixels) generated from those triangles are also rendered 2048 at a time.
This is awesome, but only if you're drawing lots of triangles or shading
lots of pixels in the same way (the same shader).

But I *cannot* change the way I'm drawing those triangles individually. Say
I alternate between a red shader and a blue shader for each of a million
triangles. NVIDIA guidelines tell me I'm at about 3 *seconds per frame*,
not even counting the rendering. This is what I mean by overhead. (To work
around this problem, you *double* the amount of work and send a color along
with each vertex as data. That's just more data and the GPU can handle it
easily. But reconfigure? No good.) And this is in C-like languages. In
Python, you have a huge amount of software overhead for those state
changes, even before you get to the PCIe bus.

And in a typical pygame project or indie game, this is basically exactly
what we're trying to do. We've got sprites with individual location data
and different ways of being rendered--different textures, different blend
modes, etc. Only a few objects, but decent complexity in how to draw them.
With a bunch of cleverness, you could conceivably write some complex code
to work around this (generate work batches, abstract to an übershader,
etc.), but I doubt you could (or would want to) fully abstract this away
from the user--particularly in such a flexible API as pygame.

The second issue is that the PCIe bus, which is how the CPU talks to the
GPU, is *really slow* compared to the CPU's memory subsystem--both in terms
of latency and bandwidth. My lab computer has ~64 GB/s DDR4 bandwidth (my
computer at home has quadruple that) at 50ns-500ns latency. By contrast,
the PCIe bus tops out at 2 GB/s at ~2ns latency. My CPU also has 15MB
of L3 cache, while my 980 has no L3 cache and only 2MiB of L2 (because
streaming workloads need less caching and caching is expensive).

So when you draw something on the CPU, you're drawing using a fast
processor (my machine: 3.5 GHz, wide vectors, long pipe) into very close
DRAM at a really low latency, but it's probably cached in L3 or lower
anyway. When you draw something on the GPU, you're drawing (slowly (~1 GHz,
narrow vectors, short pipe), but in-parallel) into
different-DRAM-which-is-optimized-more-for-streaming and which may or may
not be cached at all. Similar maybe, but you *also* have to wait for the
command to go over the PCIe bus, take any driver sync hit, spool up the GPU
pipeline in the right configuration, and so on. The overhead is worth it if
you're drawing a million triangles, but not if you're calling
Surface.set_at(...).

The point is, GPUs have great parallelism, but you pay for it in latency
and usability. It's a tradeoff, and when you consider all the rest you need
to do on the CPU, it's not always a clear one. But, as a heuristic, lots of
geometry or fillrate or math-intensive sha

Re: [pygame] pygame with SDL2 proposal

[Ian Mallett]

Hi,

As sort of a side-note, since performance has come up . . .

Per-pixel drawing operations, if they must be individually managed by the
CPU, will always be much faster to do on the CPU. This means things like
Surface.set_at(...) and likely draw.circle(...) as well as potentially
things like draw.rect(...) and draw.line(...). And it means everything, if
there are a lot of calls. The GPU is obviously faster at graphics
operations in-general, but it's still a thorough loss if you have to send
the commands over the PCIe in the first place: if not in processing time,
then in latency. As a matter of fact, this is true for most things people
try to use GPUs for, and mitigating it is why e.g. Vulkan has to be so
complex.

What does this have to do with anything?

Well, it's a philosophical question of what we want pygame to be:

1: Hardware-accelerated pygame-API-compatible library. (Basically won't
work for reasons above.)
2: Hardware-accelerated pygame-API-incompatible library. (Fine, but AFAIK
this already exists . There
are probably other projects too.)
3: Software pygame-API-compatible library. (We have this now, and any
movement to SDL2 should be considered in light of what features it changes
(i.e. many misc. improvements, but worse (?) blitting).)
4: Software pygame-API-incompatible library. (Works best, IMO, with any
plan to support SDL2.)

Python is a slow language, and if you're using it, you're implicitly saying
usability is more important right now. This includes graphics, and pygame
is currently occupying that niche: highly usable, low-level, slow(ish;
still pretty fast) graphics. If we want hardware acceleration (options 1,
2) then we're moving outside that niche. Ditto, to a lesser extent,
breaking compatibility to add more-modern features (option 4). So
basically, what it comes down to is whether we like our niche, whether
moving to/incorporating SDL2 is focusing on a real problem, if so whether
moving to SDL2 affects our feature set in ways we do like, and if so
whether this affects our niche in ways we don't like.

Ian

Re: [pygame] teaching resources

[Ian Mallett]

On Sat, Mar 18, 2017 at 4:20 AM, René Dudfield  wrote:

> Whilst there are now more than a dozen books, and video series in many
> languages for teaching pygame, I'd like to include a new section on the
> website for educational resources for teachers. Or even better, to be able
> to point to an existing resource.  Not particularly for 'pygame', but for
> digital education in general, or at least python related. I wonder if you
> have any thoughts on this?
>
​This sounds awfully non-orthogonal to various current movements to bring
CS education to the masses (which typically means coding instead, alas, but
yet). Honestly, I'm not sure how valuable a new resource here would
be--surely, there are educational sites for teaching, and same but specific
for Python?

What makes sense to me would be a section specifically on using pygame. We
already have something of this sort (I know; I've been
looking-at/sprucing-up the current tutorials), but these are largely dated,
and don't span the whole of what pygame has to offer. They're also
text-dense, which is apparently not a popular way to learn things anymore.


> Anything else I should link to?
>
​What would have been most helpful for me when I learned pygame would have
been some solid foundation to build on. I offer my pygame hello world

and pygame-GL-2 hello world

as minimal, best-practices, public-domain resources (links have been stable
for years, but mirroring would be ideal).

Ian​

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

[Ian Mallett]

On Sun, Mar 12, 2017 at 10:24 PM, Bork Air 
wrote:

> again, your website looks like shit
>
> the original green one had some design
>
​​
​If one doesn't like the site, then one can always kindly offer to help
improve it. And, regardless of whether you like someone's work, dissing it
non-constructively in its inchoate phase is not cool.

René: While I personally thought the green design was fine, IMO the new
design is also good (and at-least certainly feels cleaner). We appreciate
the work you've put into this--I know it's been a lot!

Ian

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

[Ian Mallett]

On Sun, Mar 12, 2017 at 4:51 AM, René Dudfield  wrote:

> You can use the site via https.
>
​Ah I see! Suggest redirect HTTP -> HTTPS.​

If you let me know what borked things you're talking about I can point you
> in the right direction.
>
​For example, on https://pygame.org/docs/, there is a link to
"readme.html", which doesn't exist. It should probably be "wiki/about"
instead. There are 3.14e16 kg of errors of this ilk.

Docs for pygame are generated from the pygame repo, and many other pages
> you can edit via the wiki.
>
​This is https://bitbucket.org/pygame/pygame/src?​

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

[Ian Mallett]

​Hi,

Re: the logins, also note that the site currently is not HTTPS. I mean,
it's not particularly high-stakes, but I'd still like to recommend setting
a cert up (I did it myself for my website  using Let's
Encrypt ; it's fairly easy).

I don't really follow the architecture of this new-fangled Python-based web
thing, but I reverse-engineered enough to fix a few further (very minor)
things (and issue a pull request). There's some really borked stuff in the
docs I would totally fix if it were uploaded (I didn't see that it had been
open-sourced yet). Various others too (tags, projects, etc.), if those
don't interface with too much database stuff.

Really glad to see progress here and finally open-sourcing! This has been a
long time coming.

Ian

Re: [pygame] Pygame 1.9.3?

[Ian Mallett]

On Mon, Jan 9, 2017 at 10:42 AM, Benjamin A. Boyce  wrote:

> hello, i have a question about pygame, but I realize this is not the
> appropriate place for pygame help. I tried to click on the help link on the
> pygame website for a mailing list, but link didnt work. Any suggestions as
> to where I could go?
>
​Well, looks like you've found your way to the mailing list successfully.
Just send a new email to "pygame-users@seul.org".

I also hear tell of an IRC channel.

People have also tried StackOverflow, but it's pretty hit or miss.

Ian​

Re: [pygame] Pygame, images, and Macs

[Ian Mallett]

On Fri, Jan 6, 2017 at 8:16 AM, Bob Irving  wrote:

> We're using pygame in our CS classes here and have found that the built-in
> python (with Macs, which is what we use) works MOSTLY.
>
> The big snag seems to be image files. It doesn't seem to matter whether
> they are jpgs, pngs, etc. They sometimes display and sometimes don't.
>
> Our suspicion is that it is something in how either El Cap or Sierra
> processes image files that conflicts with pygame
>
> Has anyone found a solution?
>

​I'm not sure I apprehend the problem. In particular, "[t]hey sometimes
display and sometimes don't" could mean any number of different things, and
could be due to an error in your display code, invalid image data, bugs in
PyGame or OSX, &c. Please explain more about how exactly it doesn't work.
Ian​

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

[Ian Mallett]

On Sun, Dec 25, 2016 at 12:53 PM, Mikhail V  wrote:

> ​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?
>
​Definitely.
​


> 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 transpose being expensive.
> Actually transpose itself does not add significant overhead. First time
> I was testing it, I did something wrong.
>
> For method 2. if I define order="FORTRAN" for original array,
> there is no difference in comparison to 3. But if I leave default (C)
> order then the performance degrades with bigger arrays
> (ca. 20% slower by 800x600 8bit array).
> So it is indeed important thing.
>
​Makes sense. For bigger arrays, caching becomes more important in the
copying, and implicit transposes of the order mean you thrash on reading.​


> Most interesting that 1. method with buffer write seems to be always
> faster
> than others, by ca. 5%. Not a big win, but still interesting...
> And if I try it with FORTRAN order, it becomes 2 times slower!
>
​I'm not sure I fully parse what you're doing here. As long as it's safe,
copying buffers should be slightly faster since it's 1D--maybe the buffer
API is smart enough to step in larger chunks that might potentially
straddle a scanline, and you also have one fewer loop variable. When you
try it with FORTRAN order, to produce a buffer of the same format would
require an allocation and then a copy, so that's probably why it's slower.

The NumPy internals

has salient things to say on this issue.

So I would still look forward to having methods dealing with C order,
> just to avoid writing extra transposing and full compliance
> with default numpy notation.
>
> Any comments or opinions about it?
> It would be good to know first, which of those things
> people use more often and make some use case examples.
>
​Personally, I would like C order just because it's "expected" in
graphics*. Under this assumption, I wrote all my code e.g. looping over "y"
first, using the buffer API for GL interop, etc. This is optimal in the C
order every graphics programmer would expect, but in FORTRAN order, it's
*exactly* wrong. I never profiled both options because it's a nearly
fundamental assumption.

I mean, it's not terribly important. Python is not a fast language. One
writes stuff in Python because your program running 5x/50x slower is a
non-issue and you want the expressivity. But free perf is free, so it's a
bit annoying.

*In the interest of fairness, it should be noted that there is an offshoot
of image processing (a subset of graphics) that might disagree. They're
very FORTRAN-y, using langs with 1-based indexing and both array orders.
They also tend to be non-CS/non-math types who work in industry, generating
appalling code.

Mikhail
>
​Ian​

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

[Ian Mallett]

On Sat, Dec 24, 2016 at 9:39 AM, Mikhail V  wrote:

> > --Are you tied to palettal color?
>
> Yes in many cases. I need also palettal rendering for higher
> depths. Ideally graphical frontend should support also 16 bit and 32 bit
> palettal rendering. And ideally the final colorisation should happen on GPU
> namely I send an integer array to video system and video system
> must resolve the values to the end format and ideally
> this should be done in most effective way.
> But this is not what Pygame can do.
>
> So currently for higher depths I use numpy to convert integers
> to composite colors in each loop cycle. So Pygame provides only 8 bit
> paletted, but actually for many applications it is good enough.
> 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).
​

> > 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.

​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.

​Ian​

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

[Ian Mallett]

On Fri, Dec 23, 2016 at 4:45 PM, Mikhail V  wrote:

> Could you elaborate please?
>
​Now that I'm reading more carefully, it looks like you're creating a
palettalized RGB surface (8-bit indices to 24-bit color). Offhand, I also
would expect referencing the indices into a 2D array to work. I'm tempted
to conclude a possible bug, or at least an insufficiently helpful exception.

A few questions:
--Do you need to create a surface from data, or merely update a surface
repeatedly?
--Are you particularly tied to pygame.pixelcopy? I've found the surfarray
module works best of the three (pixelcopy, surfarray, PixelArray), and you
can use any for either task.
--Are you tied to palettal color? These are slower, and more relevantly,
less common and therefore more likely to be less robust. Their main use
today is for accelerating palette rotations. Their higher memory usage is
usually irrelevant for typical surface sizes.

The copy buffer trick you're using looks a little suspect to me. 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.

Ian​

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

[Ian Mallett]

​Your surface is 300*300*3 (3D), since it is RGB, but your array is only
300*300 (2D).

Re: [pygame] New pygame.org website

[Ian Mallett]

On Thu, Dec 15, 2016 at 1:23 PM, Thomas Kluyver  wrote:

> If you're interested in helping to build this, or you have ideas about how
> best to do it, please reply to this email!
>
​I would be interested in helping. My knowledge of web development is
"basic" (and that's being generous). I do know the basics of HTML, PHP, and
Javascript though.

I support Python-based tools, Markdown, and possibly making the site on
Github.

Re: [pygame] Should Pygame be recognized for using Sphinx document generator

[Ian Mallett]

I'm confused--is there a reason it shouldn't be?

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

[Ian Mallett]

On Thu, Sep 29, 2016 at 9:06 PM, shortcipher 
wrote:

> Some experiments point to overflowing 16-bit integers rather than memory
> resource issues:-
>
> 1. My script can load a 16383 x 1321 image but gets "Out of memory" on a a
> 16384 x 1321 image.
>
​PyGame is layered over SDL 1.2. It seems that, in SDL 1.2, the pitch
(sizeof scanline) is a uint16. So 16384 pixels * 4 bytes/pixel causes the
overflow.​


> 2. A workaround to load the image in PIL and transfer it to pygame as a
> string works as long as the width is less than 21846 and the height is less
> than 32768, otherwise the image is totally garbled. (Note that 21845 x 3 =
> 0x.)
>
​Based on the above, I'd say 16383 is an upper limit on width. The pixel
pitch is important for various things, although it may not be immediately
critical. That's why loading might appear to work.

Width and height are stored as ints, but I still wouldn't make them larger
than 16383 (who makes an image higher than wide?).

N.B. JPEG itself supports up to 65535 square.

Ian​

Re: [pygame] Registration disabled.

[Ian Mallett]

​​On Wed, Apr 27, 2016 at 11:27 PM, DiliupG  wrote:

> Pardon me for saying so but I simply can't understand why those who
> maintain this site can't rectify this problem which has been persisting for
> many years. Can anyone point out the reason for this?
>
Be nice, now. As has been explained before, the reason is due to a
historical deluge of spam. The feature is implemented, it is just
deliberately not *enabled*.

OP: René has been handing out the link to register. Maybe the PyGame IRC
knows it too.

Re: [pygame] Faster blitting

[Ian Mallett]

On Mon, Mar 14, 2016 at 1:41 AM, Javier Paz  wrote:

> I also agree with Greg. My experience tells me that, in order to have a
> significant overhead, you must have a loop.
>
​I think the point is that in the case where you have a lot of small blits,
the proportional overhead of the checks is more significant.

My (C++) codebase supported something similar, and I noticed (in my code)
that the checks were pretty cheap, unless you had a lot of blits to do.
Then, they were still cheap, but pointless. My solution? Only allow blits
between surfaces of like type (and it won't compile if you try). This works
out great--on the CPU, you don't really ever want to blit anything other
than RGBA8 anyway (even if you don't have an alpha, you should use RGBA,
because of SIMD and alignment). This forces you to make a copy if you
*really* want to blit--but that's sortof what the blitter would already
have to do, in a slower (less instr. locality), less elegant, one-off way.

So one *could* drop support for a lot of surface types (I know there was
talk about doing this anyway). But, at some point you have to remember that
your game is written in Python. If you want to scrape out the last 1% of
your performance, why are you using a scripting language in the first
place? And sure, the underlying library oughtn't to be deliberately slow,
but I think I value flexibility over minor performance gains. Of course,
maybe we *can* get rid of some surface types that no one actually uses, and
get a bit of both . . .

Ian​

Re: [pygame] pygame Event

[Ian Mallett]

>
> No, that is not a bug. The Events don't have a __dict__ attribute.
>
The attributes that events have are described in the documentation:
>
​Umm, I think you are mistaken. Events are instances of
"pygame.event.EventType", and the documentation you linked correctly shows
".__dict__" as an attribute.

http://pastebin.com/qfKg2bAe http://pastebin.com/KQN8Fpc8
>
Thanks for providing an example. I wasn't able to reproduce the problem
(that is, for me the ".__dict__" attribute exists and the example works as
expected). Can you output your PyGame version? Try e.g. in a shell:
>>> import pygame
>>> pygame.ver
Mine produces "1.9.2pre" (which might not be the latest).

As a sidenote, I haven't ever had occasion to use this functionality, as
there are more idiomatic and clear ways to retrieve information about
events' data.

Ian​

Re: [pygame] Pygame site

[Ian Mallett]

I think I have 90% of the functional documentation memorized. +1 for local
copies.

Re: [pygame] connect-4 game

[Ian Mallett]

On Sat, Jan 30, 2016 at 4:44 PM, Yann Thorimbert 
wrote:

> However, how to go to this page (
> ​[...]) from pygame.org ? I did not find any way.
>
​After a rash of spam, coupled with a lack of resources to combat it, this
stopgap measure was put into place. It was certainly not intended as a
long-term solution, although practically speaking, it is.

I would also like to remind the list that it's also supposed to be
semi-secret, with the URL distributed directly only as requested to
plausible developers (such as the OP).

> Also, I had to go to the old version in order to get a way to add a
> project, this does not appear clearly in the new version.
>
​A similar scenario. The PyGame website has undergone a (huge) number of
rejuvenation efforts, with the latest development being the dogfooding of
the front page with the new site.

The consensus is that this effort is, broadly, a step in the welcome
direction. However, that also the current site design is both
incomplete/unusable and confusing. I had hoped that the dogfooding
procedure would make development progress faster, but this appears not to
have been the case.

Ian​

Re: [pygame] Good English Computer coding books

[Ian Mallett]

On Tue, Jan 26, 2016 at 10:45 AM, Oliver Nichol 
wrote:

> Hey everyone
>
> What is a good book to get going with python coding (not as a beginner,
> just learning more.) Plz help! (not computer coding for kids by carol
> vorderman
>
> Sent from Mail  for
> Windows 10
>
​At a certain point, programming becomes more about solving problems than
learning the language, so you can't separate out the learning from the
doing. So, you should pick a problem domain that interests you and go from
there.

Since this is the PyGame mailing list, I'll suggest "Beginning Game
Development with Python and Pygame: From Novice to Professional

".

​Ian​
​

Re: [pygame] `pygame`: on Ubuntu, using `pygame.image.save` to save PNG causes `pygame.error: SavePNG: could not create png write struct`

[Ian Mallett]

​N.B. creating the write struct does *not*, for example, require being able
to open the actual file for writing. Therefore, this isn't an IO issue (if
the error is indeed what it says).

I think this is probably an outdated library. Probably, updating/compiling
the PyGame version as suggested is necessary.

Ian

Re: [pygame] Closing issue 211 with big-endian CPU test

[Ian Mallett]

On Sun, Oct 25, 2015 at 4:27 PM, Lenard Lindstrom  wrote:

> Is there a need to continue big-endian support?

​Bi-endian architectures are still around (ARM, MIPS in particular). AFAICT
little endian won the war, but big endian is still around mainly for
compatibility. The Raspberry Pi, for example, is almost universally
configured to little endian, despite being a bi processor.

Also, notionally, programs could swap endian-ness when operating on certain
memory regions for performance improvements. Though, I don't know of any
modern programs that do that.
​

> I mean, we leave in the big-endian specific code, but just leave it
> untested. Worry about it only if the need arises.
>
I like this solution. Making endianness go both ways with a compile flag
isn't really extra effort.

Lenard Lindstrom

​Ian

Re: [pygame] Is there a file limit on sound files?

[Ian Mallett]

​Hi,

There is not limit that I am aware of. Certainly, I've played much larger
sound files on much older versions of PyGame. Although, I prefer .ogg.

Outside guess--perhaps the required shared libraries aren't installed?

Are you sure you can't reproduce the problem? At the very least, what
OSes/systems/environments does this affect? And, what is the exact error
message?

Ian

Re: [pygame] lighting challenge

[Ian Mallett]

​I'm writing back because I thought I might have time to deal with this,
but it develops that I actually won't. :)

Basically . . . the algorithm I described is a reasonable ground truth. It
probably won't be very fast without NumPy or HW accel, and I can't really
debug your implementation for you, but it should at least help you get
started with what to look for.

Good luck!
Ian

Re: [pygame] Difference between flip and update?

[Ian Mallett]

On Wed, Aug 26, 2015 at 11:40 AM, Bob Irving  wrote:

> What is the difference? Is there a reason to use one over the other?
>
​The docs  are pretty clear on the
basic difference. Do you have a more specific question?​

Re: [pygame] Gracefully exiting with errors

[Ian Mallett]

On Wed, Aug 26, 2015 at 11:38 AM, Bob Irving  wrote:

> Is there a way to exit your game gracefully when there are errors? We have
> found with both IDLE and WingIDE that the game hangs, requiring several
> clicks of the X, etc.
>
> We are ending our game loop with
>
> pygame.quit()
> sys.exit()
>
​I prefer to let the script terminate itself (i.e. fall out the bottom),
but sys.exit should work fine too. I remember having this issue with older
versions of Python, but 2.7 or 3.* should work fine.

Here's some skeleton code

that I use.

Ian

Re: [pygame] Re: sprint this weekend

[Ian Mallett]

​Hi,

First, I think it's great that there's been some attention on the site
(even if it was a pointer switch). I'm comfortable with early 2000s web
design, but I realize not everyone is. The new feel of PyGame is a lot more
like something, if I were a neophyte, I'd want to tinker with.

Second, I think it's good that the new site has been made default. This
will force dogfooding. We should leave it that way.

However . . . the new site needs work. It took me *five minutes* to find
the documentation, and I still don't know how to add a project. IMO the
narrow columns and horizontal scrolling are bletcherous too, but I won't
knock the prototype too much, because what I really want to say is that:

*I propose that the website model be made more open for everyone to change.*
I haven't been keeping up with the list, so I apologize if it's been
answered, but it doesn't look like https://bitbucket.org/pygame/pygame is
the location for the site. That is, ordinary users can't submit pull
requests for the site itself. I think this would help us move toward a
better website, faster--and one which, by construction, the community would
value.

Ian

[pygame] `pygame.draw.(aa)?lines?(...)` with Alpha

[Ian Mallett]

Hi all,

I recently got a problem that traces back to the drawing functions "line",
"aaline", "lines", and "aalines" ignoring any alpha value they are fed.

This seems to me to be a Bad Thing. The obvious workaround is to draw to a
temporary surface, and then blit the surface with transparency, but this is
extremely wasteful, as it *squares* the asymptotic complexity. Really, I
think this should instead be handled by PyGame in the underlying rasterizer.

Attached is a simple example.

Ian
import pygame
surface = pygame.display.set_mode((128,128))
pygame.draw.  line(surface, (255,0,0,128), (0, 0),(128,128))
pygame.draw.aaline(surface, (0,255,0,128), (0,64),(128, 64))
running = True
while running:
for event in pygame.event.get():
if event.type==pygame.QUIT or (event.type==pygame.KEYDOWN and event.key==pygame.K_ESCAPE):
running = False
pygame.display.flip()

Re: [pygame] The dates for the next PyWeek...

[Ian Mallett]

​It should be noted that that is the week of SIGGRAPH, so all the graphics
people are out.

Re: [pygame] erratic behavior with 'display.update(Rect)'

[Ian Mallett]

On Mon, Jul 13, 2015 at 5:34 PM, Tom Rothamel  wrote:

> There isn't a way to update a portion of the display using OpenGL. OpenGL
> expects you to redraw the screen from scratch every frame, and then flip to
> the next frame.
>
> How are you drawing to the screen? Are you using GL calls? Or pygame blits
> to the screen surface? The later doesn't work with OPENGL.
>
​Yes and:

> Is it possible that the cause is that OPENGL is being used by pygame?
>
On Windows, afaik, this only happens if you request it with the
pygame.OPENGL flag. Nevertheless, inspecting the value of the following
should say for sure:
import os
print(os.environ["SDL_VIDEODRIVER"])
Pro-tip: IIRC, you can also *set* that value to whatever you like *before*
you initialize PyGame. Some values
.

Ian

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

[Ian Mallett]

Hi,

​As a long-time member here, I recall many *many* different attempts to
redesign the website. Three in memory, which is several years. Probably
more if I looked through my archives.

The model is that someone gets fed up with the current design and mentions
it on this list. There's some discussion and then everyone basically agrees
that the old design is lacking at least somewhat, but there forms a schism
between those who want to update the old site and those who want to start
over.

Usually, it devolves into the start-over people just going ahead and making
the remake, hoping it will be adopted. The result is semi-promising, but
since it is feature-deficient, no one wants to convert everything (and the
website maintainer(s) remained basically quiet throughout the whole process
anyway). Since there was no commitment to use it, the remake eventually
dies and everyone forgets about it in disgust.

Then, each time, I post a message like this and hope people will choose a
different model this time.

Ian

Re: [pygame] Problem with pytmx and tiled

[Ian Mallett]

​Assuming you're using a PyTMX version > 2.16.5, this looks like a bug in
its Python 3 support.

I'd try replacing "data = b64decode(data_node.text.strip())" with something
like "data = b64decode(data_node.text.strip().encode())" and seeing if that
improves anything. But this isn't a PyGame issue.

Ian

Re: [pygame] Which project is actually pygame2?

[Ian Mallett]

​I think we shouldn't worry about backward compatibility at all. I expect
making a standard wrapper to the new pygame and then going "import
py_wrapper as pygame" would work just fine for porting. Once pygame2 (or
whatever) is released, I might even write that wrapper myself.

Re: [pygame] lighting challenge

[Ian Mallett]

​Hi,

The basic idea with what I gave is to compute the simplest light transport
paths from the light to the eye. Specifically, we want all paths that start
at the light, pass through some number of surfaces, scatter off another
surface, pass through some number of surfaces, and then hit the eye.

I've added some comments to my pseudocode, which I've also edited a bit.

#Start with no light
result = 0
for S in surfaces:
#On this loop iteration, we will consider the
#light path that starts at the light, travels
#to S, bounces off, and travels to the eye.

#Figure out the amount of light that gets from
#the light to the surface.
product_of_alphas_between_light_and_S = 1.0
for T in surfaces:
if T is between S and the light:
#Attenuate light by T's transmissivity
#(alpha in range [0.0,1.0]).
product_of_alphas_between_light_and_S *= T.alpha
#"product_of_alphas_between_light_and_S" should
#now be a number between 0.0 and 1.0.  It
#represents the attenuation of the light
#as it travels to S.

#This tell you how much light gets to S.  The
#"intensity" scales how "strong" the light is.
#Technically, it's radiance, not intensity.
light_at_surface = light_intensity *
product_of_alphas_between_light_and_S

#Some of the light will be absorbed or transmitted
#through S.  The amount that is scattered back
#in a particular direction is called the BSDF.
#The BSDF I'm using here is diffuse, which is a
#constant factor (surface reflectance).  Because
#energy is conserved, this factor cannot be
#negative or larger than 1.0.
#Ultimately, this tells how much light leaves the
#S heading toward the eye.
reflected_light = light_at_surface * surface_reflectance

#Same idea as above.  Here we're attenuating the
#reflected light as it travels from S to the eye.
product_of_surface_alphas_between_S_and_eye = 1.0
for T in surfaces:
if T is between S and the eye:
product_of_surface_alphas_between_S_and_eye *= T.alpha

#This is the amount of light that finally reaches
#the eye.
light_at_eye = reflected_light *
product_of_surface_alphas_between_S_and_eye

#Accumulate it.  The sum of all paths (in all the
#loop iterations) is the first order light
#transport between the light and the eye.
result += light_at_eye

HTH,
Ian

Re: [pygame] lighting challenge

[Ian Mallett]

​Hi,

I played around with it a bit, but I'm not sure exactly what the problem
is, nor do I have time to figure out exactly what you're trying to do about
it.

I didn't run through your implementations in detail, but I did notice that
you're copying surface(s) in every one. I bet this eats a lot of time.

Certainly, the blits will too. As you observed, a GPU is great for this
sort of thing. If you haven't used PyOpenGL before, it might not be as hard
as you think to get simple blitting function correct. Actually, I think
there are already several projects on PyGame.org that provide it. In any
case, GPUs exist to draw things. They're very good at it. It is wise to
take them up on the offer.

Lastly, a correct-ish blitting function to use (assuming no SSS or
radiosity) in pseudocode:
result = 0
for all surfaces:
light_at_surface = light intensity *
product_of_alphas_between_light_and_surface
result += light_at_surface * surface_reflectance *
product_of_surface_alphas_between_surface_and_eye
I bet that can be factored into a 1-pass-per-surface algorithm.

Ian​

Re: [pygame] Re: Need a lot of help with 'virtual' board game

[Ian Mallett]

​Since this has turned into an advice thread . . .

Having taught Python for several years, I find that the best way to learn
any language, but Python in particular, is to just sit down and try a lot
of things, without assistance. It sounds like you're trying to make a game.
That's great, but you shouldn't try to do that by piecing together code
other people have written. You will learn more by writing it all from
scratch. *After* you have done this, then you'll have a better idea of what
goes into making a game, what code is best reused, and what code is best
left outsourced to dedicated projects.

Re: [pygame] Help me!

[Ian Mallett]

​Sounds like a Windows variety. I'm not sure why you'd expect it to appear
in the start menu, though. It's an API, not a program.

You can check if PyGame is installed by opening a Python terminal (Python
IDLE, probably), typing "import pygame", and then waiting to see if it
barfs.

Re: [pygame] GUI for pygame : ThorPy

[Ian Mallett]

On Sat, Jun 27, 2015 at 1:00 AM, Oliver Nichol 
wrote:

> I have no idea how pygame mailing works but I have a question I need help
> with. I’ve been trying to install pygame but it hasn’t been working (the
> files haven’t been downloading) please help!
>
​Oliver, you should start a new email thread addressed to "
pygame-users@seul.org" and ask your question in that.

Re: [pygame] looking for a critique of my code

[Ian Mallett]

On Sun, Jun 21, 2015 at 5:39 PM, tom arnall  wrote:

> I've written a program with pygame. It does what it's supposed to do,
> and runs at good speed, but I'm new to pygame, and OO programming, and
> I'm not much more than a novice with python. It would help me greatly
> if someone with experience in those areas would look at my code and
> tell me how I can improve it. Is that possible on this list, or in any
> other venue on the internet?
>
​Normally, I might recommend StackExchange's CodeReview site, but judging
by how frequently PyGame-related questions get answered on StackOverflow, I
think that's probably futile.

I don't see any reason why you can't get help on this list, especially if
you make your example on the smaller side.

You might also look at the PyGame IRC channel.

Ian​

Re: [pygame] mystery examples in pygame tutorial

[Ian Mallett]

On Tue, Jun 16, 2015 at 1:19 PM, tom arnall  wrote:

> >>> screen = create_graphics_screen()
>
​Skimming the tutorial and the sections around it, I think it's probably
pseudocode. A number of other functions are too. In this case, I think it's
probably just:

def create_graphics_screen():
return pygame.display.set_mode((800,600))
create_screen = create_graphics_screen

Ian​

Re: [pygame] Mailing List Discard Tweak

[Ian Mallett]

On Sat, Jun 13, 2015 at 2:13 PM, Philip Le Riche 
wrote:

> The only snag with sending reject replies is that it's then open to
> abuse. If I took a dislike to someone (not a subscriber), I could send
> hundreds of emails to the list, spoofing his email address as the
> sender. He'd then get his inbox swamped.
>
​I disagree, and cite precedent in use by other mailing lists. If the
targeted user is on the mailing list, there is no rejection notice. If not,
then the attack is no different from any of the related variety of
backscatter mailer exploits.

I personally subscribe to the view of RFC 5321
:
*As discussed in Section 7.8 and Section 7.9 below, dropping mail without
notification of the sender is permitted in practice. However, it is
extremely dangerous and violates a long tradition and community
expectations that mail is either delivered or returned. . . . silent
dropping of messages should be considered only in those cases where there
is very high confidence that the messages are seriously fraudulent or
otherwise inappropriate.*

Re: [pygame] image window disappears

[Ian Mallett]

On Fri, Jun 12, 2015 at 9:30 PM, tom arnall  wrote:

> thanks for yr response. is there no other way to get image to stay?
>
​If you mean for the window to stay open, then no, there is no other way.
The main loop (and the event handling within) provides for your control
over the window. Whatever would you want with a window with which you could
not interact in any way?

Re: [pygame] image window disappears

[Ian Mallett]

This is the message I sent at 16:56 today (5 minutes after the OP); eaten
silently by the mailer​
​
 (see thread [Mailing List Discard Tweak]). I would appreciate the list's
confirmation of this email as a test.

---

On Fri, Jun 12, 2015 at 4:51 PM, tom arnall  wrote:

> import pygame, sys
> from pygame.locals import *
>
> # set up pygame
> pygame.init()
>
> # set up the window
> windowSurface = pygame.display.set_mode((500, 400), 0, 32)
> pygame.display.set_caption('Hello world!')
>
None of these are blocking calls, so if there is the entire script, Python
should exit, taking PyGame (and the window) with it.

So, to clarify, are you omitting a main loop in your sample?

Ian

[pygame] Mailing List Discard Tweak

[Ian Mallett]

Hi all,

I use GMail as my mailer client. The email associated with this
account is *geometriangmail.com
*. However, I use GMail to send from my personal
email *iangeometrian.com
* (and this is the default). I am subscribed to the
mailing list under the *first*.

It seems that the pygame mailing list silently rejects emails from
addresses that are not registered, to the effect that emails from my
personal email are silently discarded. The effect is that I have been
having one-sided conversations with myself for years, every time I forget
to use *geometriangmail.com *.

*I propose that messages from emails not subscribed to the list be rejected
with a message informing the sender of such*.

I have unsubscribed the GMail address and subscribed the personal address,
fixing the problem, hopefully. However, I still recommend the above action.

Thanks,
Ian

Re: [pygame] Install documentation is down?

[Ian Mallett]

On Mon, Apr 6, 2015 at 10:07 AM, Eryn Wells  wrote:

> I've been trying to find information about how to install Pygame. I'm
> getting a 404 error when I try to access the install documentation at
> http://www.pygame.org/install.html . Is anyone else seeing  this?
>
​Confirmed; this page is a broken link from
http://www.pygame.org/download.shtml

For installation, I've found the WHL packages from the linked page best
, although the downloads
on that page should work and there was some recent activity on compilation
instructions on the Wiki

​.​


Ian​

>

Re: [pygame] Pygame non-MPEG1 video options?

[Ian Mallett]

​I sent a message, but looking at the archives it appears the PyGame server
silently rejected it. Trying again.

I had a similar problem for drawing over videos; I solved it by using VLC
in this small open-source project
.

Re: [pygame] New tutorial for Pygame beginners: Balloon Ninja

[Ian Mallett]

On Sun, Mar 3, 2013 at 6:02 PM, Sam Bull  wrote:

> On Sun, 2013-03-03 at 08:00 -0900, Eric Matthes wrote:
> > I would appreciate any feedback about the tutorial, both so that I am
> > teaching students good practices, and so that it is a decent resource
> > for anyone who comes across it.
>
> Seems like a decent tutorial. I like the way it introduces only small
> parts in each section, should be easy to work through.
>
I read a little bit. It could use some further revisions, but overall, it
does demonstrate decent Python/PyGame programming practices.

Re: [pygame] Fonts

[Ian Mallett]

Put it into some data folder relative to your project, not inside the
PyGame system folder.

Re: [pygame] Alternate to graphics modules

[Ian Mallett]

On Thu, Feb 7, 2013 at 5:29 PM, Greg Ewing wrote:

> Ian Mallett wrote:
>
>> At some level, you need to interface with the graphics drivers. Since
>> Python is an abstraction layer over C, this means either writing in C (not
>> Python), or using a package that does that for you.
>>
>
> Not necessarily -- you can use ctypes to wrap a C library.
>
Yes. In this case, you're creating your own package.

The point is that you need to go through some kind of middle layer. Python
code, by definition, does not interface directly with anything--you must go
through some library/package--whether it is a built-in within Python's
runtime, a 3rd-party distribution, or a wrapper you make around existing C
functionality.

Ian

Re: [pygame] Alternate to graphics modules

[Ian Mallett]

On Wed, Feb 6, 2013 at 4:43 PM, Richard Jones wrote:

>  > For a package that gives you low-level access, my recommendation is
> > PyOpenGL. It's lower-level than PyGlet and much cleaner, I think.
>
> That's not quite right. PyOpenGL and pyglet exist at about the same
> level architecturally. PyOpenGL does not provide an OpenGL context -
> you need another library (like pyglet or pygame) to provide that.
>
While I have not used PyGlet extensively, that is not my impression.

PyGlet, for example, provides a dedicated shader class, and an entire
rendering backend. I do recall that there is some direct exposure of some
OpenGL calls (particularly OpenGL 2 callbacks), but by and large I have
seen PyGlet applications that do not touch a single line of GL.

Conversely, PyOpenGL is a "binding" of raw OpenGL, with facilities for
extensions. You will need to use these OpenGL calls to accomplish anything.
There are a few helper classes (e.g. for VBOs), but the most complicated
thing it provides IIRC is a testing framework.

At any rate, I feel like PyGlet is a binding on top of OpenGL, but it's not
meant to be used that way. While you can make direct GL callbacks, PyGlet
encourages the use of their abstracting classes built on top of it.
Whereas, PyOpenGL is just a binding, with maybe a few higher level classes
added on top of it for convenience.

Ian

Re: [pygame] Alternate to graphics modules

[Ian Mallett]

On Wed, Feb 6, 2013 at 4:20 PM, Richard Jones wrote:

> You'd better start writing then :-)
>
At some level, you need to interface with the graphics drivers. Since
Python is an abstraction layer over C, this means either writing in C (not
Python), or using a package that does that for you. You *must* use some
package in Python to do low-level graphics--whether you write it yourself
or no.

For a *package* that gives you low-level access, my recommendation is
PyOpenGL. It's lower-level than PyGlet and much cleaner, I think.

Ian

Re: [pygame] Build instructions for pygame

[Ian Mallett]

On Wed, Feb 6, 2013 at 10:10 AM, Paul Vincent Craven
wrote:

> Not much there in the wiki. Instructions are for mingw, and Visual Studio
> 2003, neither one of which I think it compiles under. I'd love to by able
> to get a good compile, but the dependencies are killing me. I can compile
> and have it find most of the dependencies, but when I try to run it I get a
> missing dll error or it will hang or something.
>
> Paul Vincent Craven
>
The world is onto Visual Studio 2012 now, and 2008 has been a standard
compilation platform for even ancient packages. The oldest I've *ever* seen
being used, in recent memory, is VS 2005.

Perhaps the compilation instructions should be updated. Using a compiler
that's a decade out of date as "current" is somewhat regrettable, methinks.

Ian

Re: [pygame] PyGame website

[Ian Mallett]

Hey all,

Are we making progress with this? I would like to see the PyGame.org
website improved, and I would like to help!

Ian