DEV Community: Ian

Perl, Inline::CPP and the need for speed (sometimes).

Ian — Mon, 13 Mar 2023 18:01:25 +0000

TLDR;
V1 Perl original regex character strip loop: 11 Seconds
V2 Perl manual charatcer strip loop: 40 Seconds
V3 Perl + Inline::CPP character strip loop: 0.92 Seconds
/TLDR

Summary: A dabble with Perl and the great Inline::CPP module to speed up a bit of performance with a bit of old code.

Inline:CPP is a Perl module which makes it really easy to incorporate bits of C++ with Perl. (Why aren't more people using this! You can even create standalone modules without the need for Inline::CPP)

You can find it here

So, I've been trying to optimise some bits of Perl code recently. We all know premature optimisation in code is evil, but there are times when its worth benchmarking your code and sometimes it's surprising where the slow downs occur. Whilst Perl is fantastic for speed of programming, like any language, sometimes we grab the wrong solution or things just grow without checking in on our code.

So, we do a lot of text processing, this IS what Perl IS good for isn't it ? But sometimes we get lazy keeping an eye on our code, as long as it works.

So the original idea of this code (to be fair it was written about 15 years ago by someone else!), was to sanitise some text, strip out excess whitespace (but leave one) and make lower case, for comparing duplicates once all the clutter (punctuation, html etc) was removed.

This is naturally a simplified example.

# get rid of non-alphas and excess spaces and make lower case
sub perl_strip {
        my ( $string ) = @_;
        $string =~ s/[^0-9a-zA-Z]/ /g;
        $string =~ s/ +/ /g;
        $string =~ s/^ +//;
        $string =~ s/ +$//;
        lc $string;
}

Ok, immediately, I suspect there's some better way within regex itself, but as we add more clauses it gets messy (simplified example again).

Anyway, after benchmarking, this looked pretty slow, and it kinda felt dumb looping over the same text even with regex repeatedly. Regex deep down was written in C afaik, so it's fast, but this approach doesn't feel optimal.

So lets try and come up with a general solution that doesn't do that.

At this point, out of interest, I actually asked ChatGPT (I find it good for suggested approaches), and with some coaxing to what was on my mind (it tried the regex only route, but failed with exactness), "we" came up with a simple loop with a check on the previous character/state...

my ($str) = @_;

my $result = '';
my $last_char_was_space = 1;

for my $c (split //, $str) {
    if ($c =~ /[a-zA-Z0-9]/) {
        $result .= $c;
        $last_char_was_space = 0;
    } elsif (!$last_char_was_space) {
        $result .= ' ';
        $last_char_was_space = 1;
    }
}
return lc $result;

Ok, maybe that makes sense logically, but is it faster ? Actually, no. I'm guessing (but don't know), maybe the optimised regex code easily makes up for any improvement in approach.

However, What about if we spend a little time optimising that loop with some C++, it's pretty straightforward and some Perl genius at https://github.com/daoswald/Inline-CPP has made it easy to merge C++ with Perl (note RPerl I think also uses Inline::CPP). Install as usual via

cpan Inline::CPP

So, I've fluffed about with Inline::CPP before a little (not a lot! So let me know flaws here), and thought this was a prime candidate. After all, we do this processing A LOT on a lot of text, ALL the time.

So next step, get my CPP hat (erm ok, well I don't have one, but I can dig out the basics)...and have a play with Perls Inline::CPP

First of all the clutter in CPP, it's a one off, so I don't care too much, setting up the basics is not too complex, but you may need a little digging on some setups and compilers (you will need a C++ compiler on your system).

# set up basic Perl CPP compile/lib options
use Inline CPP => config => typemaps => './typemap'; ## cppxs will look for typemap if you use that
use Inline CPP => config => ccflags => '-Wall -c -std=c++11 -I/usr/local/include';
use Inline CPP => config => inc => '-I/usr/local/include';
use Inline CPP => config => cc => '/usr/bin/g++';
use Inline CPP => <<'END';

#define extract_string_from_scalar_value SvPV_nolen
#define set_string_value_of_scalar_value sv_setpv

Now some C++..it's doing exactly the same logic as the last Perl example, just with C++, then we call it from Perl as a normal Perl subroutine.

// We will call cpp_strip from Perl!! All the subs are exactly the same logic as the Perl code

#include <string>
#include <cctype>
#include <iostream> 
#include <algorithm>
#include <cstring> // for access to std::strlen

// so we know how to convert std::string to Perl strings, see lower down
typedef std::string cppstring;

cppstring cpp_strip(cppstring str) {
        bool last_char_was_space = true;

        std::string result;
        result.reserve(str.size());

        for (char c : str) {
                if (isalnum(c)) {
                        result += char(tolower(c));
                        last_char_was_space = false;
                } else if (!last_char_was_space) {
                        result += ' ';
                        last_char_was_space = true;
                }
        }

        return result;
}

and I call it within Perl later as

$s = cpp_strip( $string );

I also have a typemap file which is referenced earlier as

use Inline CPP => config => typemaps => './typemap';

Note the two statements I had earlier. I did this just to make it easier whenever I read the code, you could just use SvPV_nolen & sv_setpv but I find that messy as it's not clear to me their intention and not the intent to go into that here. We need a typemap just to know how to convert from Perl types to and back from C++ (or other language) types.

#define extract_string_from_scalar_value SvPV_nolen
#define set_string_value_of_scalar_value sv_setpv


TYPEMAP
  cppstring T_CPPSTRING

INPUT
T_CPPSTRING
        $var = ($type)extract_string_from_scalar_value($arg)

OUTPUT
T_CPPSTRING
        set_string_value_of_scalar_value($arg, $var.c_str());

I call this later in Perl as

 $s = cpp_char_strip( $string );

Benchmarks!

So, I looped over the code repeatedly using a largeish lorem ipsum string 100,000 times...benchmarks as follows.

V1 Perl original regex loop: 11 Seconds

V2 Perl manual strip loop: 42 Seconds

V3 Perl + Inline::C++ string loop: 0.92 Seconds

Final thoughts

I do feel like one of Perls strengths is the ability to combine different languages for performance and flexibility and should be used more often!

I'm also interested in using Rust and Golang, probably using FFI to integrate with Perl. I feel like there are a lot of possibilities with mixing languages we don't often explore (we can also use this for any APIs Perl doesn't have solutions for, but other languages do), and I'm hoping to have a dig into that at some point!

If anyone can do it in pure regex, I'm very interested how it will perform.

Full code, including benchmarks, and an even slightly faster (but more complex) solution can be found here

Note: We can also use InlineX::CPP2XS to convert the C++ code to a Perl XS module to include, if you then want to remove the dependency on Inline::CPP.

Perl animated game. Playing with Perl, Inline C++ and SDL2 (part 2!)

Ian — Wed, 24 Mar 2021 08:04:53 +0000

(Full code and Git link at bottom, Part 1 is here)

First things first. On the shoulders of giants are small irrelevant programs made :D. I have to give full kudos to folks who write things like Inline, Inline::cpp, SDL etc. So much work put into things like these, I think they often don't get enough appreciation, so a big round of applause from me.

Our aims in Part 2:

Set up some basic Perl classes for game Entities.
Use Perls Inline::cpp to access more c++ classes and methods (so we can access SDL2).
Get those c++ methods, to take some information from Perl and display to the screen using our system SDL2 lib (installed from Part 1).

We should end up with a window and image as below:

Right, recap time for Part 2!! The main code and Git link is at the end. If you've followed that, you should hopefully have Inline::cpp working with some c++ code, and SDL2 window appearing. Small acorns and all that! Any problems let us know.

So let's develop the Perl and c++ a bit further to get an image on the page, and a basic Object passing some info between the languages.

We'll create an Entity in Perl (i.e an object that represents something we can move about), and the fiddly bit, is an Object in c++ which represents the graphics portion of the object. There's a few ways to skin this cat, and I'm not sure which is the best approach, and I'm happy to hear others ideas.

My main theory is to leave all the graphical heavy lifting on c++, things like graphics, vertices, any big datasets. Then decision making, logic etc, where an object is, the stuff we want to play with easily in Perl. So x,y in Perl, how an object is represented graphically in c++.

For the moment, I'm going to call the Perl game object/entity an erm Entity, and the c++ object a Gfx object, and link the two (well Inline automatically links c++ objects to Perl).

We will end up with:

Perls $some_entity->gfx accesses the c++ Gfx class.
Perls $sdl element accesses the c++ Sdl class.

So I'm going to create a new package for the Entity in Perl. the gfx methods we'll define later in c++ below.

This is going to go right at the top of our code after our "use" statements. It's a basic object with a few attributes. Note the "Gfx"

Perl: Creating a game Entity class, with access to c++ Gfx class.


package Entity;

sub new {
    my $class = shift;
    my $type = shift;

    my $self = bless {
        'alive'   => 1,
        'x'       => 1,
        'y'       => 2,
        'width'   => 100,
        'height'  => 100,
        'type'    => $type,
        'gfx'     => new Gfx,     # Reference a c++ class in later code
    }, $class;

    # Set the x,y coordinates of our new c++ Gfx object.
    $self->gfx->setxy( $self->{ 'x' }, $self->{ 'y' } );   

    return $self;
}

sub gfx    { my $self = shift; return $self->{ 'gfx' } };     # Simple accessor.

Whenever we create a new player, enemy, object, it will have a few attributes, like if it's alive, where it is on the screen etc. Lower down in our main package, we'll create one, which will be the player! It may be nice to create getters/setters for x,y etc, but I'm trying to keep the code down just for the moment for simplicity.

my $player = Entity->new('player');
$player->{ 'x' } = 3;
$player->{ 'y' } = 4;

# $player->gfx->method is calling c++!
$player->gfx->setwidth($player->{ width }, $player->{ height });   # This will reference the c++ class we'll see soon!
$player->gfx->setTextureSlot(1);    # Don't worry about this just yet...it's which image we will use later for the player.

The call..

$player->gfx->someMethod()

is calling the c++ object gfx of class Gfx we have created in our c++ code.

Now, we need Perl to call those c++ classes, and methods. Remember, Inline::cpp makes classes available (and structs with a bit of extra work, see Part 1 tutorial). So let's have a look at an example c++ class to use!

c++ creating our Graphics class that each Perl game Entity will reference

class Gfx {
    public: 
        int x, y, w, h;     // set x,y, width, height
        int textureSlot;    // which texture/image slot this object will use for visuals
        void setxy( int nx, int ny );   
        void setwidth( int nw, int nh );
        void setTextureSlot( int slot );
};

void Gfx::setTextureSlot( int slot ) { textureSlot = slot; }
void Gfx::setxy( int nx, int ny )    { x = nx; y = ny; }
void Gfx::setwidth( int nw, int nh ) { w = nw; h = nh; }

So there's not a lot of clues here, but the c++ Gfx class has an x,y, w(width), h(height), and a couple of methods to set its options we can use on the c++ side. Why don't we write this bit in Perl ? Well, we want to pass some information to various methods in c++, so it makes it simpler passing those types about. Again, there may be a better way to do this!

Now, if you have your code from Part 1, we also had the Sdl class. We're going to extend that a bit to be able to store an image.

This is in the existing Sdl class (from Part 1)

  const int NUMBER_OF_IMAGES = 2;

  SDL_Texture *textureList[ NUMBER_OF_IMAGES ];
  SDL_Rect currentSpritePos;
  SDL_Surface* tempSurface;


  void loadImageIntoSlot( char *newImage, int slot ) {
        tempSurface = IMG_Load( newImage );
        if( tempSurface == NULL ) {
                std::cout << "Unable to use surface\n";
        } else {
                SDL_Texture *myTextureAddress = SDL_CreateTextureFromSurface( renderer, tempSurface );
                textureList[ slot ] = myTextureAddress;
        }
        if( textureList[ slot ] == NULL ) { std::cout << "Unable to load image \n"; }
        SDL_FreeSurface( tempSurface );
    }

Eeek! What on earth ? Ok, this is where the SDL docs need to be read a bit to understand what each one does. There's a wiki at https://wiki.libsdl.org/ but it needs a bit of digging through the tutorials and API.

So what I'm doing here, is creating a method which will take (from Perl in our case) the name of an image, which "slot" we'll load it into (just our own array here, so we can reuse image/textures). Convert this to a texture, which we'll store in the graphics card. So we'll have an array of pointers to texures/images.

So we do

tempSurface = IMG_Load( newImage );

load in the image from the filesystem, and test it loaded ok.

SDL_Texture *myTextureAddress = SDL_CreateTextureFromSurface( renderer, tempSurface );

This is creating a texture from the image. The difference here, is that in SDL2 the textures can be stored on the graphics card. So we'll manipulate "textures" now instead of images.

SDL_FreeSurface( tempSurface );

We no longer need that temporary bit of image/surface space, so we'll get rid of it to be nice and clean.

Now, we're going to create another couple of c++ methods.

First one, clear the "renderer" or screen in this case (sort of), but we'll set a colour for it to clear to. In this case, a healthy "grey" colour ;). (couple of languages differences for our friends over the pond there ;))

    void renderClear() {
        SDL_SetRenderDrawColor(renderer, 200, 200, 200, 200);
        SDL_RenderClear(renderer);
    }

Then renderPresent will update the screen with any rendering we've stored (we save it to a buffer which then gets splatted to the screen).

    void renderPresent() {
        SDL_RenderPresent(renderer);
    }

Now, this following bit, we're just using the Perl entities gfx reference, copying the basic values into an Sdl rect, and then passing to an SDL Render method, which takes a texture, a position (our Rect) and displays it on the screen with SDL_RenderCopyEx. There's a couple of bits on there, like SDL_FLIP and whether we it to be a mirror image reversed or not. Why don't we just pass the Perl entity ? c++ doesn't know about Perl objects, and Perl doesn't know about SDL Rect types, so we have to convert them.

    void updatePosition( Gfx *gfx ) {
        currentSpritePos.x = gfx->x;
        currentSpritePos.y = gfx->y;
        currentSpritePos.w = gfx->w;
        currentSpritePos.h = gfx->h;
        SDL_RenderCopyEx(renderer, textureList[ gfx->textureSlot ], NULL, &currentSpritePos, 0.2, NULL, SDL_FLIP_NONE);
    }

Now, finally back to Perl! We've created our $sdl object in Part1 which opened up a window and referenced Sdl2.

We'll now call these new c++ methods, firstly to load our image.
Then to clear the screen to grey.
Then to update our c++ reference to our Entity with our new position.
Then to splat the screen with the buffered texture.

$sdl->loadImageIntoSlot("Camel1.png", 1);
$sdl->renderClear();
$sdl->updatePosition( $player->gfx );
$sdl->renderPresent();

You can download the Camel from Github here, save into the same folder as the script.

FULL CODE BELOW (or Git link at bottom)! (Save both sections in one file)

Perl code:

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper;
use Time::HiRes qw( usleep gettimeofday );

use Inline CPP => config => libs => '-L/usr/local/lib -lSDL2 -lSDL2_image -lSDL-Wl,-rpath=/usr/local/lib';
use Inline CPP => 'DATA';

# Game object class
package Entity;

sub new {
    my $class = shift;
    my $type = shift;

    my $self = bless {
        'alive'   => 1,
        'x'       => 1,
        'y'       => 2,
        'width'   => 100,
        'height'  => 100,
        'type'    => $type,
        'gfx'     => new Gfx, # calling c++ class
    }, $class;

    # calling c++ Gfx class
    $self->gfx->setxy($self->{ 'x' },$self->{ 'y' });

    return $self;
}

sub gfx    { my $self = shift; return $self->{ 'gfx' } };


package main;

# Set up a new Graphics window for the game
my $sdl = Sdl->new; # Calling c++ class
$sdl->init();

# Create our player
my $player = Entity->new('player');
$player->{ 'x' } = 3;
$player->{ 'y' } = 4;

# Call c++ class/methods below, so c++ has the correct positional info

$player->gfx->setwidth($player->{ 'width' }, $player->{ 'height' });
$player->gfx->setTextureSlot(1);

# Store our image in an texture/image array slot
$sdl->loadImageIntoSlot("Camel1.png", 1);

# Clear the screen in grey
$sdl->renderClear();

# Draw our player
$sdl->updatePosition( $player->gfx );

# Update the screen from our drawn buffer
$sdl->renderPresent();

sleep 2;


__DATA__
__CPP__

c++ code

#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <iostream>
#include <map>

const int SCREEN_WIDTH = 800;
const int SCREEN_HEIGHT = 600;
const int NUMBER_OF_IMAGES = 2;

SDL_Renderer *renderer = NULL;
SDL_Window *window;
SDL_Surface* tempSurface;

// Class that Perl references, so SDL can access the relevant Perl game Entity variables

class Gfx {
    public: 
        int x, y, w, h;
        int textureSlot;
        void setxy( int nx, int ny );
        void setwidth( int nw, int nh );
        void setTextureSlot( int slot );
};

void Gfx::setTextureSlot( int slot ) { textureSlot = slot; }
void Gfx::setxy( int nx, int ny ) { x = nx; y = ny; }
void Gfx::setwidth( int nw, int nh ) { w = nw; h = nh; }

// Set up our SDL Window and Renderer for displaying to the screen

class Sdl {
  private:

  public:

    Sdl() {
        std::cout << "C++ Constructor for Sdl\n";
    }   
    ~Sdl() {
        std::cout << "C++ Destructor for Sdl\n";
    }

    SDL_Texture *textureList[ NUMBER_OF_IMAGES ];
    SDL_Rect currentSpritePos;

    int init() {
        int x = SDL_Init(SDL_INIT_VIDEO);
        if( x == 0 ) {
            window = SDL_CreateWindow("SDL2 Window",
                                       SDL_WINDOWPOS_CENTERED,
                                       SDL_WINDOWPOS_CENTERED,
                                       SCREEN_WIDTH, SCREEN_HEIGHT,
                                       0);
            renderer = SDL_CreateRenderer( window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC );
        } else {
            std::cout << "Had a problem creating a window! " << SDL_GetError();
        }
        if( window == NULL ) {
            std::cout << "Window null";
            exit( 0 );
        }
        if( renderer == NULL ) {
            std::cout << "Renderer null";
            exit( 0 );
        }
        return 0;
  }


   // Save our image as a texture into an array of possible textures
    void loadImageIntoSlot( char *newImage, int slot ) {
        tempSurface = IMG_Load( newImage );
        if( tempSurface == NULL ) {
                std::cout << "Unable to use surface\n";
        } else {
                SDL_Texture *myTextureAddress = SDL_CreateTextureFromSurface( renderer, tempSurface );
                textureList[ slot ] = myTextureAddress;
        }
        if( textureList[ slot ] == NULL ) { std::cout << "Unable to load image \n"; }
        SDL_FreeSurface( tempSurface );
    }

    // clear the screen in grey
    void renderClear() {
        SDL_SetRenderDrawColor(renderer, 200, 200, 200, 200);
        SDL_RenderClear(renderer);
    }

    // update our Graphics card buffer
    void renderPresent() {
        SDL_RenderPresent(renderer);
    }

    // Render our texture to the screen in the correct position.    
    void updatePosition( Gfx *gfx ) {
        currentSpritePos.x = gfx->x;
        currentSpritePos.y = gfx->y;
        currentSpritePos.w = gfx->w;
        currentSpritePos.h = gfx->h;
        SDL_RenderCopyEx(renderer, textureList[ gfx->textureSlot ], NULL, &currentSpritePos, 0.2, NULL, SDL_FLIP_NONE);
    }


};

Code and image all avaiable on Github here

Extra thoughts:
methods like renderClear(); feel too SDL specific, so maybe Perl should start to reference more graphics library agnostic names. Eg clearScreen() and updateScreen(), then if we want to use Opengl or something, the Perl part of the code would likely need to change less.

Perl animated game. Playing with Perl, Inline C++ and SDL2 (part 1!)

Ian — Sat, 20 Mar 2021 16:15:40 +0000

TLDR; We're going to create a (very basic) animated game using Perl, Inline and C++, screenshot of it in action at the top of this page! Github link to code here, part 2 blog here

Be gentle, this is my first ever post!

Firstly, I'm not a C++ programmer. I don't really know SDL2 either. Also my Perl is quite ordinary :D. However I do like exploring, and I'm going to do the odd blog not as a tutorial, but just highlighting my experiences. Some things I'll get wrong or won't understand, but that's fine, it may highlight weak points in myself, documentation, or something else!

Secondly, say hello to a new Camel at the top, drawn by a friend Tommy Cameron for this blog, and will appear in the SDL2 graphics later. More of his stuff here.

With that disclaimer out of the way, there have been quite a few times I've wanted to explore the following....

1) Integrating Perl with other languages, especially with none trivial objects or data.
2) Integrating Perl with system libraries.
3) Integrating Perl with graphics.
4) Play with SDL2 and OpenGL. I can't really tell if Perl SDL is relevant any more.
5) Look at Perl c stuff. All the Perl SV variables and functions feel too difficult to use when in explore mode to amend their code. Whoever named all the SV stuff needs erm, something doing to them :). It's always put me off, so I'm trying easier routes to explore.

So, here we go, lets see if I can achieve some of the above. In this case with C++ and Inline (I want to explore FFI->Platypus to compare at some point as well).

What is SDL ? It's a "Simple" DirectMedia layer that comes with most systems. It's mainly used for 2d graphics manipulation in its own graphics window, but also deals with sounds, keyboard events and things like that. SDL2 adds some new features, like storing textures in graphics card memory, interfacing with OpenGL and a few bits like that.

What is Inline ? Inline is a way of combining another languages code to intermingle with Perl code. You can currently Inline C, C++, Python and some others, as well as have a stab at creating your Inline module for a new language if you want! At a simple level, it parses the code, and looks for structs, method signatures etc, and makes them available to Perl. You need to be wary of complex datatypes though, you will need to convert those yourself in code, we'll do some of that.

So firstly, let's make sure SDL2 is installed. I'm using Linux Mint (and also the Raspberry PI) , so some the initial package install may vary depending on your distro.

sudo apt install libsdl2-2.0-0 libsdl2-dev
sudo apt install libsdl2-image-dev libsdl2-image-2.0-0

If you're not sure what the package names are, try searching with apt or yum, eg

apt search libsdl2  or yum search libsdl2

You will need the library itself and the dev packages for compiling against.

Next, lets install Perls Inline::CPP via CPAN.

cpan install Inline::Struct
cpan install Inline::cpp

Make a cup of tea if you are doing this on the Pi. Or two. Or cut out the middle man and go straight for the Cider.

Still here (and sober)? :)

If you get stuck on any of the Inline bits, it's worth checking out Inline::CPP docs and Inline docs

So, we need to get Inline working with the system SDL library we have just installed. Let's have a go. We'll start with our usual strict, warnings, Dumper, and a highres time module.

use strict;
use warnings;
use Data::Dumper;
use Time::HiRes qw( usleep gettimeofday );

Now we'll get to the fiddly bit, that may vary, but works for me on both systems...

use Inline CPP => config => libs => '-L/usr/local/lib -lSDL2 -lSDL2_image -lSDL-Wl,-rpath=/usr/local/lib';
#use Inline CPP => config => ccflags => '-Wall -c -std=c++11 -I/usr/local/include';
#use Inline CPP => config => inc => '-I/usr/local/include';
#use Inline CPP => config => cc => '/usr/bin/g++';

The first line tells Inline::CPP which libraries we want to use, and where to find them. If you want to add a new library to interface with, add it to this line. You can find the docs in library imports here.
The rest is for the compiler, where it is and what options to compile with. I've left some options commented out, that could be useful to test if you have a problem, but may cause problems for others on a different OS.

IMPORTANT: If you edit some of the CPP config bits above, you may need to delete the Inline cache to reset it. Inline creates some cache files in your current directories ./_Inline folder. You can safely delete this any time you need to reset it. You shouldn't need to bother with this if just amended most normal source code.

So, to include C++ code with our Perl and Inline::CPP, we need to tell Perl where the C++ source code is. We can tell it to look for code after the "DATA" section with

use Inline CPP => 'DATA';

At this point, I'm going to jump straight in and add some! Add this to the end of the code.

__DATA__
__CPP__

#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <iostream>
#include <map>

const int SCREEN_WIDTH = 800;
const int SCREEN_HEIGHT = 600;
const int NUMBER_OF_IMAGES = 2;

SDL_Renderer *renderer = NULL;
SDL_Window *window;
SDL_Surface* tempSurface;

We're basically including the relevant header files for SDL2 to make the SDL resources available to C++ and a few other useful starting points.

Note, we can now reference SDL objects like SDL_Window and things like that.
There's a really great and useful C++ SDL2 tutorial here. I'd recommend giving it a view, and the first sections of that, will closely match some of the code here, because it may get tricky without having an appreciation of SDL.

I'm now going to create my very own C++ class (I'm new to these!). With this, we can initialise an SDL window to test everything works.

We can create an SDL Window and renderer (an object we can manipulate to display to the window) with

SDL_CreateWindow("SDL2 Window", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, SCREEN_WIDTH, SCREEN_HEIGHT, 0);
SDL_CreateRenderer( window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC );

and I'm now going to include that in a c++ class init function (below DATA again in your code), that we'll call from Perl...

class Sdl {
  private:

  public:

    Sdl() {
        std::cout << "C++ Constructor for Sdl\n";
    }   
    ~Sdl() {
        std::cout << "C++ Destructor for Sdl\n";
    }


    int init() {
        int x = SDL_Init(SDL_INIT_VIDEO);
        if( x == 0 ) {
            window = SDL_CreateWindow("Perl/Inline/C++ Game!!!",
                                       SDL_WINDOWPOS_CENTERED,
                                       SDL_WINDOWPOS_CENTERED,
                                       SCREEN_WIDTH, SCREEN_HEIGHT,
                                       0);
            renderer = SDL_CreateRenderer( window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC );
        } else {
            std::cout << "Had a problem creating a window! " << SDL_GetError();
        }
        if( window == NULL ) {
            std::cout << "Window null";
            exit( 0 );
        }
        if( renderer == NULL ) {
            std::cout << "Renderer null";
            exit( 0 );
        }
        return 0;
  }

};

I'm going to leave some debugging in for you, so you can see what happens later.

NOW, we can access this class from Perl! Any C++ classes are available from Perl that you create. There are no accessor/setter/getter functions automatically, so you need to create those yourself.

Sidenote, if you want to use a c++ struct, you can change one of the Inline statements earlier to include some. This would look like

use Inline CPP => 'DATA', structs => ['State'];
my $state = Inline::Struct::State->new;
my $is_alive = $state->alive();

#in your c++ code...
struct State {
    int alive;
};
typedef struct State State;

This would access a State struct that you declared in your c++. The handy thing here is that any Structs declared, do have getters and setters, eg $state->alive, rather than $state->{ alive } or whatever.

We're not using structs just at the moment (just thought it useful to be aware as an option), so back on to the rest....

At the top of page, after your "use" commands, add the following lines.

my $sdl = Sdl->new;
$sdl->init();
sleep 2; # just so you can see the window open!

Our complete code should look like (include both c++ & Perl sections in one big file for the moment)...

Perl

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper;
use Time::HiRes qw( usleep gettimeofday );

use Inline CPP => config => libs => '-L/usr/local/lib -lSDL2 -lSDL2_image -lSDL-Wl,-rpath=/usr/local/lib';

use Inline CPP => 'DATA';

my $sdl = Sdl->new;
$sdl->init();
sleep 2;


__DATA__
__CPP__

c++

#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <iostream>
#include <map>

const int SCREEN_WIDTH = 800;
const int SCREEN_HEIGHT = 600;
const int NUMBER_OF_IMAGES = 2;

SDL_Renderer *renderer = NULL;
SDL_Window *window;
SDL_Surface* tempSurface;

class Sdl {
  private:
  public:

    Sdl() {
        std::cout << "C++ Constructor for Sdl\n";
    }   
    ~Sdl() {
        std::cout << "C++ Destructor for Sdl\n";
    }

    int init() {
        int x = SDL_Init(SDL_INIT_VIDEO);
        if( x == 0 ) {
            window = SDL_CreateWindow("Perl/Inline/C++ Game!!!",
                                       SDL_WINDOWPOS_CENTERED,
                                       SDL_WINDOWPOS_CENTERED,
                                       SCREEN_WIDTH, SCREEN_HEIGHT,
                                       0);
            renderer = SDL_CreateRenderer( window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC );
        } else {
            std::cout << "Had a problem creating a window! " << SDL_GetError();
        }
        if( window == NULL ) {
            std::cout << "Window null";
            exit( 0 );
        }
        if( renderer == NULL ) {
            std::cout << "Renderer null";
            exit( 0 );
        }
        return 0;
  }

};

If you run it, Perl should access the Sdl class with Sdl->new and $sdl->init(), which will open a new (empty) window and wait for a few seconds before quitting.

So that's the end of part 1! Part 2 we'll get some images displaying and moving.

It's only getting a window up, but it's the nuts and bolts of getting Inline, a class working, and SDL. I'll try and flesh it out with more Perl code, to add a game loop and some things moving about!

Note, we can probably remove the Inline dependency once we've finished, as there's a converter to XS.

Conclusions so far, are that it's relatively easy to incorporate. Memory cleanup seems to behave so far (c++ objects seem to get cleared up, but bad code in c++ will probably behave worse than Perl), and it's avoided so far any evil SV type bits (although there may be a small bit of that in part2!).

Have fun everyone, and thanks for reading!

Part 2 is now here

(I can be reached on FB or ians.coding at gmail.com)

(I'm Linux only, so if there are any Windows/Mac users, who can try the SDL lib section at the start and let me know any modifications to work on Windows/Mac I'd be happy!)