Re: [Pdl-porters] Interfacing SDL Surface with a piddle

2010-06-28 Thread Chris Marshall

On 6/27/2010 12:18 PM, Kartik Thakore wrote:



This is a good idea. How do I make a piddle of bytes 4 * $width * $height ?

At least you would have all the surface and piddle data
in the same spot which seems to be your difficulty here


This might be easier indeed, thanks.


  PDL $width = 640;

  PDL $height = 480;

  PDL $piddle = zeroes(byte,4,$width,$height);

  PDL ?vars
  PDL variables in package main::

  Name Type   Dimension   Flow  State  Mem
  
  $piddleByte D [4,640,480]  P1.17Mb


Re: [Pdl-porters] Interfacing SDL Surface with a piddle

2010-06-28 Thread Chris Marshall

On 6/27/2010 10:59 AM, Kartik Thakore wrote:


Hi

Ok I looked at get_dataref. But I still don't understand why the
surface-pixels is swaped out when a piddle is written. Both of the
Devel::Peek for the get_dataref and surface-get_pixels is the exact same.


get_dataref is a perl reference to the data section of
the piddle.  The surface-pixels is just a pointer to
the pixel data.  I see no copying of data in the code so
it doesn't seem like they should be the same.

I notice on the page you reference for the XS stuff that
there is a surface_new_from routine.  Have you tried
creating a piddle of data the size and structure of the
surface and then creating the desired surface from that?

At least you would have all the surface and piddle data
in the same spot which seems to be your difficulty here.

--Chris


On Sun, Jun 27, 2010 at 1:32 AM, Chris Marshall c...@alum.mit.edu
mailto:c...@alum.mit.edu wrote:

On 6/26/2010 10:49 PM, Kartik Thakore wrote:

Right but where is the piddle xs code?


It is in Basic/Core in the PDL  directory.
The piddle data is in the string of the perl scalar.
That way it gets the advantage of the perl memory
allocation/freeing...

--Chris

On Sat, Jun 26, 2010 at 10:35 PM, Chris Marshall
c...@alum.mit.edu mailto:c...@alum.mit.edu
mailto:c...@alum.mit.edu mailto:c...@alum.mit.edu wrote:

On 6/26/2010 10:10 PM, Kartik Thakore wrote:

What SV_type is getdata_ref using? where can I find that?


You can get a copy of the PDL source from CPAN
and that should explain things.

--Chris





No virus found in this incoming message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 9.0.830 / Virus Database: 271.1.1/2964 - Release Date:
06/26/10 02:35:00






No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.830 / Virus Database: 271.1.1/2966 - Release Date: 06/27/10 
02:35:00





Re: Perl OpenGL Project

2011-07-08 Thread Chris Marshall
A quick SDL heads up:  the Prima::OpenGL strawman implementation
is now working with POGL on cygwin using the native WGL OpenGL
drivers.  For project goal #3 below, I'll be trying to get SDL installed
on cygwin so that I can try using it with POGL for the OpenGL drawing.

Anyone already using SDL + POGL on cygwin (with the Mesa+GLX
rendering)?  Does SDL installation on cygwin use the X11+GLX
framework or the win32+WGL one---as in any bumps I can expect
ahead?

Thanks much,
Chris

On Sun, Jul 3, 2011 at 4:44 PM, Kartik Thakore thakore.kar...@gmail.com wrote:
 Hi Chris,

 I am interested in helping out! Any bugs I can tackle I will take. I am
 also hoping to look at using some of the P5NCI optimizations chromatic
 was talking about but I will wait for a while and learn the code base so
 far.

 P.S. It would be appreciated if you CC'd the sdl-devel@perl.org list. We
 have several ppl on that list that are interested in this project

 Kartik

 On Sun, 2011-07-03 at 14:25 -0400, chm wrote:
 Announcing the new Perl OpenGL project site at
 sourceforge.net.  A read-only git access is at

    git://pogl.git.sourceforge.net/gitroot/pogl/pogl

 I plan on updating the plan going forward but
 the immediate goals are:

 (1) Continue work with Dmitry Karasik to resolve
      win32 and cygwin build issues for his new
      Prima::OpenGL module at

        http://github.com/dk/Prima-OpenGL

 (2) Refactor the perl API bindings to OpenGL
      to use GLEW rather than rolling our own.
      That should allow for an immediate bump
      in OpenGL support to version 4.x.

 (3) Refactor the GUI/system inteface in OpenGL
      to be more platform *and* GUI toolkit
      portable.  The current FreeGLUT default is
      very portable but abstracting the needed
      interface should allow it to be provided
      by *any* GUI library.  This is already getting
      started (surprisingly quickly) in #1.

 (4) Replace platform OpenGL library detection
      in the Makefile.PL by an Alien::OpenGL or
      such approach.  Maybe Alien::GLEW would be
      better here.

 (5) Move from EU::MM to Module::Build to reduce
      platform specific shell and make issues.

 If you are interested in participating, please
 contact me via email or through the sf.net
 project page links at

    http://sourceforge.net/projects/pogl/develop


 Thanks!
 Chris

 --
 Kartik Thakore thakore.kar...@gmail.com




Re: AW: Perl OpenGL Project

2011-07-11 Thread Chris Marshall
From a query to the SDL developers list, there appears
to be a cygports version of SDL that uses gcc-4.3.4 and
the X11 GLX instead of WGL.  I haven't had a chance to
try it but maybe it will resolve this issue as a binary install
option:

  
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/SDL;a=tree

Cheers,
Chris

On Mon, Jul 11, 2011 at 9:44 AM, Chris Marshall devel.chm...@gmail.com wrote:
 I took a look at compiling SDL by hand to see if I could
 figure out what is going on.  It looks like the SDL build
 on cygwin using .configure assumes you'll want the native
 win32 build of SDL.  As far as I can tell, the X11 version
 of SDL should work as well---we'll just have to rework the
 configure.in so it doesn't force win32 when all that perfectly
 good X11 stuff is already there...  sigh.

 I'll put fixing the SDL configure.in to allow cygwin to
 build with X11 (as in *all* the other unix-ish systems)
 on the to do when I get around to it list.

 Thanks for taking a look at the problem.  I think I can
 move forward with the SDL specific stuff on the native
 win32 perls (even though I would like to be able to run
 on cygwin as well).

 Cheers,
 Chris

 On Mon, Jul 11, 2011 at 9:34 AM,  em...@froggs.de wrote:
 After setting the include and lib dirs right and patching SDL's configure
 and configure.in scripts to no set -mno-cygwin i was able to compile a bit.

 But this ends up with stuff like:
 ./src/thread/win32/SDL_systhread.c:98: error: ‘_beginthreadex’ undeclared

 See also:
 http://www.cygwin.com/ml/cygwin/2009-08/msg00280.html

 So now i'm trying to use mingw gcc.


 Zitat von chm devel.chm...@gmail.com:

 On 7/11/2011 1:46 AM, Tobias Leich wrote:

 What did you do to your cygwin system? Shouldn’t be 'gcc' cygwins gcc?

 Got a current cygwin?

 As I mentioned, the -mno-cygwin option has been removed
 from gcc (a.k.a. gcc-4) on cygwin now.  If you wish to
 use the -mno-cygwin option, then the gcc-3 compiler needs
 to be explicitly requested.

 E.g.,

 $ gcc -v
 Using built-in specs.
 Target: i686-pc-cygwin
 Configured with:
  /gnu/gcc/releases/respins/4.3.4-3a/gcc4-4.3.4-3/src/gcc-4.3.4/configure
  --srcdir=/gnu/gcc/releases/respins/4.3.4-3a/gcc4-4.3.4-3/src/gcc-4.3.4
  --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin  --sbindir=/usr/sbin
 --libexecdir=/usr/lib --datadir=/usr/share  --localstatedir=/var
 --sysconfdir=/etc --infodir=/usr/share/info  --mandir=/usr/share/man
 --datadir=/usr/share  --infodir=/usr/share/info --mandir=/usr/share/man -v
  --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
  --enable-version-specific-runtime-libs --with-slibdir=/usr/bin
  --libexecdir=/usr/lib --enable-static --enable-shared
  --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld  --with-gnu-as
 --with-dwarf2 --disable-sjlj-exceptions
  --enable-languages=ada,c,c++,fortran,java,objc,obj-c++  --disable-symvers
 --enable-libjava --program-suffix=-4  --enable-libgomp --enable-libssp
 --enable-libada  --enable-threads=posix --with-arch=i686 
 --with-tune=generic
  --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FO

 R_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake
 GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar

 Thread model: posix
 gcc version 4.3.4 20090804 (release) 1 (GCC)


 and

 $ gcc-3.exe -v
 Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
 Configured with:
  /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure  --verbose
 --program-suffix=-3 --prefix=/usr --exec-prefix=/usr  --sysconfdir=/etc
 --libdir=/usr/lib --libexecdir=/usr/lib  --mandir=/usr/share/man
 --infodir=/usr/share/info
  --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
  --without-included-gettext --enable-version-specific-runtime-libs
  --without-x --enable-libgcj --disable-java-awt --with-system-zlib
  --enable-interpreter --disable-libgcj-debug --enable-threads=posix
  --enable-java-gc=boehm --disable-win32-registry  --enable-sjlj-exceptions
 --enable-hash-synchronization  --enable-libstdcxx-debug
 Thread model: posix
 gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)


 The default compiler in current cygwin installs is
 gcc-4 which is the difference.  Does SDL not build
 on cygwin as an X11+unix platform?

 --Chris

 -Ursprüngliche Nachricht-
 Von: chm [mailto:devel.chm...@gmail.com]
 Gesendet: Montag, 11. Juli 2011 03:24
 An: Tobias Leich
 Betreff: Re: Perl OpenGL Project

 Same problem:

   configure:27759: result: no
   configure:27764: error:
   *** Your compiler (gcc) does not produce Win32 executables!

 I think the normal cygwin gcc + X11 version of SDL
 stands the best chance.

 Cheers,
 Chris

 On 7/10/2011 6:19 PM, chm wrote:

 I'll give the zipball a try. I just installed
 SDL on a strawberry perl portable 5.12.3 install
 so that looks good to go. I'll have to verify
 that it works but all tests pass...

 Cheers,
 Chris

 On 7/10/2011 5:59 PM, chm wrote:

 On 7/10/2011 5:15 PM, Tobias Leich wrote:

 I am

Perl OpenGL-0.65 released

2011-07-22 Thread Chris Marshall
Announcing the release of OpenGL-0.65 to CPAN
and on the POGL sf.net project site:

  http://search.cpan.org/~chm/OpenGL-0.65/
  http://sourceforge.net/projects/pogl/files

This release includes a number of bugs fixed, build
enhancements, and features added.  It could not have
happened without the contributions of Paul Seamons,
Rob/Sisyphus, Dmitry Karasik, kmx, Kartik Thakore,
and others.  Thanks!

Enjoy,
Chris Marshall
  and the POGL developers



++
|  OpenGL-0.65
++

General Notes:

 * This is a point release for the Perl OpenGL module (POGL)
   with new features, bugs fixed and improved documentation.

 * OS/2 is no longer supported by POGL directly.

Highlights:

  * Paul Seamons contributed full tessellation support,
documentation for OpenGL::Tessellation, and a *major* set
of fixes and POD for the existing OpenGL::Array module.

  * The cygwin build of POGL now supports either the native
win32 platform drivers or the X11/GLX bindings (default).
Use interface=w32api or interface=wgl as args to the
perl Makefile.PL to select.  NOTE: you have to pick one
or the other.  If you change, any dependencies such as
PDL::Graphics::TriD will need to be recompiled.

  * The included FreeGLUT DLL has been upgraded to 2.6.0
thanks to Rob/sisyphus.

  * Prima::OpenGL has been released by Dmitry Karasik which
adds support for Perl OpenGL to his cross-platform GUI
toolkit in addition to bug fixes and code cleanup.
Thanks, Dmitry!  See http://search.cpan.org/~karasik/Prima-1.30/
for details.


Re: PDL image to SDL::Surface

2012-09-24 Thread Chris Marshall
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



Re: PDL image to SDL::Surface

2012-09-24 Thread Chris Marshall
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



Re: PDL image to SDL::Surface

2012-09-24 Thread Chris Marshall
On Mon, Sep 24, 2012 at 12:35 PM, Tobias Leich em...@froggs.de wrote:

 Am 24.09.2012 18:07, schrieb Chris Marshall:
 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.

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



Re: PDL image to SDL::Surface

2012-09-24 Thread Chris Marshall
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
 




Re: [Perldl] PDL image to SDL::Surface

2012-09-26 Thread 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
thakore.kar...@gmail.com 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 sisyph...@optusnet.com.au wrote:


 - Original Message - From: Chris Marshall
 devel.chm...@gmail.com
 To: Kartik Thakore thakore.kar...@gmail.com
 Cc: Tobias Leich em...@froggs.de; sdl-devel sdl-devel@perl.org
 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\pdlperl pdl2surface.pl
 No available video device at
 C:/_32/strawberry516/perl/site/lib/SDLx/App.pm line 123, DATA 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: PDL image to SDL::Surface

2012-09-26 Thread Chris Marshall
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
 




Re: SDL 2.0.0 has finally been released

2013-08-15 Thread Chris Marshall
Are there any perl bindings to SDL2?  The libsdl.org site
only lists C#, Pascal, and Python.

--Chris

On Thu, Aug 15, 2013 at 9:08 AM, Kartik Thakore
thakore.kar...@gmail.com wrote:
 Yeah all of them. Also smpeg was missing.


 On Wed, Aug 14, 2013 at 6:10 AM, kmx k...@volny.cz wrote:


 On 13.8.2013 22:24, Kartik Thakore wrote:

 Yeah read this! Hey kmx, anyway you can update the packs? or FROGGS


 If you mean urls in Alien::SDL2 -
 https://github.com/PerlGameDev/Alien-SDL2/blob/master/inc/My/Utility.pm#L58
 - I can do it.

 Just SDL2_xxx packages or should I update also zlib, png, freetype ... to
 the latest versions?

 --
 kmx




Re: SDL 2.0.0 has finally been released

2013-08-15 Thread Chris Marshall
Excellent, thanks for the link!  --Chris

On Thu, Aug 15, 2013 at 9:27 AM, Kartik Thakore
thakore.kar...@gmail.com wrote:
 We are working on it: http://github.com/PerlGameDev/SDL2




 On Thu, Aug 15, 2013 at 9:26 AM, Chris Marshall devel.chm...@gmail.com
 wrote:

 Are there any perl bindings to SDL2?  The libsdl.org site
 only lists C#, Pascal, and Python.

 --Chris

 On Thu, Aug 15, 2013 at 9:08 AM, Kartik Thakore
 thakore.kar...@gmail.com wrote:
  Yeah all of them. Also smpeg was missing.
 
 
  On Wed, Aug 14, 2013 at 6:10 AM, kmx k...@volny.cz wrote:
 
 
  On 13.8.2013 22:24, Kartik Thakore wrote:
 
  Yeah read this! Hey kmx, anyway you can update the packs? or FROGGS
 
 
  If you mean urls in Alien::SDL2 -
 
  https://github.com/PerlGameDev/Alien-SDL2/blob/master/inc/My/Utility.pm#L58
  - I can do it.
 
  Just SDL2_xxx packages or should I update also zlib, png, freetype ...
  to
  the latest versions?
 
  --
  kmx
 
 




Re: SDL 2.0.0 has finally been released

2013-08-15 Thread Chris Marshall
The current POGL module uses XS functions for
constant values.  alias pointed out that that prevents
the perl compiler from doing performance optimizations
resulting bigger, slower code.

For the current POGL2 work, I'm switching to use
constants from the XS loader where the constant
values are determined from the appropriate headers.

It is a bit simpler for the case of OpenGL constants
since their values are actually specified in the
standard so getting them directly from there (via
the GLEW sources) means I don't have to deal
with platform-specific include file processing and
parsing. A nice feature is that it is possible to have
constants for features that may not be supported
by your current runtime environment.  The fact
that they are visible at the perl/source layer is
nice too.

In the SDL2 case, couldn't Alien::SDL2 perform the
constant determination (and even generation) for the
bindings to use?

--Chris

On Thu, Aug 15, 2013 at 9:54 AM, Kartik Thakore
thakore.kar...@gmail.com wrote:
 No problem. Btw do you have any comments on the new Constants.pm ? Using XS
 to load them instead of use constants?


 On Thu, Aug 15, 2013 at 9:53 AM, Chris Marshall devel.chm...@gmail.com
 wrote:

 Excellent, thanks for the link!  --Chris

 On Thu, Aug 15, 2013 at 9:27 AM, Kartik Thakore
 thakore.kar...@gmail.com wrote:
  We are working on it: http://github.com/PerlGameDev/SDL2
 
 
 
 
  On Thu, Aug 15, 2013 at 9:26 AM, Chris Marshall devel.chm...@gmail.com
  wrote:
 
  Are there any perl bindings to SDL2?  The libsdl.org site
  only lists C#, Pascal, and Python.
 
  --Chris
 
  On Thu, Aug 15, 2013 at 9:08 AM, Kartik Thakore
  thakore.kar...@gmail.com wrote:
   Yeah all of them. Also smpeg was missing.
  
  
   On Wed, Aug 14, 2013 at 6:10 AM, kmx k...@volny.cz wrote:
  
  
   On 13.8.2013 22:24, Kartik Thakore wrote:
  
   Yeah read this! Hey kmx, anyway you can update the packs? or FROGGS
  
  
   If you mean urls in Alien::SDL2 -
  
  
   https://github.com/PerlGameDev/Alien-SDL2/blob/master/inc/My/Utility.pm#L58
   - I can do it.
  
   Just SDL2_xxx packages or should I update also zlib, png, freetype
   ...
   to
   the latest versions?
  
   --
   kmx
  
  
 
 




SDL2 + POGL2 + PDL confluence

2013-08-15 Thread Chris Marshall
PDL/SDL/OpenGL users-

With the recently announced SDL2 release and in-progress work
to provide perl bindings for the same, I wanted to share my
thoughts for leveraging joint capabilities of these three
modules with a couple of specific points.

1) SDL2 brings integrated hardware acceleration via Direct3D and/or
   OpenGL to both 2D and 3D graphics.  This offers the possiblity
   of using modern OpenGL API features like renderbuffers for
   computation and display.

2) PDL provides a high level array computation language that
   can be used as a back-end engine for SDL applications and
   visualization.  The PDL::Graphics::TriD currently uses
   the OpenGL-1.x fixed pipeline interface.

3) Perl OpenGL currently supports the original fixed-pipeline
   display process of OpenGL-1.x and some 2.x functionality.
   Work is underway to update the support to modern OpenGL
   APIs such as OpenGL-3.x, OpenGLES,...

The common thread here is OpenGL, and I think that by updating
the OpenGL use and interfaces to the modern programmable display
pipeline we can generate significant synergy between the
projects:

1) Update Perl OpenGL to modern OpenGL (In progress by slowed
   by the fact that my development time is spread too thin.
   Am I the only one with a whole slew of projects for which
   I know *exactly* what and how to do them but not having
   the time to execute?  :-)

2) Refactor PDL::Graphics::TriD to use modern OpenGL for
   display rather than the fixed-function pipeline of OpenGL
   API 1.x.

3) Update PDL to support (simply) the use of arbitrary
   sources of data (e.g., I'm thinking framebuffer and
   renderbuffer objects but deliberately being more
   general since I could also imagine some sort of
   generator that could act like a piddle for computation
   with PDL).

4) Add GPGPU support to PDL computation.

5) Add support to the perl SDL2 interface to allow easy
   mix and match operation with PDL for computation, IO,
   and visualization.  I could see PDL+GPGPU computing
   working well with realtime game or display computations.

Well, the above ideas have a some hand waving to make them
happen, but I think the pieces are there.

Comments?
Chris


Re: SDL2 + POGL2 + PDL confluence

2013-08-16 Thread Chris Marshall
On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore
thakore.kar...@gmail.com wrote:

 I am definitely interested in helping with this. Perhaps we should make a
 test module that tests just these integration.

 It will get latest branches of the 3 projects and run tests.

 What do you think?

I'm glad to see the interest but most of the base work
is still needing to be done as far as the OpenGL stuff.
We need modern OpenGL support in POGL before a lot of
the specific development can occur.

However, one important piece that could be investigated
is how we could make conversion between SDL2 objects
and PDL objects work.  Ideally we could have a fast
conversion to take a piddle and use it for an SDL2 surface
or texture or whatever and similarly for the other direction.

Currently, the approach used for SDL is to create the PDL
object with the right sized data segment and then pass that
to SDL to make a surface from that.  I'm not sure what would
work for SDL2 stuff.

--Chris

 On Thu, Aug 15, 2013 at 1:11 PM, Chris Marshall devel.chm...@gmail.com
 wrote:

 PDL/SDL/OpenGL users-

 With the recently announced SDL2 release and in-progress work
 to provide perl bindings for the same, I wanted to share my
 thoughts for leveraging joint capabilities of these three
 modules with a couple of specific points.

 1) SDL2 brings integrated hardware acceleration via Direct3D and/or
 OpenGL to both 2D and 3D graphics. This offers the possiblity
 of using modern OpenGL API features like renderbuffers for
 computation and display.

 2) PDL provides a high level array computation language that
 can be used as a back-end engine for SDL applications and
 visualization. The PDL::Graphics::TriD currently uses
 the OpenGL-1.x fixed pipeline interface.

 3) Perl OpenGL currently supports the original fixed-pipeline
 display process of OpenGL-1.x and some 2.x functionality.
 Work is underway to update the support to modern OpenGL
 APIs such as OpenGL-3.x, OpenGLES,...

 The common thread here is OpenGL, and I think that by updating
 the OpenGL use and interfaces to the modern programmable display
 pipeline we can generate significant synergy between the
 projects:

 1) Update Perl OpenGL to modern OpenGL (In progress by slowed
 by the fact that my development time is spread too thin.
 Am I the only one with a whole slew of projects for which
 I know *exactly* what and how to do them but not having
 the time to execute? :-)

 2) Refactor PDL::Graphics::TriD to use modern OpenGL for
 display rather than the fixed-function pipeline of OpenGL
 API 1.x.

 3) Update PDL to support (simply) the use of arbitrary
 sources of data (e.g., I'm thinking framebuffer and
 renderbuffer objects but deliberately being more
 general since I could also imagine some sort of
 generator that could act like a piddle for computation
 with PDL).

 4) Add GPGPU support to PDL computation.

 5) Add support to the perl SDL2 interface to allow easy
 mix and match operation with PDL for computation, IO,
 and visualization. I could see PDL+GPGPU computing
 working well with realtime game or display computations.

 Well, the above ideas have a some hand waving to make them
 happen, but I think the pieces are there.

 Comments?
 Chris