[Request] Spriter and Spine (2D Skeleton Animation Software)

rabcor · 2014-10-23 01:31:45

I would love to have a Spriter package and a Spine package in AUR (both are 2D animation software aimed at game development) these 2 are two of very very few alternatives to Adobe Flash Pro for 2D game development with complex animations (from flash games to things like Unity2D)

Spriter is still in development and started as a kickstarter project in 2012, I think it's currently at an RC stage (Late beta/just before 1.0) Spine is a bit older and already being used by many professionally.

Last edited by rabcor (2014-10-23 01:59:20)

Scimmia · 2014-10-23 04:27:04

Sprinter looks pretty straight forward. Spine, not so much (java).

Edit: *sigh*, or not. Seems that it will only look in the run dir for the help files instead of something sane like /usr/share or /usr/share/doc. I guess it will just have to get dumped to /opt.

Edit2:

# Contributor: Doug Newgard <scimmia at archlinux dot info>

pkgname=spriter
pkgver=b10
pkgrel=1
pkgdesc="Intuitive 2D animation and object creation tool for video game makers"
arch=('i686' 'x86_64')
url="http://brashmonkey.com/spriter.htm"
license=('custom')
depends=('imagemagick-no-hdri' 'qtwebkit' 'phonon-qt4')
if [[ "$CARCH" == "x86_64" ]]; then
  _arch=64
  source=("http://www.brashmonkeygames.com/spriter/Spriter_free.tar.gz")
  sha256sums=('51de9683e96c58b7e6c960f346939ae02b9bb4d2a70d44bf07519c86da2e3961')
elif [[ "$CARCH" == "i686" ]]; then
  _arch=32
  source=("http://www.brashmonkeygames.com/spriter/Spriter_free32.tar.gz")
  sha256sums=('c4a8a05ac3898ec3db1d77f4cf67acb68aed02698953155e2df2832baf35cf64')
fi

package() {
  cd "$srcdir/Spriter${pkgver^^}($_arch)"

  install -d "$pkgdir/usr/bin/"
  install -dm777 "$pkgdir/opt/spriter/"
  install -dm700 "$pkgdir/opt/spriter/TexturePackerTemplates/"
  install -m755 Spriter "$pkgdir/opt/spriter/"
  install -m644 SpriterHelp.* "$pkgdir/opt/spriter/"
  install -m644 TexturePackerTemplates/* "$pkgdir/opt/spriter/TexturePackerTemplates"
  install -Dm644 SpriterEULA.txt "$pkgdir/usr/share/licenses/$pkgname/SpriterEULA.txt"
  cp -a docs "$pkgdir/opt/spriter/"
  printf "#!/bin/sh\ncd /opt/spriter/\n./Spriter\n" > "$pkgdir/usr/bin/Spriter"
  chmod 755 "$pkgdir/usr/bin/Spriter"
}

Last edited by Scimmia (2014-10-23 05:47:04)

rabcor · 2014-10-24 09:04:39

Thanks for your help I'd put it up on AUR but I won't be around for about 2 months so I'll wait until then.

But wouldn't it be easy to solve the documentation problem by using symlinks? (i.e. installing the documentation into /usr/share or /usr/doc and then symlinking it to the run dir so the program will still be able to find it?)

If so, where would the rest of the stuff be installed instead of /opt? (Or is there some problem that prevents this approach perhaps?)

Also does it really require imagemagick-no-hdri version? How did you find that out? (It breaks calibre )

Last edited by rabcor (2014-10-24 11:32:21)

Scimmia · 2014-10-24 16:24:28

Normally you'd put the binary in /usr/bin, but you don't want to put everything there, even if it were just a bunch of symlinks.
If you look at the soname of the lib the binary is linked to, yes, it as to be the no-hdri version of imagemagick. It may be possible to make a package that just installs the needed libs and is co-installable with the repo imagemagick package, but I didn't go that far.

galaktor · 2015-03-02 11:06:45

Scimmia wrote:

Spine, not so much (java).

I'm totally new to the PKGBUILD system so I could be wrong. But Spine comes bundled with it's own JRE and uses that on launch. The Linux version comes with shell scripts that do all the lifting. Basically it's just a download-and-run thing. At least that's how it worked for me on a Ubuntu install a while ago.

I have yet to try it on Arch.

The PKGBUILD would then just be:
* source the right package from esotericsoftware for 86 or 64
* put the whole thing in a bin dir
* maybe symlink to launch script, named "spine" or so

Might give this a try if i'm bored - maybe a good way to get into this PKGBUILD business!

Edit:
dependencies might be opengl related. Would have to try and find out.

Last edited by galaktor (2015-03-02 11:12:44)

galaktor · 2015-03-02 14:04:24

What is the common PKGBUILD convention to handle user input or so during install?

The Spine download link is unique for registered users; URL has some hash value in it. I can probably make a PKGBUILD for the Trials, but I suspect serious users would want to be able to provide their unique archive.

Is it possible to ask for optional path to archive during pre-install or so, interactively, and otherwise default to getting the trial?

galaktor · 2015-03-02 16:56:29

I'll probably just go with trial by default, and add a few comments explaining how to set local archive for pro users. "edit the pkgbuild" appears to be the simplest and most accepted way of handling custom settings.

galaktor · 2015-03-03 13:50:47

Alright @rabcor here goes my first ever shot at an AUR package...you can give it a shot if you like.

https://aur.archlinux.org/packages/spine/

You will require a tarball download of spine (trial or full version) matching your architecture (you can choose 32 bit or 64 bit on the download page). You will then have to edit the PKGBUILD and set the 'spinetar' varaible to the path to your downloaded tarball. Otherwise should just work from there (famous last words).

I presume you have a licensed version, which means you are required to download the archive manually (every licensee gets their own url). This works with the trial as well, fwiw.

Let me know how it goes.

Last edited by galaktor (2015-03-03 13:51:15)

Scimmia · 2015-03-03 15:16:50

While I applaud your effort, extracting everything to /usr/bin like that is really, really bad. I would also suggest 2 different PKGBUILDs for trial and full, and you can make it download the sources on the trial by using source_x86_64/source_i686. Using the included JRE is not optimal, either. That is also not what the check function is for.

galaktor · 2015-03-03 15:30:38

Thanks for the feedback.

Why do you suggest a trial package at all? I can't see a scenario where it would be useful given that it doesn't do much (exports) and you cannot just upgrade it, you have to install proper anyway.

The JRE is bundled with the installer, I don't see why it would be wrong to use that? It is part of the official distributed app after all, no?

Re the check function...I realize I'm taking some liberties on the conventions but in this case it seems to work quite nicely if you ignore the fact that I'm making a variable in the script mandatory.

galaktor · 2015-03-03 15:32:01

re /usr/bin, I originally had it go to /usr/local/lib but is there really much difference? /usr/bin seems like an appropriate place for an application such as spine. What alternative are you suggesting?

Scimmia · 2015-03-04 01:40:41

galaktor wrote:

Why do you suggest a trial package at all? I can't see a scenario where it would be useful given that it doesn't do much (exports) and you cannot just upgrade it, you have to install proper anyway.

As the maintainer, that's up to you. I'm just saying that the way it's done right now is pretty clunky.

galaktor wrote:

The JRE is bundled with the installer, I don't see why it would be wrong to use that? It is part of the official distributed app after all, no?

And if every java app included it's own copy of the JRE, would that be fine? Installing a bunch of duplicated crap is one of the things that Unix/Linux tries not to do.

galaktor wrote:

Re the check function...I realize I'm taking some liberties on the conventions but in this case it seems to work quite nicely if you ignore the fact that I'm making a variable in the script mandatory.

This becomes moot once you fix the source array.

galaktor wrote:

re /usr/bin, I originally had it go to /usr/local/lib but is there really much difference? /usr/bin seems like an appropriate place for an application such as spine. What alternative are you suggesting?

/usr/local/lib is even worse, as packages should NEVER touch /usr/local.
/usr/bin is for executables, not entire directory structures. If you can't split it up between /usr/bin, /usr/lib, and /usr/share, you just have to dump the whole thing in /opt.

galaktor · 2015-03-04 07:13:11

You make good points. I agree the way Spine is distributed for Linux is not pure in the Unix sense. It's developed for multiple target platforms and relies on the JRE and libgdx to run on Win/Mac/Linux. Seems reasonable for the devs to use the same simple bundle structure accross the board. And no, I don't mind if apps bring their own runtime - Java or not - as long as it doesn't interfere with my system. Tons of games bring Lua interpreters and proprietary VMs etc, JRE isn't mich different here considering that Spine already is a proprietary, closed-source application.

Also, Spine is very frequently updated through it's built-in update system which means if I was to split it up or remove the JRE, and it works for my test today, that tomorrow's update could break because the devs make assumptions on the app's installation (and rightfully so).

So, as much as I agree that the original Spine package isn't perfect, splitting into multiple places and removing the JRE are not an option for me. I will install to /opt/spine and place a launcher in /usr/bin. The JRE will stay where it is.

As for "fixing the source array", it's not clear to me how to do that given that the http source is unknown for licensed users. Any suggestions? How do other packages typically do that?

Scimmia · 2015-03-04 13:56:50

galaktor wrote:

As for "fixing the source array", it's not clear to me how to do that given that the http source is unknown for licensed users. Any suggestions? How do other packages typically do that?

Simply put the name of the file in the source array and tell the user they have to download it themselves.

galaktor · 2015-03-04 14:45:51

Ok, so I assume that the accepted convention is to know where the $srcdir is located and place the file in there. Sounds good to me, that means I can get rid of the awkward variable. Thanks.

rabcor · 2015-04-03 12:13:57

Nice try galaktor It is a bit of a pain to need to edit the pkgbuild to install though. Scimmia's package was pretty solid (although I'm not a fan of dumping everything into /opt, it's better than dumping everything in /usr/bin)

With that package the downloader wouldn't have to worry about editing the pkgbuild and the maintainer (i.e. you) would only have to worry about regularly updating the pkgbuild's checksum (but well, even after all this time, that checksum still hasn't changed; the program simply hasn't been updated for all these months, so that package is still up to date)

Users will flag the package out of date if the checksum doesn't match which will notify you of when you need to update the pkgbuild, not so hard I think. I would do it myself (that is modify his package a little and then upload it to aur and manage it) as I said before, but I ended up not yet becoming an active user of the program. Maybe later.

Arch Linux

#1 2014-10-23 01:31:45

[Request] Spriter and Spine (2D Skeleton Animation Software)

#2 2014-10-23 04:27:04

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#3 2014-10-24 09:04:39

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#4 2014-10-24 16:24:28

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#5 2015-03-02 11:06:45

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#6 2015-03-02 14:04:24

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#7 2015-03-02 16:56:29

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#8 2015-03-03 13:50:47

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#9 2015-03-03 15:16:50

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#10 2015-03-03 15:30:38

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#11 2015-03-03 15:32:01

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#12 2015-03-04 01:40:41

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#13 2015-03-04 07:13:11

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#14 2015-03-04 13:56:50

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#15 2015-03-04 14:45:51

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

#16 2015-04-03 12:13:57

Re: [Request] Spriter and Spine (2D Skeleton Animation Software)

Board footer