Results 1 to 7 of 7

Thread: Lazarus on the Raspberry Pi

  1. #1

    Lazarus on the Raspberry Pi

    Anyone here tried Lazarus on the Raspberry Pi? Iím looking to get an old Delphi game of mine running on the Pi. I read somewhere that Lazarus is now available on the Pi but would be interested to know if anyone has tried it yet.

  2. #2
    Haven't a Pi, yet. But this might help: http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi
    Best regards,
    Cybermonkey

    Pulsar2D framework:
    http://pulsar2d.org

  3. #3
    After following your link I started an update and upgrade to the OS. Several hours later it was still running the upgrade! As I had connected using Putty I was a bit gutted when my laptop decided it was time to turn off to save power during the champions league match, so I didn't notice I'll try again tonight to get fpc and Lazarus installed.

  4. #4
    I have now got fpc and Lazarus running on my Raspberry Pi. The first thing I did was to hit run to display the default form. Disappointingly it took about a minute to compile and run this. If it takes that long I dread to think how long it would take for a large project. I'm hoping to recompile a game I wrote using Delphi so I'll comment here on how long a full application takes to compile.

  5. #5
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    It'll be a lot faster with successive builds as Pascal compilers work differently from say a C++ compiler : they compile the units then build the final output from combining this intermediate stage (as well as normal linking) so that any unit that is unchanged, does not need to be recompiled. Some C/C++ etc compilers have similar optimizations that fit around the language, but that's more of a vendor specific optimization than anything inherent to the language itself. Classicly C compilers concatenate all source into one big file then compile that. (that's why you see compiler level IFDEFs / constant sections in some C source code checking to see if they've already been defined))

    If you do have a fairly modern desktop or laptop, compiling on the Pi isn't the way forward. As good as it is, it's no powerhouse and compilation (as quick as it might be with Delphi/FPC) isn't a task you should expect to be quick in any context. (don't forget your blistering compilation speeds in Delphi have a lot to thank to the far superior processing power of whatever system you used compared to the Pi and the Delphi compiler itself)

    You should examine Cross compilation if working on the Pi is slowing you down, no reason you can't build your Pi executables on your PC (you'll need a proper CVS checkout and build of FPC/Lazarus with all the trimmings to do this properly) and test on the Pi, build to a network directory, execute the app on the Pi automatically as part of execution by writing a script that uses SSH to start the process remotely.

    If you're coding in a cross platform way then you shouldn't be using any specific hardware functionality of the Pi (preferably), So a program/game sucessfully debugged on a PC is going to work on other platforms too. That is to say that once you have a framework that compiles and runs on multiple platforms and works as expected, then anything you build within that framework should be platform agnostic, including the bugs (providing you're using the standard/proven cross platform libs and handling generic cross architecture/platform concerns such as endiness correctly).

    (Oh and obviously if the game calls for it, taking into account the available memory and any performance aspects of the intended devices)
    Last edited by phibermon; 02-05-2013 at 12:49 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  6. #6
    I’ve used GitHub to get my source files onto the Pi. Had a few issues with SDL and some strange settings that the Delphi to Lazarus conversion had thrown in. I’ve commented out some code that uses Bass as the sound dll until I can get round to fixing that. The code now builds but when run I got a black screen. I then run out of time. I next plan to get my code to run the game as a window rather than full screen and single step to see where things are going wrong. At least the code builds which is further than I expected to get.

  7. #7
    I finally got to the bottom of my main bug with my source code. It was down to the file names of the graphics. All the files ended in "PNG" whereas the names used in the code used the lowercase "png". Once I changed the file names the game ran. I still have a couple of problems, one being that when I close the game window a destructor appears to want to do something with an object that is a nil pointer Shouldn't be too much of an issue to fix that one. I then need to reinstate the sound either using Bass or the SDL libraries. I am developing the code via a VNC link so I need to connect a real mouse and keyboard to really see how fast and smooth the game is running. I'm sure there are some tweaks I can do to gain some extra speed. Here is a link to my Blog that shows the game running in a window along with a screen shot of the original ZX Spectrum game that it is based on.

    http://sjm-remakes.blogspot.co.uk/20...ighter-on.html
    Last edited by retrocoder; 09-05-2013 at 12:35 PM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL