On Mon, Sep 24, 2012 at 12:46 PM, Chris Marshall 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
> 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
>> 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
>>> wrote:
>>> > On Mon, Sep 24, 2012 at 10:41 AM, Tobias Leich 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 us
