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.

--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
>> >>
>
>

Reply via email to