Looking back through the code to the original SDL_Perl I found version 2.0.5 which allows one to actually create an SDL surface from pixel data. More recent versions appear to copy the data and as far as I can tell, there is no way to directly create an SDL surface from external data.
If that is the case (that SDL_CreateRGBSurfaceFrom is not accessible from the perl API), have you implemented another approach to achieve this? Regards, Chris On Mon, Sep 24, 2012 at 12:07 PM, Chris Marshall <devel.chm...@gmail.com> wrote: > On Mon, Sep 24, 2012 at 10:41 AM, Tobias Leich <em...@froggs.de> wrote: >> Hi Chris, >> >> The performance is poor of course. >> >> I tried to use the piddle's pointer (->dataref or so) but it looks like >> it is not pointing to a usable memory area. > > $piddle->get_dataref returns a scalar reference to a perl > PV whose string content _is_ the data block. You should > be able to get the starting location for the pixel data (i.e., > the string) via SvPV. > >> It looks like there are more than 4 bytes per pixel, and libSDL can't >> handle that. > > Per the above, the get_dataref returns an RV to an Sv with > the data in the string. It is just a contiguous block of memory. > As far as I know, all the SDL memory buffers are just > contiguous blocks of memory (ignoring variations due to > stride, alignment,...) > >> The pdl.pl example is working, I see colored squares. > > I don't know what the output should look like. I'm > cc-ing our PDL mailing list in the hopes that someone > with access to both PDL and SDL can give it a try. > > Is there a cygwin install of SDL and libSDL? > >> I think we should need to improve our examples btw, there is not a >> single comment, thats bad. >> In the pdl.pl is a var $ref, which is never used. Thats a bit confusing. > > I think the ref is from a previous iteration in the code > trying to get things working. > > Speaking of documentation, do you have any on the > actual perl<->libSDL bindings an data structures? Trying > to read XS is not the simplest way to sort things out--- > especially since I am far for an expert on some of the > tricky XS technologies. > > --Chris > >> Cheers, Tobias >> >> Am 24.09.2012 16:09, schrieb Chris Marshall: >>> I took a look at the gist and it looks reasonable >>> (I can't run it because I don't have the SDL module >>> and lib installed on my system), however... >>> >>> I would expect the performance to be *very* poor >>> since the image data is essentially being converted >>> from packed byte data to a perl list and then poked >>> a byte at a time into the SDL surface data. >>> >>> The better approach would be to wrap a PDL object >>> (a.k.a. piddle) into an SDL surface. Then you could >>> just lock, copy the data via a PDL direct assignment, >>> unlock and use SDL. There is an examples/pdl.pl >>> that shows how to do the wrapping. >>> >>> BUT, I took a look at the xs code and it appears >>> that your SDL_Surface objects no longer use a >>> packed-string representation for the SDL surface >>> data. If that is the case, I would be surprised if >>> the pdl.pl example works at all now. >>> >>> If someone could verify this, I would appreciate it. >>> If that is the case, it should be straightforward to >>> modify the SDL_CreateRGBSurfaceFrom routine >>> to allow for a SvPV for pixel data as one alternative. >>> >>> Given the power of PDL for whole-image data >>> manipulation, allowing for easy interoperability >>> with the current SDL module would benefit both >>> our user and developer communities. >>> >>> Regards, >>> Chris >>> >>> >>> On Sun, Sep 23, 2012 at 3:07 PM, Tobias Leich <em...@froggs.de> wrote: >>>> Hi, Andrei asked some days ago how to load an image via PDL and but it >>>> in a Surface to use it in SDL. >>>> >>>> The example is here: https://gist.github.com/3772701 >>>> >>>> I'll put that in the examples folder too. >>>> >>>> Cheers, Tobias >>
