[Pysdl-devel] win32 progress

[Pete S. <pe...@sh...>]

for all who care about how my win32 porting progress is going...

my job tonight was to get the video system initializing.
i knew there was some extra work to do as pysdl started up
on WIN32. a little tip from mbaker got me moving in the right
direction and the good news is the video system now works great!

i did some experimenting with a window and some fun with
surface.fill_rect(). all seems to be working as expected.


sadly, it's not all good news, and here's where i again look
for a little direction from you who might know more about such
things...


python is dumping in the calls sdl_image_load and sdl_sound_load.
i've been spending my time attacking the sdl_image_load, but it
seems curious that the same problem exists in sdl_sound_load.

<lament>
i was hopeful for the starfield example, since it requires
no image library. ALAS, the win32 python binary doesn't come
with the "rand" module compiled in. this'll be a project for
tomorrow night.
</lament>

anyways, i ran it through the standard gauntlet of testing.
i tried both BMP and GIF. (i tried JPG too, only to discover
JPG doesn't come standard with SDL_Image for win32, urg)
i also tried passing in a filename, and a opened binary file
handle. same results with both.

things are crashing on the meat and potatos line of sdl_image_load
in sdlmodule.c:

surface_ref = sdl_surface_NEW(IMG_Load_RW((SDL_RWops*)ops_ref, 0));

to be truthfull, i haven't gotten much further than this, but i'm
highly suspect of the RW object right now. i can see this is an
SDL thing. a wrapper around the usual <stdio.h> methods. i nice way
to make things flexible.

the bottom line of all this, is i'm hoping a lightbulb is flashing
over someone's head right now, and they have a good hunch of what
the problem is. it'll save me a bit of time as i dig in tomorrow
evening. share!



it will be a good day when i get a live feed of pandas on
my win32 desktop! thanks to all those that've helped me get
this far.