Re: [pygame] I need the Noob wiki

[Jeff Welch]

OK, I'm not getting past your step #1.

Can someone give me a suggestion about this error?


Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> import pygame
Traceback (most recent call last):
  File "", line 1, in 
import pygame
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pygame/__init__.py",
 line 95, in 
from pygame.base import *
ImportError: dynamic module does not define init function (PyInit_base)
>>> 

-Jeff Welch

On Jun 2, 2012, at 1:44 PM, Ian Mallett wrote:

> Hey,
> 
> To check whether PyGame is installed, in IDLE, type:
> import pygame
> from pygame.locals import *
> pygame.init()
> None of these lines should throw errors.  If they do, you have an install 
> problem.  To make a basic window, type:
> surf = pygame.display.set_mode((400,200))
> If a window pops up, great!  Then, to get rid of that window, type:
> pygame.quit()
> 
> As for basic tutorials, Googling "PyGame tutorial" yields this simple example 
> on the second link:
> http://www.pygame.org/docs/tut/intro/intro.html
> . . . and this one on the third:
> http://www.pygame.org/docs/tut/chimp/ChimpLineByLine.html
> I personally find that the best way to learn is to just try to make 
> something.  For PyGame for example, making a Pong clone is a classic first 
> project.  Just find some example code and take wild guesses at what 
> everything does.  If you get stuck there's always this list.
> 
> Finally, as for downloading and running on PyGame.org, simply click on one of 
> the projects at right, and then follow the links.
> 
> Ian

Re: [pygame] Monospaced fonts are meant to be mono-spaced, right?

[Weeble]

I've looked into Sam's monospaced font size problems and followed up
in the Ubuntu bug. I think we've discovered unusual behaviour in
FreeType that may or may not be a bug, and hopefully someone on the
FreeType mailing list will respond to my questions over there. I'm
posting back here now to discuss how best to actually achieve the
intended cursor placement using Pygame.

Over in the bug report, Sam says:
> My solution for the labels, which works fine, is to find the rendered length 
> of the first character, then the length of the first two characters, then the 
> length of the first 3 characters and so on. Storing all these values allows 
> me to work out the correct position.

> Because there's quite a bit of repetition, this can take a little bit of CPU 
> time. My only concern with the input box, is that it needs to recalculate all 
> of this, everytime the user types something, and it is designed for use in 
> games where a fraction of a millisecond can still be important to keep the 
> game running smoothly.

In all the examples so far, you've been using
font.render("blah"...).get_size(). Do you know there's a
font.size("blah") too? That should do the calculations quickly without
actually doing the rendering. I think that should be fast enough for
your needs. (See the end of this email for a short example.)

I've done some experiments to try to understand how the font metrics
relate to the dimensions of a rendered piece of text in the general
case, not just for monospaced fonts. I thought it might be useful to
others.

Firstly, any text string rendered by a font will always have a height
of font.get_height(). It seems that this is always
1+font.get_ascent()+font.get_ascent(). It doesn't matter what text you
render, even it it's entirely whitespace, it will always be the full
height.

For the width, you need to look at the metrics of each character in
the string, as returned by font.metrics(). These are xmin, xmax, ymin,
ymax and advance, as shown in the diagram here:
http://www.libsdl.org/projects/SDL_ttf/docs/SDL_ttf.html#SEC38

The advance is the easiest to understand. It's the horizontal distance
the text cursor moves from one side of the character to the other.
xmin is the distance from the left cursor position to the leftmost
part of the outline. xmax is the distance from the left cursor
position to the rightmost part of the outline.

Most of the time, the width of a string of text is the sum of the
advance widths of the characters. But some characters can overhang,
which happens a lot in italic fonts. If the first or last characters
overhang, the width of the string will be longer. Here's a diagram:

https://lh3.googleusercontent.com/-hxXPX7kxCbs/T8q0jF08loI/DJk/72dsWzp7ATw/s877/font_rendering.png

The black bars under the letters are their advance widths. The red
highlighted areas are where characters overhang - they have parts
wider than their advance width. (The blue highlighted areas are where
the characters are narrower than their advance width - they don't
matter much.) The width of the string of text is the sum of the
advance widths *plus* the overhang of the first and last characters.

(Actually, that's not *entirely* true. I think long strings can also
vary a few pixels due to accumulated rounding and/or kerning, but
that's a much smaller effect than the overhang.)

Suppose you have rendered the word "offer" as shown in the diagram,
and you want to draw a cursor between the two "f"s. If you calculate
the cursor position based on the width of the text on the left - "of"
- you will find that the cursor is too far to the right. It will end
up right in the middle of the second "f" because the first "f"
overhangs it so much. What you actually want to do is let the font
library calculate the width of "of", then subtract the right overhang
of the last letter, "f". The right overhang is "xmax - advance".

To get the very best positioning of a text cursor, I think you want to
calculate the width of the string on its left, then *subtract* the
overhang of the character immediately to the left, if any. Here's a
demo: http://pastebin.com/PKm8ChxV

Hope this information is useful to someone!

[pygame] Unsubscribe

[Rob]

Re: [pygame] Improved Sprites System - Call for Suggestions

[Christopher Night]

On Sat, Jun 2, 2012 at 1:50 PM, DR0ID  wrote:

>  On 02.06.2012 16:46, Christopher Night wrote:
>
> On Fri, Jun 1, 2012 at 2:29 PM, DR0ID  wrote:
>
>> On 01.06.2012 15:29, Sagie Maoz wrote:
>>
>>> 2. Setting a sprite's anchor points for handling in movement, animation,
>>> collision etc.
>>> 5. New visual attributes for sprites:
>>>- Rotation angle
>>>- Scale
>>
>>  2. the sprites anchor point should be just an offset, not limited to
>> 'topleft', 'midtop', 'topright',... and the other rect attributes
>>
>
>  I want to be able to specify "center" or "midbottom" for the sprite
> anchor without knowing the image's dimensions. And I want that anchor point
> to remain in the appropriate place even if the image is rotated, scaled, or
> flipped. I'm not sure that an offset would accomplish this, but if so, then
> that's okay.
>
>  -Christopher
>
>
> Hi
>
> I agree, what I suggested is that both things should be possible: a
> general offset and/or specifying 'center' or 'midbottom' or
>
> I'm not sure right now how the math to maintain the point at the
> appropriate place. Maybe this needs some more specification for the
> different transformations (rotation, flip, scale).
>

Well the desired behavior is pretty straightforward to me. Say I specify a
sprite's anchor as "midbottom", and the sprite's image has a single orange
pixel at its mid-bottom. Then if I ask to draw the sprite at (200, 100),
then that orange pixel should wind up at (200, 100) no matter how the
sprite is transformed (maybe one pixel off because of rounding). The math
shouldn't be too hard to work out from that.

-Christopher

Re: [pygame] Improved Sprites System - Call for Suggestions

[Valentine Blacker]

One little thing; as far as item 9. goes, this might be implied, but it
would be great if it was set up to easily handle subsurfaces (ie
spritesheets) as well as individual images.

On Sat, Jun 2, 2012 at 1:08 PM, Sagie Maoz  wrote:

> Hi all,
>
> Thanks so much for all of the comments and suggestions. This is extremely
> helpful for my project at this stage.
>
> I admit I'm not too educated about the whole subject, so let me know if
> any of my answers below need further research in your opinion.
>
> Regarding adding GUI elements (David's suggestion) - I can see how
> important that would be, but I'd like to focus on basic game graphics for
> now. Also, there's another GSoC project by Sam Bull that approaches a GUI
> framework for Pygame.
>
> As for collision detection (Nicholas' and DR0ID's emails): I agree with
> DR0ID's concerns about maintaining a clear scope for the project, and I can
> understand that collisions are more the engine's job than the sprite
> classes. However, as the current Sprite module includes many of the
> functions related to that, I thought I could get into that as part of my
> work.
> I'm guessing that implementing a basic and naive code wouldn't be too
> hard, but the question remains would doing that be an elegant design.
> I want to research how this kind of features is done on similar libraries.
> I would also love to get your thoughts on that. So this is still an open
> question for now.
>
> Aggregated sprites: I think the use case DR0ID has mentioned is good
> enough for implementing that. I'm thinking about writing the aliens.py game
> so that the aliens are a group of sprites moving together, while each one
> could have a different behavior when needed.
>
> Dirty rendering: Again, this doesn't seem to me as something that's too
> difficult to implement, and would definitely help any non-scrolling game,
> which I think is a pretty solid use case.
>
> I gather that the most requested features are probably:
>
> 1. Better positioning, particularly using float values.
> 2. Anchor points.
> 3. Visual attributes.
> 4. A smarter layers system.
> 5. Sprite picking.
>
> I will research each of these during the week.
>
> If you have any more comments or additions please do reply to this thread.
> I'll also be idling in #pygame most of the time and would love to chat.
>
> DR0ID - I'll be happy to set a time to chat and learn more about all of
> your suggestions.
>
> Thanks again,
>
> --
> Your friend in time,
> Sagie Maoz
> sa...@maoz.info // +1 (347) 556.5044 // +972 (52) 834-3339
> http://sagie.maoz.info/ http://n0nick.net/
>
> /* simba says roar! */
>
> On Saturday, June 2, 2012 at 5:46 PM, Christopher Night wrote:
>
> On Fri, Jun 1, 2012 at 2:29 PM, DR0ID  wrote:
>
> On 01.06.2012 15:29, Sagie Maoz wrote:
>
> 2. Setting a sprite's anchor points for handling in movement, animation,
> collision etc.
> 5. New visual attributes for sprites:
>- Rotation angle
>- Scale
>
> 2. the sprites anchor point should be just an offset, not limited to
> 'topleft', 'midtop', 'topright',... and the other rect attributes
>
>
> I want to be able to specify "center" or "midbottom" for the sprite anchor
> without knowing the image's dimensions. And I want that anchor point to
> remain in the appropriate place even if the image is rotated, scaled, or
> flipped. I'm not sure that an offset would accomplish this, but if so, then
> that's okay.
>
> -Christopher
>
>
>

Re: [pygame] Improved Sprites System - Call for Suggestions

[DR0ID]

On 02.06.2012 16:46, Christopher Night wrote:
On Fri, Jun 1, 2012 at 2:29 PM, DR0ID > wrote:


On 01.06.2012 15:29, Sagie Maoz wrote:

2. Setting a sprite's anchor points for handling in movement,
animation, collision etc.
5. New visual attributes for sprites:
   - Rotation angle
   - Scale 


2. the sprites anchor point should be just an offset, not limited
to 'topleft', 'midtop', 'topright',... and the other rect attributes


I want to be able to specify "center" or "midbottom" for the sprite 
anchor without knowing the image's dimensions. And I want that anchor 
point to remain in the appropriate place even if the image is rotated, 
scaled, or flipped. I'm not sure that an offset would accomplish this, 
but if so, then that's okay.


-Christopher


Hi

I agree, what I suggested is that both things should be possible: a 
general offset and/or specifying 'center' or 'midbottom' or


I'm not sure right now how the math to maintain the point at the 
appropriate place. Maybe this needs some more specification for the 
different transformations (rotation, flip, scale).



~DR0ID

Re: [pygame] I need the Noob wiki

[Ian Mallett]

Hey,

To check whether PyGame is installed, in IDLE, type:

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

None of these lines should throw errors.  If they do, you have an install
problem.  To make a basic window, type:

surf = pygame.display.set_mode((400,200))

If a window pops up, great!  Then, to get rid of that window, type:

pygame.quit()


As for basic tutorials, Googling "PyGame tutorial" yields this simple
example on the second link:
http://www.pygame.org/docs/tut/intro/intro.html
. . . and this one on the third:
http://www.pygame.org/docs/tut/chimp/ChimpLineByLine.html
I personally find that the best way to learn is to just try to make
something.  For PyGame for example, making a Pong clone is a classic first
project.  Just find some example code and take wild guesses at what
everything does.  If you get stuck there's always this list.

Finally, as for downloading and running on PyGame.org, simply click on one
of the projects at right, and then follow the links.

Ian

[pygame] I need the Noob wiki

[Jeff Welch]

Hello,

I see the discussion here is pretty high level, but I'm hoping someone can 
direct me to some very low level help.

I'm brand new to both Python and Pygame.

I'm working on a Mac 10.6.8, and I found some instructions for building the 
install here.  http://programming.itcarlow.ie/PyGameInstall.pdf

After following those as best I could I found that I needed to update Tcl to 
8.5.11, and I did that.

It seems that I have a working Python 3.2.3 IDLE.  Interactive mode works fine 
on screen.  However, I am having trouble running example pygame programs.   I'm 
not really sure how to see if Pygame is working.

So, I probably need some install troubleshooting tips, and also some basic 
instructions on how one downloads a Pygame game and runs it.  

Thank you!

Jeff Welch

Re: [pygame] Improved Sprites System - Call for Suggestions

[Sagie Maoz]

Hi all,

Thanks so much for all of the comments and suggestions. This is extremely 
helpful for my project at this stage.

I admit I'm not too educated about the whole subject, so let me know if any of 
my answers below need further research in your opinion.

Regarding adding GUI elements (David's suggestion) - I can see how important 
that would be, but I'd like to focus on basic game graphics for now. Also, 
there's another GSoC project by Sam Bull that approaches a GUI framework for 
Pygame.

As for collision detection (Nicholas' and DR0ID's emails): I agree with DR0ID's 
concerns about maintaining a clear scope for the project, and I can understand 
that collisions are more the engine's job than the sprite classes. However, as 
the current Sprite module includes many of the functions related to that, I 
thought I could get into that as part of my work.
I'm guessing that implementing a basic and naive code wouldn't be too hard, but 
the question remains would doing that be an elegant design.
I want to research how this kind of features is done on similar libraries. I 
would also love to get your thoughts on that. So this is still an open question 
for now.

Aggregated sprites: I think the use case DR0ID has mentioned is good enough for 
implementing that. I'm thinking about writing the aliens.py game so that the 
aliens are a group of sprites moving together, while each one could have a 
different behavior when needed.

Dirty rendering: Again, this doesn't seem to me as something that's too 
difficult to implement, and would definitely help any non-scrolling game, which 
I think is a pretty solid use case.

I gather that the most requested features are probably:

1. Better positioning, particularly using float values.
2. Anchor points.
3. Visual attributes.
4. A smarter layers system.
5. Sprite picking.

I will research each of these during the week.

If you have any more comments or additions please do reply to this thread.
I'll also be idling in #pygame most of the time and would love to chat.

DR0ID - I'll be happy to set a time to chat and learn more about all of your 
suggestions.

Thanks again, 

-- 
Your friend in time,
Sagie Maoz
sa...@maoz.info // +1 (347) 556.5044 // +972 (52) 834-3339
http://sagie.maoz.info/ http://n0nick.net/

/* simba says roar! */


On Saturday, June 2, 2012 at 5:46 PM, Christopher Night wrote:

> On Fri, Jun 1, 2012 at 2:29 PM, DR0ID  (mailto:dr...@bluewin.ch)> wrote:
> > On 01.06.2012 15:29, Sagie Maoz wrote:
> > > 2. Setting a sprite's anchor points for handling in movement, animation, 
> > > collision etc.
> > > 5. New visual attributes for sprites:
> > >- Rotation angle
> > >- Scale  
> > 2. the sprites anchor point should be just an offset, not limited to 
> > 'topleft', 'midtop', 'topright',... and the other rect attributes
> 
> I want to be able to specify "center" or "midbottom" for the sprite anchor 
> without knowing the image's dimensions. And I want that anchor point to 
> remain in the appropriate place even if the image is rotated, scaled, or 
> flipped. I'm not sure that an offset would accomplish this, but if so, then 
> that's okay. 
> 
> -Christopher 

Re: [pygame] Improved Sprites System - Call for Suggestions

[Christopher Night]

On Fri, Jun 1, 2012 at 2:29 PM, DR0ID  wrote:

> On 01.06.2012 15:29, Sagie Maoz wrote:
>
>> 2. Setting a sprite's anchor points for handling in movement, animation,
>> collision etc.
>> 5. New visual attributes for sprites:
>>- Rotation angle
>>- Scale
>
> 2. the sprites anchor point should be just an offset, not limited to
> 'topleft', 'midtop', 'topright',... and the other rect attributes
>

I want to be able to specify "center" or "midbottom" for the sprite anchor
without knowing the image's dimensions. And I want that anchor point to
remain in the appropriate place even if the image is rotated, scaled, or
flipped. I'm not sure that an offset would accomplish this, but if so, then
that's okay.

-Christopher