Re: [pygame] question about transparent surfaces and alpha-value

2008-09-24 Thread claudio canepa
sorry, the blit musty be

tmp.blit(surf, (0,0), surf.get_rect(), BLEND_RGBA_MULT)

--

claxo

On Wed, Sep 24, 2008 at 2:58 AM, claudio canepa [EMAIL PROTECTED] wrote:


 something like:

 def get_alphaed( surf, alpha):

 tmp = Pygame.Surface( surf.get_size(), SRCALPHA, 32)

 tmp.fill( (alpha,alpha,alpha,alpha) )

 tmp.blit( surf, (0,0), surf.get_size(), BLEND_RGBA_MULT)

 return tmp

 (untested)

 --

 claxo



Re: [pygame] question about transparent surfaces and alpha-value

2008-09-24 Thread kschnee
 Hi List,
 just want to make sure i got this right, please correct me if i'm wrong:
 
 if i have a jpg-file, i can set the transparency with the command 
 
 pygame.Surface.set_alpha(alpha-value).
 
 but if i hav a .png-file with already transparent background, i can not
 set the alpha-value of that picture ? Of the visible pixels of
 that .png-file, of course.
 
 Here is a demo , what i want is the second face (right) also to become
 more and more transparent:
 
 http://www.spielend-programmieren.at/wiki/doku.php?id=code:colordemo1.py


If I understand correctly, one thing you could try is to fill the
background with a solid color such as bright purple, then use
set_colorkey(), like this:

image = pygame.image.load(filename)
image.set_colorkey((255,0,255))

I think you can then set an alpha value for the image while still having
the pixels marked as transparent not show up at all. Use an extreme and
unlikely color like (255,0,255) to reduce the chance that you'll
accidentally make the wrong parts of your image transparent.



Re: [pygame] question about transparent surfaces and alpha-value

2008-09-24 Thread Horst JENS
thanks for the advice, i updated the code at 
http://www.spielend-programmieren.at/wiki/doku.php?id=code:colordemo1.py


-Horst




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [pygame] Good code for text wrapping?

2008-09-24 Thread René Dudfield
hey,

would you like to work with me in creating something for inclusion in pygame?

This would mean working out a simple api, making docs, examples, and unittests.

Something basic that we can have a look at, for adding the most easy
and useful features.  We can try and avoid most of the tricky issues
for now.



If anyone else is interested, we can set up a google host page or
something to work on it?

cheers,




On Tue, Sep 23, 2008 at 10:11 PM, Charlie Nolan [EMAIL PROTECTED] wrote:
 A fair amount of this is already in that file, down in print_string
 and print_line.  (You're welcome to as much of the file as you like,
 but I'd strongly suggest you look into refactoring it.  It's good
 enough for one isolated project, but probably not up to library
 quality.)

 - aligning text, left, right, center etc.
 - vertical alignment... top, bottom, center.
 - text color
 Check.

 - each part of text having a separate font/attributes.  So you can
 then do words with bold, italics etc.
 Everything but the font is easy to extend (the font's ugly to do, and
 probably overkill).  I've already got underline in there.  Might want
 to swap the style list for a style dict/object, though, to avoid
 degenerating into positional hell.

 - selecting text.  Based on mouse click, which letter and word does it
 collide with?
 I've already got the baseline in for this, by way of EditableText's
 handle_click function.

 - breaking words (word-break), so it can add a long word like
 complexifcation as complexif-\ncation

 More-or-less present.  Right now, it'll break on any character,
 without adding a hyphen, but extending it shouldn't be hard.  Of
 course, if you want intelligent hyphenation, that's an icky can of
 worms all by itself.

 - justify text.
 - letter spacing
 - line spacing
 - word spacing
 - indenting
 - padding around text.
 Somewhat annoying, mostly because they affect selecting text.  With
 this many weird things, it might be a good idea to look for a way to
 merge the layout and select code, possibly by storing a map as you lay
 things out.

 - flowing around areas...
 - eg( place an image, and the text flows around it)
 - example here:  http://www.csstextwrap.com/example_for_demo.php
 This one gets a bit ugly, and also runs into the layout/select
 duplication mentioned above.

 - splitting text up into 'pages',
 - different sized pages or Rects could be useful too.
 Not too hard.  When the printing clips off the end of the available
 area, you move on to the next one.

 - scrolling text.
 Are you thinking marquee or scrollbar?  Either one seems out of scope.

 - text render method.
 Not sure we need/want this, but it would be easy enough to add.  You'd
 also want to add a way to replace the related methods (metrics,
 get_linesize, etc.).  My main worry here is scope creep.  Actually, if
 you're going into this much depth, wouldn't you just subclass
 pygame.Font?

 ---

  - text flow other than left-right (right-left, mixed, top-down)
 I think this really belongs upstream in SDL, assuming it's not there
 already.  Once it renders a string correctly, this is just another
 easy layout/select issue.

  - support for non-letter fonts (e.g. button glyphs for help text) --
  although I suppose you could handle it by something you described,
  flowing text around images, if the images could be floated as well
 I'm pretty sure you can do this already.  As long as you have the
 font, you can render whatever you like in it.

  - support for non-breaking spaces and hyphens
 NBSP is handled correctly.  Hyphens fall under breaking words properly.

  - proper handling of line-breaking in different languages (e.g.,
  French inserts a space or two between the last letter of a sentence
  and a final exclamation point, don't want to break there, some
  languages consider certain combinations of letters to really be only
  one, can't break in between them, etc.)
 Most of this falls under word breaks again.  French's pre-! space is
 kinda annoying, unless they already use an NBSP.

  - proper support for full Unicode fonts
 I haven't run into anything broken here.  DejaVu seems to render
 perfectly well.  Most of this is up to SDL, though we'd have to pay
 attention to control characters (switching RTL/LTR without warning
 does ugly things).

 ---

 Most of this isn't too bad to add to what I've already got, but you'd
 want to be really careful with adding them one-by-one.  It'd be really
 easy to get scope creep or just turn the entire thing into hacks of
 hacks.

 In some ways, I'd be relieved if you didn't use my code, because it's
 already held together with duct tape and baling wire.  Unfortunately,
 I'm not sure there *is* a sane way to handle this stuff, there are
 just too many special cases.

 I think the important thing is to get something in soonish that
 handles as many of the common cases as we can.  We don't want this
 degenerating into something that will come out shortly after Duke
 Nukem Forever.