Re: [pygame] Quick OS survey - 2013
60% Mac OS 10.8 40% Ubuntu Linux On 6 December 2013 08:01, Jason Marshall wrote: > No, if this survey were on a dedicated web service, then it never would > have been created because setting up a dedicated web service would take too > much effort. Also, fewer people would have noticed it and responded to it. > > I'm still hoping for many more responses. Doesn't somebody use pygame with > Windows 8.x? > > Jason > > -- > *From:* Olivier Crouzet > *To:* pygame-users@seul.org > *Sent:* Friday, December 6, 2013 1:06 AM > *Subject:* Re: [pygame] Quick OS survey - 2013 > > Dear all, it seems to me that if any single pygame user is going to answer > this "survey", it won't be long until this list becomes full with any > single answer! Wouldn't it be wise, if this really is a matter of interest, > to set up a survey on a dedicated web service so everyone can continue > discussing and reading pygame issues? Thanks for your understanding. > > Olivier. > > --Message d'origine-- > De: Miriam English > Expéditeur: owner-pygame-us...@seul.org > À: pygame-users@seul.org > Cc: Jason Marshall > Répondre à: pygame-users@seul.org > Objet: Re: [pygame] Quick OS survey - 2013 > Envoyé: 6 déc. 2013 07:27 > > Puppy Linux 97% > Android 1% > Ubuntu Linux 1% > various flavors of MSWindows and FreeDOS 1% > > > Jason Marshall wrote: > > pygamers, which computer operating system(s) have you used this year? If > > you have been using more than 1 operating system, approximately what > > percentage of your time are you using each one? > > > > Here's my breakdown: > > 0.5%Linux Mint > > 0.5%Mac OS X 10.4 > > 2%Windows ME > > 4%Windows XP > > 5%Mac OS X 10.6 > > 88%Windows 7 > > -- > If you don't have any failures then you're not trying hard enough. > - Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory > - > Website: http://miriam-english.org > Blogs: http://miriam-e.dreamwidth.org > http://miriam-e.livejournal.com > > > > -- > Olivier Crouzet > LLING - Laboratoire de Linguistisque > >
Re: [pygame] Games for blind players
You could do that, but I think a really cool idea would be an arcade style shooter with the "display" in sound. E.g. it gives eight distinct sequential sounds per "frame", one per direction (N, NE, E, SE etc) the presence of an enemy alters the sound for that direction, and you shoot it by pressing the button at the right time. (All with appropriate aural feedback.) On Sat, Oct 22, 2011 at 9:51 AM, Luis Miguel Morillas wrote: > A friend asked me to write a game for blind kids. He proposed me a > kind of hangman game. Do you have any experience using speech > recognition and text to speech into games? > > -- lm >
Re: [pygame] are individual midi instruments sounds copyrighted
Hear, hear. I imagine Yamaha just wants to keep people from taking their samples and using them in another instrument or midi rendering software... On Mon, Jul 19, 2010 at 4:36 PM, Brian Fisher wrote: > Well the midi version of your composition is absolutely your own and no-one > else's, and there are other ways to render it to wav/ogg/whatever besides > the line out of your keyboard, which don't restrict your ability to > distribute and sell your product, so you always have options. If you have > access to a mac, for instance, garageband instrument samples give a > royalty-free license to use to make renderings of midi music. > > That being said, I would be *amazed* if rendering down your own music wasn't > an "authorized use" of the yamaha keyboard. That copyright notice you have > there isn't clear at all at what is and isn't authorized, it just says that > "personal use" is always OK, and that's basically a meaningless statement > because what they say is already given by copyright law. I think bottom line > is you are in a grey area with that keyboard unless you find something more > about what is exactly authorized or licensed. You could try emailing Yamaha > support if you really cared, but if I were you, I would assume it's totally > fine and just use my own rendered music however I like, cause it would be > ridiculous and stupid if yamaha ever tried to claim infringement in a case > like yours, bad for their business. The reality of copyright and IP law is > that the only thing that is actually in violation is what is enforced by the > copyright holder. > > > On Mon, Jul 19, 2010 at 1:14 PM, Brian Brown wrote: >> >> I think I have an idea of what to do now. >> I think I will just keep making my music and if I find it is unusable >> for my game, I should just use it personally. >> Thanks everybody for all your help. I appreciate it. >> Matt > >
Re: [pygame] are individual midi instruments sounds copyrighted
I find Luke's argument pretty convincing... again, I'm not a lawyer
either, but perhaps the situation is analogous to typefaces? As you
may know, the type foundry does not have control over how its typeface
is used after they sell it to you, and you don't have to pay royalties
for using it. Again, it would be best to talk to an actual
intellectual property rights lawyer. I'm curious as to what he/she
says about the issue.
On Sun, Jul 18, 2010 at 5:32 AM, Mel Collins wrote:
> As I read it, the linked midiloops.com page is not actually relevant
> in your situation. It talks about the MIDI files, which really only
> describe the composition. You say yourself that it is your own musical
> composition, which means that the copyright belongs to you.
> _However_, there may still be a copyright issue with using the audio
> samples which your keyboard outputs - those will most likely be
> copyrighted by the manufacturer (ie. Yamaha). I would strongly suggest
> that you read through the small-print sections of the keyboard's
> manual, specifically the copyright section (you may be able to find
> the relevant PDF on the yamaha.com site).
> For example, I found this online, for the Yamaha PSR-E413:
>
>> This product incorporates and bundles computer programs and contents in which
>> Yamaha owns copyrights or with respect to which it has license to use others’
>> copyrights. Such copyrighted materials include, without limitation, all
>> computer
>> software, style files, MIDI files, WAVE data, musical scores and sound
>> recordings.
>> Any unauthorized use of such programs and contents outside of personal use is
>> not permitted under relevant laws. Any violation of copyright has legal
>> consequences. DON’T MAKE, DISTRIBUTE OR USE ILLEGAL COPIES.
>>
>> Copying of the commercially available musical data including but not limited
>> to
>> MIDI data and/or audio data is strictly prohibited except for your personal
>> use.
>
> If your keyboard's manual says something like that ("WAVE data" is
> the relevant part in this case), then your recording from the
> keyboard's audio-out would indeed be infringing copyright if you
> distributed it.
>
> I would say that your best bet (if you don't want to try negotiating
> a licence!) is to just take your MIDI composition and record it using
> some libre instrument samples. I know there are several sources for
> such online.
>
> - Mel C
> (IANACLBIPOOTI)
>
Re: [pygame] are individual midi instruments sounds copyrighted
Perhaps I'm mistaken, but I don't think that this isn't really a list for legal issues related to music. But, for what it's worth, that website you link looks very old. Perhaps you should consult with a copyright lawyer who is up to date with current developments in the law and recent precedent. Anyway, you could always play a midi file directly, and the user's own sound card will render it into audio, using the user's own instrument sounds. On Sat, Jul 17, 2010 at 8:33 PM, Brian Brown wrote: > Hi pygame users, > I've just recently composed many of my own music pieces using a Yamaha > keyboard. > I saved the exact midi sound into a wav-file on my computer by > plugging the keyboard to the computer's line-in. > Everything was seeming good until-- I saw this page about midi > copyright: http://www.midiloops.com/copyrit1.htm > Does this mean I should pay royalties just to use an ogg-file > containing midi sounds-- even if I composed the melody totally myself? > I really wish I could just legally use my midi recordings without > paying royalties. > The Yamaha keyboard is already payed for and now I realize there are > copyright restrictions. This is very frustrating. > I'd appreciate any of your help. Thanks. > Matt >
Re: [pygame] unsubscribe
Unity3D? Eeew. Windows. Proprietary. And I bet it tastes like gophers, too. On Sat, Jan 30, 2010 at 11:48 PM, Luke Paireepinart wrote: > > > On Sun, Jan 31, 2010 at 12:25 AM, ryan wrote: >> >> yes it would appear I did do that wrong. >> thank you, and goodbye pygame! >> >> ive moved onto unity3d and have no need for pygame > > Oh man, what are we going to do without you? > > >> >> On Sat, Jan 30, 2010 at 9:27 PM, Russell Cumins >> wrote: >>> >>> Try this, if you haven't already. >>> http://www.mail-archive.com/pygame-users@seul.org/msg12606.html >>> >>> On 31 January 2010 05:14, Luke Paireepinart >>> wrote: you're doing it wrong, I think. On Sat, Jan 30, 2010 at 10:05 PM, ryan wrote: > > unsubscribe >>> >> > >
Re: [pygame] File Hosting
What's wrong with SVN or CVS anyway? They don't take long to learn how to use on a basic level, and using them is a worthwhile skill. On Sat, Jan 2, 2010 at 8:12 AM, Yanom Mobis wrote: > I know about SourceForge, but don't they make you use that SVN thing? I > just distribute my games as source code in .zip files. > > --- On *Fri, 1/1/10, Alex Nordlund * wrote: > > > From: Alex Nordlund > Subject: Re: [pygame] File Hosting > To: pygame-users@seul.org > Date: Friday, January 1, 2010, 4:33 PM > > > On Fri, Jan 1, 2010 at 9:10 PM, Ian Mallett > http://mc/compose?to=geometr...@gmail.com>> > wrote: > > MediaFire is what I use when my server is down. > > If you open-source them there's several sites like; Google Code, > SourceForge etc that'll host your files for free! > > --- > //Alex > > >
Re: [pygame] Trolls Outta Luckland - new release
> I don't think it would be possible to tune the game to swing both > ways. I will concede that point. Also, I was playing on a laptop, using a trackpoint pointing device, so that could have skewed my perception. (Although I still think keyboard+mouse would be better, you're right that it would be too hard to balance versus mouse-only or keyboard-only, difficulty-wise; all pointing devices are not created equally.) > > What size is your display? And is your eyesight good or poor? No > insult meant by those questions. They are factors I would want to > consider when interpreting your comment. And puzzling out how big is > too big, how small is too small. I played it on a 90dpi LCD monitor. My eyesight is not exceptional either way. > > Also, a large window and graphics means jumping sprites more pixels > per frame and the motion appears jerky or blurred to me, depending on > your frame and refresh rate. Unless the user has a very old computer, I don't know why this would be the case... It certainly seemed perfectly smooth to me, a 2x increase in graphic size (4x increase in number of pixels) should not drop the frame rate unacceptably low. You might want to look into how you are updating the window (flip or whatever) and see if you are doing it redundantly or something. > I guess I could consider knuckling down > and do scaling based on user-selected screen resolution. Not sure how > easy that would be... but I think not very. Probably not the way to go. Would look ugly, too, as you observe. I think you should just make bigger resolution graphics, about twice the size of your current ones would be fine in my opinion. > I was hoping someone wouldn't disparage an alpha > version of Trolls Outta Luckland for being akin to refried beans. But > I guess it had to happen. :) I didn't catch that it was an alpha, sorry. I forgot that people post alpha versions of things on the pygame website. Doesn't change my comments, though; it just means that it defiantly isn't too late to improve substantially. :) I guess people have different motivations for writing games; mine is either "There should be a version of X for linux!" (which tends to not last very long), or "Hey, wouldn't Y be neat in a game, why aren't there any games with Y?" "Z is fun, let's make another fun game like Z" doesn't really do it for me but if it results in a fun game, I suppose it's legitimate (just not very critically interesting even if well done.)
Re: [pygame] Trolls Outta Luckland - new release
Control scheme interesting and somewhat novel but a little difficult (probably to at least in part to unfamiliarity); there is potential there but it needs refinement. I think I would like mouse to aim, keys to move the ship, personally. The graphics are small and difficult to see. Better (larger, mainly) graphics would be a logical improvement at this point. None of the aforementioned problems are really severe. Overall, it's a competently executed but forgettable basic space invaders style game; a quirky control scheme alone is not enough to differentiate it from similar games. On Sun, Dec 20, 2009 at 10:27 PM, B W wrote: > Ahoy, pygamers. > > v0.0.3 is posted. > http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2402.html > > Ain't this like the third space shooter out this month? Sorry... > promise, we did not conspire to flood you with shooters! :) > > Anyway, I'd been wanting to do a shooter for a very long time so here > it comes. A little tired of the joystick and keyboard scene with its > clumsy 2- to 8-way motion. Thought I would go mouse for a big change, > try and get N-way. And that seems to be working great. I poured many > hours in over the past few days, and it shows. Please check it out, I > hope you like. > > I haven't gotten any feedback yet. Not even a "first post1" Makes > me wonder if my stuff is broke. :) Let me know if you have any > problems with the site. And thanks for your interest. > > Gumm >
Re: [pygame] Ncurses RTS?
At that point I would think that you might as well use simple 2D icons, which are much more expressive than letters, if you're going to forgo the advantages of a text console game which can be played over telnet or ssh... On Mon, Dec 7, 2009 at 10:08 AM, Casey Duncan wrote: > Maybe a solution to this is to use pygame. Just divide the screen up into a > grid where each rectangle can contain a character. To draw the screen you > just paint the appropriate character in each rect. You could also use > fancier glyphs too if you wanted to (like from wingdings, dingbats, > whatever) since you wouldn't be limited to the terminal font. > > -Casey > > On Dec 6, 2009, at 6:34 PM, Yanom Mobis wrote: > >> I know this doesn't actually involve pygame, but I was wondering if it >> would be possible to use the Python Ncurses module to make a realtime >> strategy game. Something in the vein of dwarf fortress (you can see >> screenshots at: http://www.bay12games.com/dwarves/screens.html ), but more >> of a traditional RTS than a rougelike/citybuilder game. >> > >
Re: [pygame] Ncurses RTS?
I don't see why that would not be possible. Sounds like a cool idea. On Sun, Dec 6, 2009 at 5:34 PM, Yanom Mobis wrote: > I know this doesn't actually involve pygame, but I was wondering if it > would be possible to use the Python Ncurses module to make a realtime > strategy game. Something in the vein of dwarf fortress (you can see > screenshots at: http://www.bay12games.com/dwarves/screens.html ), but more > of a traditional RTS than a rougelike/citybuilder game. > >
Re: [pygame] First / Third person shooter?
Designing and implementing a 3D game without opengl or another 3D toolkit is almost certainly much harder than learning OpenGL. On Fri, Nov 27, 2009 at 3:53 PM, Greg Ewing wrote: > Luke Paireepinart wrote: >> >> Look up how raycasters work, I've written a lot of them, you can write >> one in a few hours if you know how they work. > > The classic raycasting technique was designed in the days > before 3D hardware when the CPU had to do everything. > Nowadays it'll almost certainly be faster to do minimal work > with the CPU and make the most of the 3D hardware's > abilities. > > -- > Greg >
Re: [pygame] First / Third person shooter?
Those games, historically, used a variety of tricks to avoid the need for a fully general 3D system like OpenGL which would have been beyond consumer computers of the time. Are you looking to imitate the resulting look of the vintage games, or just make a simple 3D game with modern tools? On Fri, Nov 27, 2009 at 2:52 PM, Ian Mallett wrote: > Most likely using OpenGL. >
Re: [pygame] Font-Related Segfault
Maybe my cStringIO has been transparently replaced by StringIO for some reason. I would think that cStringIO would be available on this platform but perhaps not. On Mon, Nov 23, 2009 at 7:03 PM, Lenard Lindstrom wrote: > Strange. cStringIO works for me. I have localized the problem to the first > call to the file like object's tell method. But since this is the first > method called, it might not be limited to it. > > Lenard Lindstrom > > Bryce Schroeder wrote: >> >> cStringIO seems to have the same problem for me. >> It is already using open with 'rb'. >> Thanks for all your help, I will await the next version / patch I guess. >> >> On Mon, Nov 23, 2009 at 5:24 PM, Lenard Lindstrom wrote: >> >>> >>> Hi Bryce, >>> >>> Try using cStringIO instead. And make sure to open the file 'rb' (this >>> won't >>> matter on Linux, but will on Windows). I reproduced your problem with a >>> modified pygame.examples.fonty, and yes, it appears to be a bug. StringIO >>> instances should work. >>> >>> Lenard Lindstrom >>> >>> Bryce Schroeder wrote: >>> >>>> >>>> This code reproduces the problem. It is also as an attachment. >>>> >>>> My system: >>>> uname -a: >>>> Linux thales 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC >>>> 2009 x86_64 GNU/Linux >>>> >>>> >>>> ---file: tester.py -- >>>> import pygame, StringIO, sys >>>> pygame.font.init() >>>> if len(sys.argv) != 2: >>>> print >> sys.stderr, "Usage: python tester.py font.ttf" >>>> sys.exit(1) >>>> >>>> font = pygame.font.Font(sys.argv[1], 12) >>>> print "Loaded the font as a file:", font >>>> >>>> test = open(sys.argv[1]).read() >>>> stio = StringIO.StringIO(test) >>>> font2 = pygame.font.Font(stio, 12) >>>> print "Loaded the font as a StringIO:", font2 >>>> - >>>> >>>> On Mon, Nov 23, 2009 at 2:27 PM, Bryce Schroeder >>>> wrote: >>>> >>>> >>>>> >>>>> Okay: >>>>> I wrote the string (self.parts['font']) out to a temporary file and >>>>> diff'd it against the original file, and they are identical. >>>>> Pygame successfully loads the font from the temporary file, and the >>>>> font works normally. However I would definitely like to >>>>> find a less kludgish solution to the problem. >>>>> >>>>> The particular font does not appear to matter, or at least, a wide >>>>> variety of truetype fonts are affected - I can't load Junius Unicode >>>>> or Free Serif from a StringIO either, but I can load them from files. >>>>> >>>>> It worked about six to eight months ago. Sorry I can't be more >>>>> specific - I sort of mothballed the project for a while. >>>>> >>>>> Sorry I didn't provide a "demonstration program" I will try to keep >>>>> that in mind in the future. >>>>> >>>>> - Bryce >>>>> >>>>> >>>>> On Mon, Nov 23, 2009 at 2:05 PM, Brian Fisher >>>>> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> Pygame should be supporting a file-like object no problem, so this >>>>>> seems >>>>>> like it could be a bug. >>>>>> >>>>>> Can you be more specific on when in the past it worked, and what >>>>>> happened >>>>>> between then and when it segfaults now? >>>>>> >>>>>> Also, it's not clear from your problem description whether the problem >>>>>> is >>>>>> that pygame crashes when loading from a file-like object, or if pygame >>>>>> crashes on a specific set of font data. >>>>>> >>>>>> So I would suggest doing a sanity check here by writing the >>>>>> self.parts['font'] string to a temp file, and trying to load from >>>>>> that, >>>>>> as a >>>>>> way of being able to determine if the crash is caused by the file-like >>>>>> object reading,
Re: [pygame] Font-Related Segfault
cStringIO seems to have the same problem for me. It is already using open with 'rb'. Thanks for all your help, I will await the next version / patch I guess. On Mon, Nov 23, 2009 at 5:24 PM, Lenard Lindstrom wrote: > Hi Bryce, > > Try using cStringIO instead. And make sure to open the file 'rb' (this won't > matter on Linux, but will on Windows). I reproduced your problem with a > modified pygame.examples.fonty, and yes, it appears to be a bug. StringIO > instances should work. > > Lenard Lindstrom > > Bryce Schroeder wrote: >> >> This code reproduces the problem. It is also as an attachment. >> >> My system: >> uname -a: >> Linux thales 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC >> 2009 x86_64 GNU/Linux >> >> >> ---file: tester.py -- >> import pygame, StringIO, sys >> pygame.font.init() >> if len(sys.argv) != 2: >> print >> sys.stderr, "Usage: python tester.py font.ttf" >> sys.exit(1) >> >> font = pygame.font.Font(sys.argv[1], 12) >> print "Loaded the font as a file:", font >> >> test = open(sys.argv[1]).read() >> stio = StringIO.StringIO(test) >> font2 = pygame.font.Font(stio, 12) >> print "Loaded the font as a StringIO:", font2 >> - >> >> On Mon, Nov 23, 2009 at 2:27 PM, Bryce Schroeder >> wrote: >> >>> >>> Okay: >>> I wrote the string (self.parts['font']) out to a temporary file and >>> diff'd it against the original file, and they are identical. >>> Pygame successfully loads the font from the temporary file, and the >>> font works normally. However I would definitely like to >>> find a less kludgish solution to the problem. >>> >>> The particular font does not appear to matter, or at least, a wide >>> variety of truetype fonts are affected - I can't load Junius Unicode >>> or Free Serif from a StringIO either, but I can load them from files. >>> >>> It worked about six to eight months ago. Sorry I can't be more >>> specific - I sort of mothballed the project for a while. >>> >>> Sorry I didn't provide a "demonstration program" I will try to keep >>> that in mind in the future. >>> >>> - Bryce >>> >>> >>> On Mon, Nov 23, 2009 at 2:05 PM, Brian Fisher >>> wrote: >>> >>>> >>>> Pygame should be supporting a file-like object no problem, so this seems >>>> like it could be a bug. >>>> >>>> Can you be more specific on when in the past it worked, and what >>>> happened >>>> between then and when it segfaults now? >>>> >>>> Also, it's not clear from your problem description whether the problem >>>> is >>>> that pygame crashes when loading from a file-like object, or if pygame >>>> crashes on a specific set of font data. >>>> >>>> So I would suggest doing a sanity check here by writing the >>>> self.parts['font'] string to a temp file, and trying to load from that, >>>> as a >>>> way of being able to determine if the crash is caused by the file-like >>>> object reading, or by some problem with the contents of the file-like >>>> object. >>>> >>>> So something like: >>>> >>>> class Font(Resource): >>>> >>>> def pygame_font(self,size): >>>> file(temp_file_name, "w").write(self.parts['font']) >>>> return pygame.font.Font(temp_file_name, size) >>>> os.unlink(temp_file_name) >>>> >>>> If that still crashes, then pygame has trouble with that font content, >>>> and >>>> then the question would be to figure out what about that font content is >>>> causing problems. If that doesn't crash, then the problem would be with >>>> accessing the content as a file-like object. >>>> >>>> >>>> ... finally, as general advice to all people posting problems - if you >>>> can >>>> send a completely self-contained reproducible case, then you are much >>>> more >>>> likely to get good help and results faster. As an example in this case, >>>> providing the contents of the self.parts['font'] string in an attached >>>> file >>>
Re: [pygame] Font-Related Segfault
This code reproduces the problem. It is also as an attachment. My system: uname -a: Linux thales 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux ---file: tester.py -- import pygame, StringIO, sys pygame.font.init() if len(sys.argv) != 2: print >> sys.stderr, "Usage: python tester.py font.ttf" sys.exit(1) font = pygame.font.Font(sys.argv[1], 12) print "Loaded the font as a file:", font test = open(sys.argv[1]).read() stio = StringIO.StringIO(test) font2 = pygame.font.Font(stio, 12) print "Loaded the font as a StringIO:", font2 - On Mon, Nov 23, 2009 at 2:27 PM, Bryce Schroeder wrote: > Okay: > I wrote the string (self.parts['font']) out to a temporary file and > diff'd it against the original file, and they are identical. > Pygame successfully loads the font from the temporary file, and the > font works normally. However I would definitely like to > find a less kludgish solution to the problem. > > The particular font does not appear to matter, or at least, a wide > variety of truetype fonts are affected - I can't load Junius Unicode > or Free Serif from a StringIO either, but I can load them from files. > > It worked about six to eight months ago. Sorry I can't be more > specific - I sort of mothballed the project for a while. > > Sorry I didn't provide a "demonstration program" I will try to keep > that in mind in the future. > > - Bryce > > > On Mon, Nov 23, 2009 at 2:05 PM, Brian Fisher > wrote: >> Pygame should be supporting a file-like object no problem, so this seems >> like it could be a bug. >> >> Can you be more specific on when in the past it worked, and what happened >> between then and when it segfaults now? >> >> Also, it's not clear from your problem description whether the problem is >> that pygame crashes when loading from a file-like object, or if pygame >> crashes on a specific set of font data. >> >> So I would suggest doing a sanity check here by writing the >> self.parts['font'] string to a temp file, and trying to load from that, as a >> way of being able to determine if the crash is caused by the file-like >> object reading, or by some problem with the contents of the file-like >> object. >> >> So something like: >> >> class Font(Resource): >> >> def pygame_font(self,size): >> file(temp_file_name, "w").write(self.parts['font']) >> return pygame.font.Font(temp_file_name, size) >> os.unlink(temp_file_name) >> >> If that still crashes, then pygame has trouble with that font content, and >> then the question would be to figure out what about that font content is >> causing problems. If that doesn't crash, then the problem would be with >> accessing the content as a file-like object. >> >> >> ... finally, as general advice to all people posting problems - if you can >> send a completely self-contained reproducible case, then you are much more >> likely to get good help and results faster. As an example in this case, >> providing the contents of the self.parts['font'] string in an attached file >> with a simple script that tries to load from a StringIO using that file's >> contents, would make this easily reproducible and testable by fellow mailing >> listers - but without knowing what the contents of the string in question >> are, it may actually be practically impossible for anyone else to test >> themselves. >> >> >> On Mon, Nov 23, 2009 at 12:38 PM, Bryce Schroeder >> wrote: >>> >>> (My apologies if this is a double-post. I didn't get a copy of the >>> message or see it in the archive, so I'm trying again.) >>> >>> I have a pygame program that worked in the past on both Linux and >>> Windows, but now results in a segfault, at least on Linux. (I can't >>> test it on Windows.) >>> The segfault occurs in this code: >>> >>> class Font(Resource): >>> >>> def pygame_font(self,size): >>> return pygame.font.Font(StringIO.StringIO(self.parts['font']), >>> size) # Segfaults here >>> >>> >>> self.parts['font'] is a string containing a truetype font loaded from >>> a file. I have checked that the string contains the file like it is >>> supposed too. Any suggestions? >> >> > import pygame, StringIO, sys pygame.font.init() if len(sys.argv) != 2: print >> sys.stderr, "Usage: python tester.py font.ttf" sys.exit(1) font = pygame.font.Font(sys.argv[1], 12) print "Loaded the font as a file:", font test = open(sys.argv[1]).read() stio = StringIO.StringIO(test) font2 = pygame.font.Font(stio, 12) print "Loaded the font as a StringIO:", font2
Re: [pygame] Font-Related Segfault
Okay: I wrote the string (self.parts['font']) out to a temporary file and diff'd it against the original file, and they are identical. Pygame successfully loads the font from the temporary file, and the font works normally. However I would definitely like to find a less kludgish solution to the problem. The particular font does not appear to matter, or at least, a wide variety of truetype fonts are affected - I can't load Junius Unicode or Free Serif from a StringIO either, but I can load them from files. It worked about six to eight months ago. Sorry I can't be more specific - I sort of mothballed the project for a while. Sorry I didn't provide a "demonstration program" I will try to keep that in mind in the future. - Bryce On Mon, Nov 23, 2009 at 2:05 PM, Brian Fisher wrote: > Pygame should be supporting a file-like object no problem, so this seems > like it could be a bug. > > Can you be more specific on when in the past it worked, and what happened > between then and when it segfaults now? > > Also, it's not clear from your problem description whether the problem is > that pygame crashes when loading from a file-like object, or if pygame > crashes on a specific set of font data. > > So I would suggest doing a sanity check here by writing the > self.parts['font'] string to a temp file, and trying to load from that, as a > way of being able to determine if the crash is caused by the file-like > object reading, or by some problem with the contents of the file-like > object. > > So something like: > > class Font(Resource): > > def pygame_font(self,size): > file(temp_file_name, "w").write(self.parts['font']) > return pygame.font.Font(temp_file_name, size) > os.unlink(temp_file_name) > > If that still crashes, then pygame has trouble with that font content, and > then the question would be to figure out what about that font content is > causing problems. If that doesn't crash, then the problem would be with > accessing the content as a file-like object. > > > ... finally, as general advice to all people posting problems - if you can > send a completely self-contained reproducible case, then you are much more > likely to get good help and results faster. As an example in this case, > providing the contents of the self.parts['font'] string in an attached file > with a simple script that tries to load from a StringIO using that file's > contents, would make this easily reproducible and testable by fellow mailing > listers - but without knowing what the contents of the string in question > are, it may actually be practically impossible for anyone else to test > themselves. > > > On Mon, Nov 23, 2009 at 12:38 PM, Bryce Schroeder > wrote: >> >> (My apologies if this is a double-post. I didn't get a copy of the >> message or see it in the archive, so I'm trying again.) >> >> I have a pygame program that worked in the past on both Linux and >> Windows, but now results in a segfault, at least on Linux. (I can't >> test it on Windows.) >> The segfault occurs in this code: >> >> class Font(Resource): >> >> def pygame_font(self,size): >> return pygame.font.Font(StringIO.StringIO(self.parts['font']), >> size) # Segfaults here >> >> >> self.parts['font'] is a string containing a truetype font loaded from >> a file. I have checked that the string contains the file like it is >> supposed too. Any suggestions? > >
Re: [pygame] Font-Related Segfault
The font in question is a custom font in a game data archive. I'm not sure if by "load the font itself" you mean using sysfont to find it or use pygame to open the ttf file, but it's impossible in either case, unfortunately. - Bryce On Mon, Nov 23, 2009 at 12:43 PM, RB[0] wrote: > Why not just let Pygame load the font itself? > > On Mon, Nov 23, 2009 at 2:38 PM, Bryce Schroeder > wrote: >> >> (My apologies if this is a double-post. I didn't get a copy of the >> message or see it in the archive, so I'm trying again.) >> >> I have a pygame program that worked in the past on both Linux and >> Windows, but now results in a segfault, at least on Linux. (I can't >> test it on Windows.) >> The segfault occurs in this code: >> >> class Font(Resource): >> >> def pygame_font(self,size): >> return pygame.font.Font(StringIO.StringIO(self.parts['font']), >> size) # Segfaults here >> >> >> self.parts['font'] is a string containing a truetype font loaded from >> a file. I have checked that the string contains the file like it is >> supposed too. Any suggestions? > >
[pygame] Font-Related Segfault
(My apologies if this is a double-post. I didn't get a copy of the message or see it in the archive, so I'm trying again.) I have a pygame program that worked in the past on both Linux and Windows, but now results in a segfault, at least on Linux. (I can't test it on Windows.) The segfault occurs in this code: class Font(Resource): def pygame_font(self,size): return pygame.font.Font(StringIO.StringIO(self.parts['font']), size) # Segfaults here self.parts['font'] is a string containing a truetype font loaded from a file. I have checked that the string contains the file like it is supposed too. Any suggestions?
