[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pygame] I'm having problems with the pygame C api
On Wed, 17 Oct 2001, Pete Shinners wrote:
>
> ah, i know the problem :]
>
> pygame's C api actually does some "runtime linking" which means you
> don't need to use the pygame libraries when linking your program.
> this means you need to do a simple "import" before using any of the
> functions from a pygame library.
>
> each pygame module has a sort of "vtable" which is a list of pointers to
> all the functions it contains. the macros you are using simply cast the
> generic vtable function pointers and cast them to the correct prototype.
>
> your code will work fine, you just need to setup the internal vtable
> properly. so whichever pygame module you want to use functions from, you
> just "import" it. you need the surface functions, so call
> import_pygame_surface();
> before making any calls to the functions in that module. for example,
> you can also use the Rect C API functions by doing
> import_pygame_rect();
>
Sure, that makes sense in relation to the broken c program. However,
the Actual Code(tm) has pygame (and pymousetrap) imported from a
python script, before I call the PySurface_Check function in my C module.
So, I should be imported for this function in that case, right? I still
get a false value for PySurface_Check in that case, though the object sure
looks like a pysurface in my debugger.
Sounds like the best way to isolate this is to make a teeny new python C
module that does the PySurface_Check and use it from a python script.
>
> a couple other things on your little "quicky" program. since you created
> your surface with the pygame surface constructor PySurface_NEW(), it is
> a real python object, not just an SDL surface. to "free" the object you
> need to reduce it's refcount "Py_DECREF(pysurf);"
>
Yeah, I'm aware of the ref counting issues, though I didn't remember
to implement it for this little proggie. pymousetrap doesn't leak
like that ;)
> another quick warning.. one thing never tested is initializing some
> parts of SDL through the SDL functions and then using them through
> pygame. there are many ways to likely break things in pygame, but just
> think things out logically and it should work. for example, you are
> calling SDL_SetVideoMode() in your code. this could cause some potential
> wierdness for any pygame functions that desire information about pygame.
>
Good point. Didn't think about that.
> lastly, not all calls in pygame have a C API equivelent. i mainly just
> added functions that support the different pygame object types. if you
> find there's some functions that are really needed and aren't available
> in the API, let me know and they can easily be added to the C API. but
> before you need that, remember you can call any pygame function from C,
> by using functions as python objects..
>
> PyObject *mod, *func, *screen;
> mod = PyImport_ImportModule("pygame.display");
> func = PyDict_GetItemString(PyModule_GetDict(mod), "set_mode");
> screen = PyObject_CallFunction(func, "(ii)", 640, 480);
> Py_DECREF(mod);
>
> anyways, you get the idea :]
Ah, that, too would be an alternative way of isolating this. Still, writing
a little module seems cleanest and the closest approximation to what I'm
trying to do in pymousetrap.
> if you end up stuck, i'll be glad to lend more help
>
Thank you. I still have the question of why PySurface_Check is failing
when both modules are imported from a python script. I can send you
the latest(not yet released) version of pymousetrap and you can see
it failing if you've got a linux system available, it now builds with
pythons other than 2.0 but requires libmousetrap to build. As soon as I
can resolve this I'll be able to release.
If that doesn't work out, I'll make that little test module after I get home
from work this evening and see what happens there.
-b
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org