[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] chewy changes to cvs



Thanks for the refresher. I used to think I was a C/C++ programmer, but 
now I'm getting spoiled by Java which has few less ways for me to shoot 
myself in the foot. Consequently, I'm all too quickly forgetting where 
the quirks of C/C++ lie. But even so, that was a pretty brainless train 
of thought that led me to that conclusion.

At any rate, pygame is coming along rather nicely. I even added some 
stupid sounds to my stupid little game the other day, and it was 
wonderfully painless!  I have written an extra module that does shaped 
collision detection ( ok, ok, I ripped the code from SGE, but I did 
_assemble_ it myself :) and it plugged nicely into your archetecture. 
Quite wonderful stuff, this pygame!

Thanks again,
Dave.

ShredWheat wrote:

>> Something I noticed in the code could be causing some wierdness, but I 
>> haven't really tested it yet:
>> in surface.c surf_map_rgb declares "color" as an int but uses 
>> PyInt_FromLong(color) to return the value to Python.  I'm not familiar 
>> enough with the Python interface to be sure, but it looks like this 
>> could pick up some garbage from outside the int memory space.
> 
> 
> hi dave, the good news is, no need to worry. 
> this code is fine, but there's a couple quick points i can
> make to put your mind at rest :] 
> 
> the first is inconsequential, but on most 32bit platforms
> "int" is same as "long". both store a 32bit signed integer.
> what makes portable C code somewhat tricky is that a "short"
> is only guaranteed to be sized equal or lesser than an int,
> while "long" is guaranteed to be sized equal or greater than int.
> 
> what makes PyInt_FromLong() work fine with any integer value
> is that C will automatically convert types to another. i could
> pass a float value to PyInt_FromLong and know C will convert it
> to a long for me. most books will explain this under "Standard
> Conversions" or something like that.
> 
> now if PyInt_FromLong took a pointer to a long, then we'd be
> in a world of difference. first, any compiler will complain that
> you passed a pointer to int instead of a pointer to long. the
> compiler should make you "cast" the pointer to the needed type.
> once that is done, then your guess that PyInt_FromLong was getting
> extra random bits woule be correct.
> 
> anyways, hopefully this is just a quick enough intro to C to
> give you a basic idea of what's going on. just because you asked
> though, i did doublecheck the prototype for PyInt_FromLong
> 
> PyObject* PyInt_FromLong(long);
> 
> 
> it makes me smile inside to know people are looking at the code
> though, :]
> 
> 
> 
> ____________________________________
> pygame mailing list
> pygame-users@seul.org
> http://pygame.seul.org



____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org