Hello, sorry... I meant that you need to RAISE, then return -1;
yeah, I think the keyword arguments do cause bugs... However it does say in a few places that they aren't used like keyword arguments. Definitely one of pygames warts. That'd be great if you could test out keyword argument performance. The docs are here: http://docs.python.org/api/arg-parsing.html Look down the page at ... ParseTupleAndKeywords . Then if you can't figure out usage from that page(no examples are there) check the python source, or google for ParseTupleAndKeywords. The SRCALPHA bug has caused a lot of confusion too... hopefully that won't happen now so much. I usually just used convert_alpha() as a work around for not understanding how to get SRCALPHA working too. On 8/22/07, Brian Fisher <[EMAIL PROTECTED]> wrote: > On 8/21/07, René Dudfield <[EMAIL PROTECTED]> wrote: > > It turns out you need to raise exceptions from init methods like this: > > RAISE (PyExc_SDLError, SDL_GetError ()); > > return -1; > > > I'm not sure what part of those to lines you are referring to when you > say "like this" - It looks like you are saying all init methods must > raise an exception type of SDL error and must propagate the text of an > SDL error - but if your error doesn't come from SDL, than I can't see > how that would apply? > > > > Another TODO is to check for endian compliance... I'm not sure if the > > masks are set correctly in there for big endian. There's no checks in > > the source for endian anyway. > > > I don't see why endian-ness would have anything to do with the masks > you pass in... if you passed in some masks, than I would assume those > are the mask you want to use... like say you passed in a mask that > says blue is in the msb - then you want it in the msb, right? > endianness only affects the translation from byte order to byte > significance in an int... i.e. it would only be an issue if they had > been asking for byte order and we were building a mask from that. > > > > However I haven't added your test for keyword arguments yet. I'm not > > sure it's a good idea or not to add keyword argument support to all > > the functions this late in the release process. We'd need a bunch > > more tests, and need to measure any performance difference adding > > keyword arguments would make. If keywords don't add any performance > > change for the case when they are not used, then they should > > definitely go in. If it makes games drop from say 30fps to 20fps... > > then they should definitely not go in. We need to test it. > > > Well I'd be happy to do a lot of the coding and performance testing > for supporting keyword arguments if I knew how to write extension code > to make keyword arguments work... does anybody know how to do that? > > Also, for what it's worth, after I discovered this bug, I found that > it affected half of the times I had made surfaces, and in some places > I put in convert_alpha crap to work around it. meaning I think people > hit the keyword argument not working thing a lot, especially > considering the docs imply the keyword arguments will work. >
