Mike,
I don't think the blit to another surface is doing what you think it's doing.
Run your code again, but this time filling the screen to something
other than black, and you'll see what I mean.
List,
I think this is the 3rd time I've seen someone emailing this list
trying to figure out how
Jeff Cagle wrote:
Jasper wrote:
More specifically, it's tricky to write tests for GUIs and real time
applications, or at least I don't know of any good python tools for
doing so.
I've put some thought into a robust GUI testing framework, but how
exactly to go about it isn't a simple matter.
Got it. You need to blit the rendered text to a new surface then
change the alpha value of that new surface before blitting it to screen.
import pygame
pygame.init()
screen = pygame.display.set_mode((640,480), pygame.SRCALPHA)
screen.fill((0,0,0))
myFont = pygame.font.Font(None, 30)
nonTransp
Good call Luke. Removing antialiasing did indeed result in a surface
with a usable set_alpha component.
However, I'd really like to have antialiased text. Inserting
'semiTransparent.convert_alpha()' between lines 9 and 10 didn't seem
to help either.
On 5-Sep-07, at 9:18 PM, Luke Paireepin
Mike Lawrence wrote:
Hi all,
Apologies for the seemingly newb help request but I can't seem to
figure out how to vary the alpha value of rendered font surfaces. Here
are my attempts thusfar:
import pygame
pygame.init()
screen = pygame.display.set_mode((640,480), pygame.SRCALPHA)
screen.fill(
Hi all,
Apologies for the seemingly newb help request but I can't seem to
figure out how to vary the alpha value of rendered font surfaces.
Here are my attempts thusfar:
import pygame
pygame.init()
screen = pygame.display.set_mode((640,480), pygame.SRCALPHA)
screen.fill((0,0,0))
myFont = p
Richard Jones wrote:
On Wed, 5 Sep 2007, pistacchio wrote:
maps are certainly a very common feature in game development. the
easiest way to trace maps (and the one that i've used in other languages
in tha past) is to use multidimensional arrays. so, a tile-map, can be
stored and worked on as
Lenard Lindstrom wrote:
Luke Paireepinart wrote:
In single process mode it will lock up the editor, but frees it when
the window Pygame window closes.
But if you have an error in your code, the window won't exit, and the
editor won't unfreeze. That's the problem he's having.
-Luke
This
Luke Paireepinart wrote:
In single process mode it will lock up the editor, but frees it when
the window Pygame window closes.
But if you have an error in your code, the window won't exit, and the
editor won't unfreeze. That's the problem he's having.
-Luke
This works:
import pygame
fro
In single process mode it will lock up the editor, but frees it when
the window Pygame window closes.
But if you have an error in your code, the window won't exit, and the
editor won't unfreeze. That's the problem he's having.
-Luke
pistacchio wrote:
Lenard Lindstrom ha scritto:
The IDLE problem isn't really a problem as such. Being an
interactive session, the interpreter doesn't shut down when the
Pygame code finishes. So pygame.quit is not called and the window
remains visible. Restarting the interpreter or adding an e
pistacchio wrote:
Luke Paireepinart ha scritto:
ght-click and choose edit with IDLE.
instead, open IDLE from the start menu and load your files from
within IDLE (should be in 'recent documents')
there's some problem with IDLE and using the separate subprocess that
only comes up when you right
12 matches
Mail list logo
