PDL image to SDL::Surface
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
Re: PDL image to SDL::Surface
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 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
Re: PDL image to SDL::Surface
Hi Chris, The performance is poor of course. I tried to use the piddels pointer (->dataref or so) but it looks like it is not pointing to a usable memory area. It looks like there are more than 4 bytes per pixel, and libSDL can't handle that. The pdl.pl example is working, I see colored squares. 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. 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 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
Re: PDL image to SDL::Surface
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 user and developer communities. >> >> Regards, >> Chris >> >> >> On Sun, Sep 23, 2012 at 3:07 PM, Tobias Leich 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 >
Re: PDL image to SDL::Surface
Am 24.09.2012 18:07, schrieb Chris Marshall: > 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. Okay, so we need to change the Surface's XS code to accept that. > >> 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 memory block is not the point. It matters how the pixels are stored in that block. LibSDL can use 1 to 4 bytes per Pixel. And we can tell it how a pixel looks like. If it is RGB or RGBA or ABGR or whatever. But it is important to know how the pixels are stored, since otherwise it might use the alpha channel for the red color. >> 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'm afraid that cygwin support is currently half-broken. If you would install only the libSDL core components and no SDL_ttf stuff you might get a chance to install SDL-perl. > >> 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. Of course. for example: http://sdl.perl.org/documentation.html http://search.cpan.org/~jtpalmer/SDL-2.540/ https://github.com/PerlGameDev/SDL/tree/master/lib/pods > > --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 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
Re: PDL image to SDL::Surface
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 user and developer communities. >>> >>> Regards, >>> Chris >>> >>> >>> On Sun, Sep 23, 2012 at 3:07 PM, Tobias Leich 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 >>
Re: PDL image to SDL::Surface
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 user and developer communities. > >>> > >>> Regards, > >>> Chris > >>> > >>> > >>> On Sun, Sep 23, 2012 at 3:07 PM, Tobias Leich 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 > >> >
Re: PDL image to SDL::Surface
On Mon, Sep 24, 2012 at 12:35 PM, Tobias Leich wrote: > > Am 24.09.2012 18:07, schrieb Chris Marshall: >> 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. > Okay, so we need to change the Surface's XS code to accept that. >> >>> 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 memory block is not the point. It matters how the pixels are stored > in that block. > LibSDL can use 1 to 4 bytes per Pixel. And we can tell it how a pixel > looks like. If it is RGB or RGBA or ABGR or whatever. > But it is important to know how the pixels are stored, since otherwise > it might use the alpha channel for the red color. PDL supports arbitrary numbers of dimensions of data. All that we need to know is how SDL is treating the data so that an equivalent mapping is set up for processing on the PDL side. >> 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. Thanks for the refs. --Chris > Of course. for example: > http://sdl.perl.org/documentation.html > http://search.cpan.org/~jtpalmer/SDL-2.540/ > https://github.com/PerlGameDev/SDL/tree/master/lib/pods > >> >> --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 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 >
Re: PDL image to SDL::Surface
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 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 user and developer communities. >> >>> >> >>> Regards, >> >>> Chris >> >>> >> >>> >> >>> On Sun, Sep 23, 2012 at 3:07 PM, Tobias Leich 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 >> >> > >
Re: PDL image to SDL::Surface
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
Re: [Perldl] PDL image to SDL::Surface
- Original Message - From: "Chris Marshall" To: "Kartik Thakore" Cc: "Tobias Leich" ; "sdl-devel" Sent: Tuesday, September 25, 2012 2:46 AM Subject: Re: [Perldl] PDL image to SDL::Surface Hi Kartik- I don't have a working SDL module install that I could check things out on. Hi guys, Chris, 'cpan -fi SDL' should install SDL-2.54 on your SPP. (You need force because a couple of the SDL tests fail.) During the 'perl build.pl' stage of Alien::SDL you'll be prompted to select which library package to install. I took option 1 because it was "RECOMMENDED", though option 2 is probably more recent. I've run the demo at https://gist.github.com/3772701 but that just produces: C:\_32\pscrpt\pdl>perl pdl2surface.pl No available video device at C:/_32/strawberry516/perl/site/lib/SDLx/App.pm line 123, line 206. SDLx::App::new('SDLx::App', 'title', 'PDL and SDL aplication', 'width', 640, 'height', 640, 'eoq', 1, ...) called at pdl2surface.pl line 12 And same error for https://github.com/PerlGameDev/SDL_Manual/blob/master/code_listings/pdl.pl I don't know what needs to be done in order that a "video device" becomes available. (I'm probably not the sharpest tool in the shed to be using for this ;-) Cheers, Rob
Re: [Perldl] PDL image to SDL::Surface
Can you select a videodriver for SDL by exporting SDL_VIDEODRIVER either fbcon or x11 may fix this. If not then your SDL were not compiled with X11 libs. Install those. On Mon, Sep 24, 2012 at 6:36 PM, Sisyphus wrote: > > - Original Message - From: "Chris Marshall" < > devel.chm...@gmail.com> > To: "Kartik Thakore" > Cc: "Tobias Leich" ; "sdl-devel" > Sent: Tuesday, September 25, 2012 2:46 AM > Subject: Re: [Perldl] PDL image to SDL::Surface > > > > Hi Kartik- >> >> I don't have a working SDL module install that I could >> check things out on. >> > > Hi guys, > > Chris, 'cpan -fi SDL' should install SDL-2.54 on your SPP. (You need force > because a couple of the SDL tests fail.) > During the 'perl build.pl' stage of Alien::SDL you'll be prompted to > select which library package to install. I took option 1 because it was > "RECOMMENDED", though option 2 is probably more recent. > > I've run the demo at > https://gist.github.com/**3772701<https://gist.github.com/3772701>but that > just produces: > > C:\_32\pscrpt\pdl>perl pdl2surface.pl > No available video device at C:/_32/strawberry516/perl/**site/lib/SDLx/App.pm > line 123, line 206. > SDLx::App::new('SDLx::App', 'title', 'PDL and SDL aplication', 'width', > 640, 'height', 640, 'eoq', 1, ...) called at pdl2surface.pl line 12 > > And same error for > https://github.com/**PerlGameDev/SDL_Manual/blob/** > master/code_listings/pdl.pl<https://github.com/PerlGameDev/SDL_Manual/blob/master/code_listings/pdl.pl> > > I don't know what needs to be done in order that a "video device" becomes > available. (I'm probably not the sharpest tool in the shed to be using for > this ;-) > > Cheers, > Rob > > >
Re: [Perldl] PDL image to SDL::Surface
This was for Strawberry Perl on windows so the device should be whatever the default is for windows. If it needs X11, then the build probably did not configure correctly for the platform. It looks like libSDL does support windows and MinGW and the docs do not indicate that X11 is a prerequisite for that. --Chris On Mon, Sep 24, 2012 at 7:03 PM, Kartik Thakore wrote: > Can you select a videodriver for SDL by exporting SDL_VIDEODRIVER > either fbcon or x11 may fix this. If not then your SDL were not compiled > with X11 libs. Install those. > > > On Mon, Sep 24, 2012 at 6:36 PM, Sisyphus wrote: >> >> >> - Original Message - From: "Chris Marshall" >> >> To: "Kartik Thakore" >> Cc: "Tobias Leich" ; "sdl-devel" >> Sent: Tuesday, September 25, 2012 2:46 AM >> Subject: Re: [Perldl] PDL image to SDL::Surface >> >> >> >>> Hi Kartik- >>> >>> I don't have a working SDL module install that I could >>> check things out on. >> >> >> Hi guys, >> >> Chris, 'cpan -fi SDL' should install SDL-2.54 on your SPP. (You need force >> because a couple of the SDL tests fail.) >> During the 'perl build.pl' stage of Alien::SDL you'll be prompted to >> select which library package to install. I took option 1 because it was >> "RECOMMENDED", though option 2 is probably more recent. >> >> I've run the demo at https://gist.github.com/3772701 but that just >> produces: >> >> C:\_32\pscrpt\pdl>perl pdl2surface.pl >> No available video device at >> C:/_32/strawberry516/perl/site/lib/SDLx/App.pm line 123, line 206. >> SDLx::App::new('SDLx::App', 'title', 'PDL and SDL aplication', 'width', >> 640, 'height', 640, 'eoq', 1, ...) called at pdl2surface.pl line 12 >> >> And same error for >> https://github.com/PerlGameDev/SDL_Manual/blob/master/code_listings/pdl.pl >> >> I don't know what needs to be done in order that a "video device" becomes >> available. (I'm probably not the sharpest tool in the shed to be using for >> this ;-) >> >> Cheers, >> Rob >> >> >
Re: [Perldl] PDL image to SDL::Surface
There prebuilt binaries for windows that you can choose when installing Alien::SDL. There is no choice to build libsdl yourself on that platform. And I never heard of that error before. On what type of windows are you exactly? WinXP 32bit? Am 26.09.2012 18:42, schrieb Chris Marshall: > This was for Strawberry Perl on windows so the > device should be whatever the default is for windows. > If it needs X11, then the build probably did not > configure correctly for the platform. It looks like > libSDL does support windows and MinGW and > the docs do not indicate that X11 is a prerequisite > for that. > > --Chris > > On Mon, Sep 24, 2012 at 7:03 PM, Kartik Thakore > wrote: >> Can you select a videodriver for SDL by exporting SDL_VIDEODRIVER >> either fbcon or x11 may fix this. If not then your SDL were not compiled >> with X11 libs. Install those. >> >> >> On Mon, Sep 24, 2012 at 6:36 PM, Sisyphus wrote: >>> >>> - Original Message - From: "Chris Marshall" >>> >>> To: "Kartik Thakore" >>> Cc: "Tobias Leich" ; "sdl-devel" >>> Sent: Tuesday, September 25, 2012 2:46 AM >>> Subject: Re: [Perldl] PDL image to SDL::Surface >>> >>> >>> >>>> Hi Kartik- >>>> >>>> I don't have a working SDL module install that I could >>>> check things out on. >>> >>> Hi guys, >>> >>> Chris, 'cpan -fi SDL' should install SDL-2.54 on your SPP. (You need force >>> because a couple of the SDL tests fail.) >>> During the 'perl build.pl' stage of Alien::SDL you'll be prompted to >>> select which library package to install. I took option 1 because it was >>> "RECOMMENDED", though option 2 is probably more recent. >>> >>> I've run the demo at https://gist.github.com/3772701 but that just >>> produces: >>> >>> C:\_32\pscrpt\pdl>perl pdl2surface.pl >>> No available video device at >>> C:/_32/strawberry516/perl/site/lib/SDLx/App.pm line 123, line 206. >>> SDLx::App::new('SDLx::App', 'title', 'PDL and SDL aplication', 'width', >>> 640, 'height', 640, 'eoq', 1, ...) called at pdl2surface.pl line 12 >>> >>> And same error for >>> https://github.com/PerlGameDev/SDL_Manual/blob/master/code_listings/pdl.pl >>> >>> I don't know what needs to be done in order that a "video device" becomes >>> available. (I'm probably not the sharpest tool in the shed to be using for >>> this ;-) >>> >>> Cheers, >>> Rob >>> >>>