Re: [pygame] Display-less PyGame

[Ethan Glasser-Camp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
> I've switched engines repeatedly too. If I can make the one I'm working on
> be halfway decent, it might be worth offering to people (free). Whether
> it's useful depends on what people actually want from an engine. What sort
> of tradeoff would you want to see between ease of use for the newcomer
> versus flexibility?

I may be out of line here, and of course you should make whatever you
want, and I look forward to seeing it, but it's my impression that the
Free Software gaming community is already very well-stocked on RPG
engines of varying states of completeness. I'd much rather see a game
that used any of them.

Failing that, I'd like to see an engine that was so superior to all
the ones out there, that nobody ever thought "Man, I think I'll make
another free RPG engine" :)

(I know, I know, people make engines to learn from, and to have fun,
rather than just to have a working engine. But I can complain, can't I?)

Ethan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGehyXhRlgoLPrRPwRAnZCAJ9Dvl7QMOBwYMFlSaAdqLNX4BZAHgCgioDf
JKMInnP6zoX6oqs+Qt6YtxY=
=OEMX
-END PGP SIGNATURE-

Re: [PATCH] Re: [pygame] Smooth Scaling (pygame.transform.smoothscale)

[Laura Creighton]

If you are on a BSD or linux system you will have a file
/proc/cpuinfo which can tell you what sort of CPU you have and
whether it has MMX support or not.  I don't know where Windows
keeps such information.  (And really old unix-and-unix-like
systems don't have this file, but they don't have MMX either,
so you are all set.)

Laura

In a message of Wed, 20 Jun 2007 19:30:07 EDT, Richard Goedeken writes:
>That's a good plan, but I haven't been able to find a good way to
>determine at compile time whether or not the compiler supports MMX.  You
>could always dump out a small test file and compile it to test for
>errors, but I was hoping to find something better like running gcc with
>a magical parameter or testing for a magical preproc definition.  Are
>you aware of any 'cleaner' ways of handling this detection?
>
>Richard
>
>
>René Dudfield wrote:
>> Hi,
>> 
>> that's good :)
>> 
>> SDL does it by compiling the mmx stuff in if the compiler supports it.
>> Then it has runtime checks to see if the cpu supports it.  SDL also
>> has a configure flag, which you can use to tell it not to even try
>> compiling mmx stuff.
>> 
>> So if the compiler doesn't support it, the C version is used.
>> If the compiler supports it, and the runtime cpu detection finds mmx,
>> then the mmx version is used.
>> 
>> 
>> 
>> On 6/20/07, Richard Goedeken <[EMAIL PROTECTED]> wrote
>:
>>> Rene,
>>>
>>> I would be willing to add the CPU detection functions but I can't thin
>k
>>> of how it could be implemented in a useful way.  The compile-time chec
>ks
>>> have to stay in because trying to compile the 64-bit code on a 32-bit
>>> architecture, or the 32-bit MMX code on a PPC or similar, will cause
>>> compile-time errors.  So it's given that if someone is running an i386
>,
>>> PPC, Sun, Arm, etc, they will get the C code.  If they're running i686
>,
>>> they'll get the 32-bit MMX, and for x86_64 they'll get the 64-bit MMX.
>>>
>>> So, the dilemma is that whatever build a user is running, the code is
>>> pretty much guaranteed to work on their CPU.  If someone is running th
>e
>>> i686 build on a 486 or something silly like that they'll probably have
>>> bigger problems.  We could allow someone to 'downgrade' and run the C
>>> code when their CPU supports MMX, but what's the point?
>>>
>>> Regards,
>>> Richard

Re: [pygame] Display-less PyGame

[kschnee]

On Thu, June 21, 2007 3:11 am, Charles Joseph Christie II wrote:
> ika looks pretty awesome... But now I'm all "I want to use pygame but
> this looks really interesting but I want to learn to make my own game
> engine in pygame but this one is already great bu *head asplodes"
>
> Crap. I don't know what I want to use now :P

I've switched engines repeatedly too. If I can make the one I'm working on
be halfway decent, it might be worth offering to people (free). Whether
it's useful depends on what people actually want from an engine. What sort
of tradeoff would you want to see between ease of use for the newcomer
versus flexibility?

Verge (ika's ancestor) used 2D tiles but, when I played it years ago,
seemed pretty limited because it was missing basic things like inventory,
menus and a battle system. The focus seemed to be on making RPGs in the
style of "Final Fantasy VI," a good one to imitate, but people were able
to adapt it for some other things.

ZZT and Megazeux were "text mode" games, but I meant that they used ASCII
(or modified ASCII) _as_ graphics. Especially with Megazeux, the later of
the two, this worked surprisingly well.

One other thing: I checked lostgarden.com again recently and saw that that
writer has released two new sets of free graphics that might be of
interest to Pygame users: some cartoon tiles and space graphics.

Re: [pygame] Questions about surface with alpha channel

[Peter Shinners]

John Eriksson wrote:

But can you pass an RGBA value to the fill method? In the document it
says RGB I think.


All the "RGB" type arguments can accept RGBA. If you only pass RGB then 
the alpha is assumed to be opaque.

Re: [pygame] Questions about surface with alpha channel

[John Eriksson]

Hi,

Thanks for your answer.

But can you pass an RGBA value to the fill method? In the document it
says RGB I think.

Best Regards
/John

ons 2007-06-20 klockan 22:14 -0700 skrev Peter Shinners:
> John Eriksson wrote:
> > 1. Is this the correct way of creating an surface with an
> > alhpa-per-pixel channel?
> > surface = pygame.Surface((w, h), pygame.SRCALPHA)
> 
> This is the easiest. It will create an 32bit RGBA image for you. If you 
> want more control over the pixel format, you can pass more arguments. But 
> generally not necessary.
> 
> > 2. How do you clear an alpha channel surface? I guesss you can't use the
> > fill method?
> 
> Fill is really the only way to do it. Fill will set all the pixels in an 
> image to a given value. You can set the alpha channel to invisible (0) or 
> solid (255).
> 

Re: [pygame] Questions about surface with alpha channel

[Peter Shinners]

John Eriksson wrote:

1. Is this the correct way of creating an surface with an
alhpa-per-pixel channel?
surface = pygame.Surface((w, h), pygame.SRCALPHA)


This is the easiest. It will create an 32bit RGBA image for you. If you 
want more control over the pixel format, you can pass more arguments. But 
generally not necessary.



2. How do you clear an alpha channel surface? I guesss you can't use the
fill method?


Fill is really the only way to do it. Fill will set all the pixels in an 
image to a given value. You can set the alpha channel to invisible (0) or 
solid (255).

[pygame] Questions about surface with alpha channel

[John Eriksson]

Hi,
I have a couple of questions regarding surfaces with an alpha channel.

1. Is this the correct way of creating an surface with an
alhpa-per-pixel channel?
surface = pygame.Surface((w, h), pygame.SRCALPHA)

2. How do you clear an alpha channel surface? I guesss you can't use the
fill method?

Best Regards
/John

Re: [pygame] MOD files question

[Peter Shinners]

Will McGugan wrote:
The docs for pygame.mixer.music mention MOD files. What kind of MOD 
files can PyGame play? Does anyone still use them? I don't think I have 
even seen any since  MP3 took over!


This SDL_mixer library includes a snapshot copy of the mikmod library. 
This is what it uses to playback mod, it, and all the other supported 
tracker formats.


For better or worse, the mikmod has continued development on its own. It 
probably is a lot better than the forked snapshot sitting inside SDL_mixer.


But I've never looked into it much, never had a problem with what was 
already provided. Btw, Solarwolf uses XM for its own music.


http://mikmod.raphnet.net/

Re: [pygame] Display-less PyGame

[Charles Joseph Christie II]

On Wednesday 20 June 2007 10:46:49 pm Luke Paireepinart wrote:
> > Have any of you played the old text-mode game engines ZZT and Megazeux?
> > For the most part these were action games. There's also "ika"
> > (), a Python spinoff of the RPG engine
> > Verge. It doesn't use Pygame itself though.
>
> Wo, thanks for introducing me to this. Ika looks super-awesome!
> Maybe when my two summer school classes stop eating up my time, I'll be
> able to look into it more ^_^.
> -Luke

Well, hey, would you look at that. Two of my prominent game ideas, an SRPG and 
a Tetris Attack clone, right there on the "examples" page. :P

ika looks pretty awesome... But now I'm all "I want to use pygame but this 
looks really interesting but I want to learn to make my own game engine in 
pygame but this one is already great bu *head asplodes"

Crap. I don't know what I want to use now :P

Re: [pygame] Display-less PyGame

[Luke Paireepinart]

Have any of you played the old text-mode game engines ZZT and Megazeux?
For the most part these were action games. There's also "ika"
(), a Python spinoff of the RPG engine
Verge. It doesn't use Pygame itself though.
  

Wo, thanks for introducing me to this. Ika looks super-awesome!
Maybe when my two summer school classes stop eating up my time, I'll be 
able to look into it more ^_^.

-Luke

Re: [pygame] Display-less PyGame

[Charles Joseph Christie II]

On Wednesday 20 June 2007 06:46:28 pm [EMAIL PROTECTED] wrote:

> Actually, someone did use Pygame to make a "DDRPG" called Tendrils.
> 

Doesn't work, the project's homepage is dead. Darnit, I really wanted to play 
this :P

> Have any of you played the old text-mode game engines ZZT and Megazeux?
> For the most part these were action games. There's also "ika"
> (), a Python spinoff of the RPG engine
> Verge. It doesn't use Pygame itself though.

I've heard of Megazeux ages ago, but that's about as much as I know. I never 
really got into text RPGs.

Re: [pygame] Display-less PyGame

[dbcad7]

I played a little with the "Z" interpreter.. Frotz if I remember. There are 
lots of games, and yearly awards for best game (although can't seem to find a 
link for the awards just now)

The Infocom games were cool. Loved Planetfall. Dave's idea of some background 
music sounds nice.. and maybe even music or sound effects that are synced with 
what's happening in the game. Heck with the darkness on some of the latest 
first person shooters it might be an improvement just to go all out text based.

Dennis




 --- On Wed 06/20,  < [EMAIL PROTECTED] > wrote:
From:  [mailto: [EMAIL PROTECTED]
To: pygame-users@seul.org
Date: Wed, 20 Jun 2007 22:46:28 - (UTC)
Subject: Re: [pygame] Display-less PyGame

[Pygame Discussion List][It is dark. You are likely to be eaten by a grue.]Dave 
LeCompte says: "Come on, you know you want to write Zork ZorkRevolution."> 
replyActually, someone did use Pygame to make a "DDRPG" called 
Tendrils.Have any of you played the old 
text-mode game engines ZZT and Megazeux?For the most part these were action 
games. There's also "ika"(), a Python spinoff 
of the RPG engineVerge. It doesn't use Pygame itself though.

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: [PATCH] Re: [pygame] Smooth Scaling (pygame.transform.smoothscale)

[René Dudfield]

Hi,

I guess we could use python platform stuff.  Like how much stuff is
done in the python config files at the moment.  We put '-enable-mmx'
or whatever it is called into each platform that we know supports it.
mingw, windows, *nix with x86, osx.

Not quite as good as a gcc flag, but I think it'll work.




On 6/21/07, Richard Goedeken <[EMAIL PROTECTED]> wrote:

That's a good plan, but I haven't been able to find a good way to
determine at compile time whether or not the compiler supports MMX.  You
could always dump out a small test file and compile it to test for
errors, but I was hoping to find something better like running gcc with
a magical parameter or testing for a magical preproc definition.  Are
you aware of any 'cleaner' ways of handling this detection?

Richard


René Dudfield wrote:
> Hi,
>
> that's good :)
>
> SDL does it by compiling the mmx stuff in if the compiler supports it.
> Then it has runtime checks to see if the cpu supports it.  SDL also
> has a configure flag, which you can use to tell it not to even try
> compiling mmx stuff.
>
> So if the compiler doesn't support it, the C version is used.
> If the compiler supports it, and the runtime cpu detection finds mmx,
> then the mmx version is used.
>
>
>
> On 6/20/07, Richard Goedeken <[EMAIL PROTECTED]> wrote:
>> Rene,
>>
>> I would be willing to add the CPU detection functions but I can't think
>> of how it could be implemented in a useful way.  The compile-time checks
>> have to stay in because trying to compile the 64-bit code on a 32-bit
>> architecture, or the 32-bit MMX code on a PPC or similar, will cause
>> compile-time errors.  So it's given that if someone is running an i386,
>> PPC, Sun, Arm, etc, they will get the C code.  If they're running i686,
>> they'll get the 32-bit MMX, and for x86_64 they'll get the 64-bit MMX.
>>
>> So, the dilemma is that whatever build a user is running, the code is
>> pretty much guaranteed to work on their CPU.  If someone is running the
>> i686 build on a 486 or something silly like that they'll probably have
>> bigger problems.  We could allow someone to 'downgrade' and run the C
>> code when their CPU supports MMX, but what's the point?
>>
>> Regards,
>> Richard

Re: [PATCH] Re: [pygame] Smooth Scaling (pygame.transform.smoothscale)

[Richard Goedeken]

That's a good plan, but I haven't been able to find a good way to
determine at compile time whether or not the compiler supports MMX.  You
could always dump out a small test file and compile it to test for
errors, but I was hoping to find something better like running gcc with
a magical parameter or testing for a magical preproc definition.  Are
you aware of any 'cleaner' ways of handling this detection?

Richard


René Dudfield wrote:
> Hi,
> 
> that's good :)
> 
> SDL does it by compiling the mmx stuff in if the compiler supports it.
> Then it has runtime checks to see if the cpu supports it.  SDL also
> has a configure flag, which you can use to tell it not to even try
> compiling mmx stuff.
> 
> So if the compiler doesn't support it, the C version is used.
> If the compiler supports it, and the runtime cpu detection finds mmx,
> then the mmx version is used.
> 
> 
> 
> On 6/20/07, Richard Goedeken <[EMAIL PROTECTED]> wrote:
>> Rene,
>>
>> I would be willing to add the CPU detection functions but I can't think
>> of how it could be implemented in a useful way.  The compile-time checks
>> have to stay in because trying to compile the 64-bit code on a 32-bit
>> architecture, or the 32-bit MMX code on a PPC or similar, will cause
>> compile-time errors.  So it's given that if someone is running an i386,
>> PPC, Sun, Arm, etc, they will get the C code.  If they're running i686,
>> they'll get the 32-bit MMX, and for x86_64 they'll get the 64-bit MMX.
>>
>> So, the dilemma is that whatever build a user is running, the code is
>> pretty much guaranteed to work on their CPU.  If someone is running the
>> i686 build on a 486 or something silly like that they'll probably have
>> bigger problems.  We could allow someone to 'downgrade' and run the C
>> code when their CPU supports MMX, but what's the point?
>>
>> Regards,
>> Richard

Re: [pygame] Display-less PyGame

[Ethan Glasser-Camp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
> [Pygame Discussion List]
> [It is dark. You are likely to be eaten by a grue.]
> Dave LeCompte says: "Come on, you know you want to write Zork Zork
> Revolution."
>> reply

:)

> Actually, someone did use Pygame to make a "DDRPG" called Tendrils.
> 

Sadly, the original host is down. If this game is freely
redistributable, does anyone have a copy of it? Is it any fun? Etc.

Ethan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGebbmhRlgoLPrRPwRAp8iAJ9dWdbgB0j283Lem3R87grjOAkFGwCglxIf
yhAY8YsSUv2gmBXWYUJgMVk=
=L2km
-END PGP SIGNATURE-

Re: [pygame] Display-less PyGame

[Charles Joseph Christie II]

On Wednesday 20 June 2007 06:46:28 pm [EMAIL PROTECTED] wrote:
> Actually, someone did use Pygame to make a "DDRPG" called Tendrils.
> 

Awesome. I had an idea for this but it looked more like "Paper Mario" 
than "Final Fantasy" but great minds think alike, I suppose :P

(I have to get this game when I come back from Church and get done playing 
Star Wars Rogue Squadron 3)

Re: [pygame] Display-less PyGame

[kschnee]

[Pygame Discussion List]
[It is dark. You are likely to be eaten by a grue.]
Dave LeCompte says: "Come on, you know you want to write Zork Zork
Revolution."
> reply

Actually, someone did use Pygame to make a "DDRPG" called Tendrils.


Have any of you played the old text-mode game engines ZZT and Megazeux?
For the most part these were action games. There's also "ika"
(), a Python spinoff of the RPG engine
Verge. It doesn't use Pygame itself though.

Re: [pygame] I have a quick question... again...

[kschnee]

On Wed, June 20, 2007 1:31 am, Charles Joseph Christie II wrote:
> Well, if I don't use the pygame sprite module, what should I use?

In the code over at
 there's one
file, "nixie.py", that might be useful. It's messy, but it's got code for
tasks like loading animation frames from a single character sheet (with
any size or padding) and the logic of animation sequences. "coral.py" is a
tile engine that changes the sprite locations based on the location of a
hypothetical camera.

Recently I tried reducing the size of the tiles I was using, and I found
that the character seemed to move more slowly. It was a pleasant surprise
to figure out that the character was covering ground at the same rate,
because the "world coordinates" of the character were unaffected by the
size of the graphics.

> Also, I'm reading about MVC from multiple sources right now and, although
> I get the concept, I'm still not 100% sure how to use it in a game.

What I've tried to do is have what I call a "worldsim," the Model in MVC,
that tracks the game's characters and environment. I test that out in
plain text. Then I build a Display class (the View), and give it access to
the Model. The Controller part of MVC might be built into the View too.
The upshot is that I've then got an object that's the Model, that's
accessed by the View/Controller. Doing that means the graphics engine can
be replaced relatively easily. It can be awkward, though, since the Model
needs some way to send messages to the main class like "the player got
killed."

Re: [pygame] FastRenderGroup (update 3)

[DR0ID]

Hello

thanks for your response, although I do not have much time for the next 
2 weeks. I have not looked at the testsprites.py very close, but I will 
as soon I have some time, so some answers/questions may be a bit inaccurate.


René Dudfield schrieb:

Hi,

just to let you know I'm looking through your FastRenderGroup today.

Here's some initial thoughts.

- it is quite well documented.

- it's great that you factored out the Layered part.

- seems to run faster than RenderUpdates.  It'd be nice if you could
incorporate FastRenderGroup into the pygame example/testsprites.py  I
sent you a copy earlier where I started to integrate it.  So that via
the command line people can choose to use FastRenderGroup or other
methods.  That is the place where the rest of the other sprite stuff
is performance tested, so that's the place to put FastRenderGroup too.

Yes it should thanks to the dirty technique.



- we could put your fast renderer group demo into the pygame examples
too.  Since it shows off lots of other features of FastRenderGroup
that none of the existing demos do.


Sure, what features exactly do you mean?



- readonly/private variables should use an underscore.  eg
DirtySprite.layer maybe should be ._layer.  I think you have done this
already mostly.
Agreed, I will put the file through "lint", so it should match standard 
python ( http://www.python.org/dev/peps/pep-0008/ )




- Maybe we could use incorporate DirtySprite's features into the
pygame.sprite.Sprite  Since all the differences are is a few
attributes.  This needs more thought on attribute naming.  We don't
want conflicts with existing pygames - if we add them to
pygame.sprite.Sprite.
well yes, naming is a delicate topic, any help appreciated (I do the 
refactoring, no problem).




- documentation is needed by some methods.


Sure, tell me which ones. Oh, I have just seen that I forgot to document 
the FastRenderGroup itself.
If someone has started to use either the LayeredRenderGroup or the 
FastRenderGroup and has found the doc's to be inaccurate, please let me 
know how to improve the docs. (because docs are valuable information). 
Thanks.


- The frame jerking is weird.  We'll need to fix this before it's used 
I think.

   - add a print 'flip' into the draw method, and you will see that
the jerkiness is caused by it occasionally flipping, rather than
updating.  This causes the fps difference, and shatters the illusion
of movement - which requires a constant fps.

I think the frame jerking is cause because I use 100% cpu and from time 
to time the OS has to do other things. If you put in a 
pygame.time.sleep(0.002) it will stop jerking, but the framerate drop too.




- I'm not sure how to have make FastRenderGroup backwards compatible
with RenderUpdates.  However if it was backwards compatible, then we
could completely replace RenderUpdates.  Maybe a question to ask is...
why is it not possible to make it backwards compatible?

Because I need more information like a dirty flag (well if the Sprite 
has it then it could be possible, but then the question is what default 
value to use). Main reason are the attributes.



- the unittests should be in a separate file.

ok, can someone look through them and give me some advise how to do them 
correctly? I have done them in the best way I thought, but perhaps wrong 
way (its actually the second unittest i have written so far).



- I think maybe a name change for the FastRenderGroup?
Sure. Just wondering what you think is wrong with that name? Any 
proposal welcome since I though it was a good name.


- I'm not sure about the use of get_ticks().  I think it's ok, because
you're not doing animation with it, just figuring out which update
method to use.  Some tests with different get_ticks() functions are
passed in could allow you to unittest your switching behaviour.

Hmm. Im not sure if I fully understand you. I should pass get_ticks to 
the draw function so different versions could be used and therefore 
unittested?



- what disadvantages does FastRenderGroup have over RenderUpdates?
These are the ones I can see so far:
- needs to use DirtySprite, not normal pygame Sprites. (We could
fix this by giving normal pygame sprites the DirtySprite default
attributes)
- all sprites have to be in a single group.  ( Why do they need
to be? Is this really a problem at all?  Can it be solved easily?)
Well, this is due the redrawing of all srpites in a dirty area on 
screen. The dirty area on screen can affect sprites that are not dirty 
and therefor not redrawn (only the part that is in the dirty area is 
repainted actually). And that is the problem: the group must know all 
sprites on screen, otherwise it can not redraw them correctly.


Actually it would be simpler if you or I write some demo to demonstrate 
the effects which can occur when using more than one group simultaneously.



Ok, that's all for now.  Just email again to the list, if you don't
catch me in irc.  Hopefully we can figu

Re: [pygame] Refcounting Bugs

[mva]

Campbell Barton <[EMAIL PROTECTED]>:


Hey, I was looking at Pygames source and noticed some refcounting
errors that will leak memory.

[Leak list]

Agreed and verified. I'll take care of it.

Regards
Marcus

Re: [pygame] Display-less PyGame

[Dave LeCompte (really)]

I asked, without doing my homework:
> René Dudfield <[EMAIL PROTECTED]> wrote:
>
>> You can use the dummy sdl driver.
>
> Nice! Is there a list of environment variables that PyGame responds to?

And it turns out, yes there is:

http://www.libsdl.org/cgi/docwiki.cgi/Environment_20variables


-Dave LeCompte

Re: [pygame] Display-less PyGame

[Dave LeCompte (really)]

René Dudfield <[EMAIL PROTECTED]> wrote:

> You can use the dummy sdl driver.

Nice! Is there a list of environment variables that PyGame responds to?


I can get back to work on my:
console game: http://www.bigdicegames.com/Console/index.html
text adventure: http://www.lecompte.org/Dave/Pix/24.jpg

-Dave LeCompte

Re: [pygame] MOD files question

[Dave LeCompte (really)]

"Will McGugan" <[EMAIL PROTECTED]>wrote:
> The docs for pygame.mixer.music mention MOD files. What kind of MOD
> files can PyGame play? Does anyone still use them? I don't think I have
> even seen any since  MP3 took over!

A buddy of mine used MOD music in a game of his:

http://evertt.com/moreinfo_gdn.htm

and won first place in "Innovation in Audio" at the Independent Games
Festival of 2005.


His thinking, at the time, was that there's a lot of MOD music out there,
and much of it much better than he could write, himself. He contacted a
few composers to get permission to use their works, and (if I recall
correctly) got some original stuff made, to boot.

-Dave LeCompte

[pygame] Refcounting Bugs

[Campbell Barton]

Hey, I was looking at Pygames source and noticed some refcounting errors 
that will leak memory.


This is from todays SVN


./src/font.c:473 - Py_BuildValue  has a ref and Append adds another
./src/font.c:489 - same as above
 - these are fairly bad because it runs in a loop.



./src/display.c:390
to...
./src/display.c:408
PyDict_SetItemString(dict, "window", PyInt_FromLong(info.info.x11.window));

This PyInt_FromLong starts with 1 refcount and PyDict_SetItemString adds 
another


use the utility function pygame has added- eg.
 insobj(dict, "gain", PyInt_FromLong(event->active.gain));
 - Not so bad because your not likely to run in a loop




append not decrefing either, these dont realy matter since your quitting 
anyhow but probably best to do it properly.

./src/base.c:95
./src/base.c:111



--
Campbell J Barton (ideasman42)

Re: [pygame] MOD files question

[Andrew Pape]

Hi Will,

>The docs for pygame.mixer.music mention MOD files. What kind of MOD 
>files can PyGame play? Does anyone still use them? I don't think I have 
>even seen any since  MP3 took over!
>Thanks,
>Will McGugan



I went to great effort a few weeks ago to get fmod (a commercial sound package) 
to play mod files with pygame, only to be told that pygame supports mod files, 
as you mentioned. So I tried a few different modules with pygame, including a 
standard ".mod" file, an ".IT" (Impulse Tracker) file, and ".XM" (extended 
module?) file and, if I remember correctly, an "S3M" (ScreamTracker) file. All 
the mod files I've ever played are in one of those formats, so pygame's module 
support is pretty good. Regarding whether people still use mod files, I used 
them in a Windows DirectX game because they were of much higher quality than 
any MIDI music I've heard. But the quality will really depend on the musical 
score. I've found some excellent mod files on the net. There are several web 
sites devoted to mod files, so mods are still popular. I have heard, however, 
that musicians who used to write music in mod format are now changing over to 
composing midi music. 

On another note (pun!), my linux box will not play mod files properly. First I 
had trouble with playing OGG files, but then someone told me I had to change 
the SDL sound settings. That fixed the OGG playback, but all the modules I play 
hiss, and I have changed every SDL sound setting but have had no luck; I still 
get hissing playback of all mods. Any ideas?


Cheers,

Andrew.




  
_
  

Yahoo!7 Mail has just got even bigger and better with unlimited storage on all 
webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html

[pygame] MOD files question

[Will McGugan]

Hi,

The docs for pygame.mixer.music mention MOD files. What kind of MOD 
files can PyGame play? Does anyone still use them? I don't think I have 
even seen any since  MP3 took over!


Thanks,

Will McGugan

Re: [pygame] Display-less PyGame

[René Dudfield]

You can use the dummy sdl driver.

Like this:
import os

os.environ['SDL_VIDEODRIVER'] = 'dummy'
import pygame
pygame.init()
pygame.display.set_mode((1,1))

while 1:
   events = pygame.event.get()
   for e in events:
   pass




On 6/20/07, Dave LeCompte (really) <[EMAIL PROTECTED]> wrote:

"Luke Paireepinart" <[EMAIL PROTECTED]> wrote, in the thread about
the text adventure:

> Since your game doesn't actually use 'pygame,' as it's a text game

This touches on a side note - not really a feature request, because I know
some of the reasons why it is the way it is, but I'm a little sad that
PyGame (really, SDL, and DirectSound, and DirectInput and so on...) does
require a graphical window and isn't a good option for a text-only game.

Supposing I wanted to use the pygame.mixer module to play music behind my
text adventure game [http://www.ifarchive.org/].

Or, supposing I wanted to use the pygame joystick support to drive a
text-mode graphics game [similar to: http://www.taat.fi/tmdc/].


Perhaps a little bit more practical - just yesterday, I was experimenting
with code I was writing for a dynamic music system. I wanted to do some
unit testing (imagine!) of the system, so I had no real need for graphics.
But pygame.mixer requires that there be a window (again, I understand the
lower-level reasons why this is).


I suppose I mention this mostly because I think it would be nice if there
was a way to use the sound, music, and input pieces of PyGame without
using the display pieces. I'm not in any particular hurry for this,
myself, otherwise, I'd launch into it alone. However, if there are any
other like-minded folks out there, I'd be happy to chat - either here or
in private email.


Come on, you know you want to write Zork Zork Revolution.


-Dave LeCompte