On Mon, Sep 24, 2012 at 12:46 PM, Chris Marshall <devel.chm...@gmail.com> wrote: > Hi Kartik- > > I don't have a working SDL module install that I could > check things out on. The posted gist seemed like a > regression of using direct PDL manipulation to read and > copy the image data to an SDL surface. > > The pdl.pl example seemed ok to me until I tried looking > at the latest XS code where it seemed that the SDL module > doesn't not accept a packed string data as input to the > "surface from" routines.
Still don't have an SDL install but reviewing objects/Surface.xs a bit more it appears that the ->get_pixels_ptr() does return a scalar perl reference to a PV with the string pointer being the pointer to the pixel data. However, the ->new_from() method appears to assume the pixel pointer is actually poked into the RV slot of the dereferenced SV rather than the PV string. This seems inconsistent. --Chris > On Mon, Sep 24, 2012 at 12:39 PM, Kartik Thakore > <thakore.kar...@gmail.com> wrote: >> Whats wrong with >> https://github.com/PerlGameDev/SDL_Manual/blob/master/code_listings/pdl.pl ? >> >> >> On Mon, Sep 24, 2012 at 12:36 PM, Chris Marshall <devel.chm...@gmail.com> >> wrote: >>> >>> 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 >>> >> >> >>
