>
> The XO should come with a manual that defines those terms, written by
> someone who is a language expert rather than a computing expert. Are
> there any plans in this direction?
>
> - Bert -
>
>
I'm doing the layout for the simple user guide right now. So I can help
structure these once they
To elaborate.. :)
On Dec 8, 2007 11:57 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > Someone mentioned that there will be (or already is?) a prohibition
> > on loading any binaries
>
This is (I assume) some ill-informed hand-waving about Bitfrost, the
security specification. http://w
The Python way is explicit over implicit. pygame.image.load() will
return a surface of the form you actually saved, you must explicitly
convert it to another format if you saved it in a format different than
what you want for blitting.
--Noah
Bernardo Innocenti wrote:
> On 12/09/07 19:51, Roberto
On 12/09/07 19:51, Roberto Fagá wrote:
> I think for now pygame is doing with 16bits at default yet, and I
> wrote wrong, the second parameter from set_mode are the flags, depth
> is the third parameter. I also used 12bits too to test, for games when
> colors don't matter so much can be a good ch
The surf.convert() and .convert_alpha() will do this. It is advised to
always run one of these (depending on if you need per-pixel alphas) on
any image loaded from disk.
--Noah
Bernardo Innocenti wrote:
> On 12/09/07 19:08, Noah Kantrowitz wrote:
>> Unfortunately this is not possible in most game
Just adding, to convert at load time with pygame, just need to use
.convert() on surface object, and it'll convert to the screen surface,
like
surf = load(..)
surf.convert()
I think for now pygame is doing with 16bits at default yet, and I
wrote wrong, the second parameter from set_mode are the f
On 12/09/07 19:08, Noah Kantrowitz wrote:
> Unfortunately this is not possible in most games, as doing them purely
> vector-based is infeasible. A lot of the artwork made for games will be
> standard raster graphics, and will need to be designed for a specific
> screen. If there are changes in the
Last I checked pygame didn't expose the X event source as a file
descriptor, so that anything that used pygame and network had to poll
... is this still a problem? Is there an example activity that solved
that?
--
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Unfortunately this is not possible in most games, as doing them purely
vector-based is infeasible. A lot of the artwork made for games will be
standard raster graphics, and will need to be designed for a specific
screen. If there are changes in the future, they can always be redrawn.
--Noah
Berna
On 12/09/07 18:35, Roberto Fagá wrote:
> Another good option to optimize games in PyGame on XO is to reduce the
> depth of the colors on:
> window = pygame.display.set_mode((400, 225), 16)
Isn't 16bpp the default?
The X display runs at 16bpp, so using any other depth causes
useless and very expe
Chris Ball wrote:
>> We figured out, a combination of pygame.event.wait() and
>> pygame.event.get() very good. That's the demo code; it takes less
>> than 4% cpu (0.3% - 1.7% here):
>
> That's cool. Note that this won't work for any pygame activity that
> wants to do something in the b
Hello Chris
Nice work! Anyway, you are only locking in the event manager, this is
great to games which doesn't need to render each frame.
A good option to use, when you need to process something in the
background, is to use the pygame.time.Clock(), like:
MAXFPS = 20 #for example
clock = pygame.ti
Hi,
> Hi! Mcfletch and I have been talking about the heavy cpu-load of
> the wiki's pygame demo: 99%; and how to reduce it.
> We figured out, a combination of pygame.event.wait() and
> pygame.event.get() very good. That's the demo code; it takes less
> than 4% cpu (0.3% - 1.7% her
Hi!
Mcfletch and I have been talking about the heavy cpu-load of the wiki's
pygame demo: 99%; and how to reduce it.
We figured out, a combination of pygame.event.wait() and
pygame.event.get() very good. That's the demo code; it takes less than
4% cpu (0.3% - 1.7% here):
import sys
import pyga
On 12/09/07 13:03, Bernardo Innocenti wrote:
> On 12/06/07 00:58, Albert Cahalan wrote:
>
>> It only gets bad when the RPM is defective, as is
>> rather common. Getting X11 headers will drag in libGL.
>
> I could fix this in the OLPC branch of libX11.
The nasty dependency was actually in xorg-x1
On 12/06/07 00:58, Albert Cahalan wrote:
> It only gets bad when the RPM is defective, as is
> rather common. Getting X11 headers will drag in libGL.
I could fix this in the OLPC branch of libX11.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - ht
1. Project name : xo-get
2. Existing website, if any :
http://www.olpcaustria.org/mediawiki/index.php/Xo-get
3. One-line description : A simple .xo-package installer / manager
4. Longer description : Search & download .xo-bundles via a public
repository; install and remove
On Dec 9, 2007, at 10:41 , Andi wrote:
> Hello List,
>
> is there any translating policy that I have oversight ?
>
> If yes, point me someone to that policy please.
>
> If no, what is the official intention by the majority of the
> translators
> and/or decision-makers about using native terms as
Hello List,
is there any translating policy that I have oversight ?
If yes, point me someone to that policy please.
If no, what is the official intention by the majority of the translators
and/or decision-makers about using native terms as much as possible vs.
using the most commonly used englis
19 matches
Mail list logo
