TODO

• https://github.com/aseprite-gpl → http://github.com/LibreSprite

REFERENCE

• #8
• #10

It's been almost a month since me and @PerryHugh got added to the LibreSprite team. To make this more known to people as a working project, and not a dead one, I think that a new release would be great. I'm not sure what version it should be, but here are the main three options:

• v2
• v1.1
• v1.0.1
  According to SemVer, option 3 would be correct. But for the good of LibreSprite (gaining more attention) the first option would be better. The question is, being correct, or gaining more attention?

I have created a new label, cherry_pick. Before our release, we should pick some doable features/issues, and have these assigned.

@maujin11 had an awesome idea, (Pixel Art Jam/Contest) more about it here. I think that this would gain some new users, just like he said. I'm kind of iffy on a "free steam game" as recognition on the site should be enough. August 1st sounds like a nice date to me. We could take this to a monthly or bimonthly art jam.

After this is said and done, a post on the website should seal this (v2) up.

When you export a sprite (like following example), LibreSprite duplicates linked frames.

Code comment mention linked frame reuse attempt:

vautour.zip

The Issue

I use the Flatpak version of the Libresprite, and everything works fine, until i open a new Canvas, then the program starts to "run in low fps" (I don't know how to explain this.), i can brush, can draw, i can do every single thing, but it's totally "lagged"

Example GIf

Edit:
It stops the "low fps" when running on 100% zoom level.

Temporary Fix

100% Screen Scaling
200% UI Elements Scaling (It looks like 200% Screen Scaling, fixes the "low fps")

LibreSprite and System version

• LibreSprite: 1.0-dev
• System: Linux Mint 19.1 (AMD) (I never tested on other Distros. Maybe i'll on Ubuntu 19.04.)

I don't think I have permission to change the logo for the organization. @akien-mga or @Calinou , could you maybe change the profile picture the the libresprite logo? The github default looks unprofessional.

This is another thing related to rebranding. Can we use existing (aseprite) logo? Even if we could i think we should create a new one.

It would be a good idea to name the installers for the current version. Whether alpha, beta or stable. Example: libresprite_V1_0_beta.exe. To let the user know which version they are downloading. Regardless of the build.

Recently installed the Windows 10 port of LibreSprite, the installation went without a hitch but BitDefender somehow read gen.exe as a threat.

As #1 suggested, this is an issue to discuss a new name for the program. I think it would be good to rename sooner than later.

Just random ideas:

• beesprite (instead of a-sprite), B following the letter A
• deusprite (instead of ace-sprite), 2 following the playing card Ace

Or something completely original and new maybe.

Currently gtest is one of the only libraries that can't be readily unbundled. The fix is trivial and I already have a patch for this I need to clean up and make a PR with: http://svnweb.mageia.org/packages/cauldron/aseprite/current/SOURCES/aseprite-1.1.4-mga-shared-gtest.patch?view=markup

Steps to reproduce

git submodule update --init
rm -rf third_party/{curl,freetype2,giflib,gtest,jpeg,libpng,libwebp,libwebp-cmake,tinyxml,zlib}
// the above leaves a couple third party libraries that I haven't tried/managed yet to unbundle on my distro
cmake -DENABLE_UPDATER=OFF \
      -DENABLE_WEBSERVER=OFF \
      -DUSE_SHARED_ALLEGRO4=OFF \
      -DUSE_SHARED_CURL=ON \
      -DUSE_SHARED_FREETYPE=ON \
      -DUSE_SHARED_GIFLIB=ON \
      -DUSE_SHARED_GTEST=ON \
      -DUSE_SHARED_JPEGLIB=ON \
      -DUSE_SHARED_LIBPNG=ON \
      -DUSE_SHARED_LIBLOADPNG=ON \
      -DUSE_SHARED_LIBWEBP=ON \
      -DUSE_SHARED_PIXMAN=ON \
      -DUSE_SHARED_TINYXML=ON \
      -DUSE_SHARED_ZLIB=ON \
      -DWITH_WEBP_SUPPORT=ON

Result:

CMake Error at third_party/CMakeLists.txt:52 (message):
  gtest/gtest.h is missing.  Initialize submodules: git submodule update
  --init --recursive

Describe your bug report or feature request here
Compile fails, I have piggy backed off the AUR of libresprite and have done the following:

mkdir -p build && cd build
git submodule update --init --recursive
cmake -DUSE_SHARED_PIXMAN=ON
-DWITH_WEBP_SUPPORT=ON
-DUSE_SHARED_LIBWEBP=ON
-DUSE_SHARED_CURL=ON
-DUSE_SHARED_GIFLIB=ON
-DUSE_SHARED_JPEGLIB=ON
-DUSE_SHARED_ZLIB=ON
-DUSE_SHARED_LIBPNG=ON
-DUSE_SHARED_LIBLOADPNG=OFF
-DUSE_SHARED_TINYXML=ON
-DENABLE_UPDATER=OFF
-DUSE_SHARED_FREETYPE=ON
-DFREETYPE_INCLUDE_DIR=/usr/include/freetype2
-DCMAKE_INSTALL_PREFIX:STRING=/usr ..
make libresprite

LibreSprite and System version

• LibreSprite (version number or commit hash): 0a01bb9
• System (Win/OSX/Linux, version, distribution): Linux, Arch

[ 34%] Building CXX object src/she/CMakeFiles/she.dir/alleg4/alleg_display.cpp.o
In file included from /usr/include/freetype2/freetype/freetype.h:33,
from /usr/include/freetype2/freetype/ftglyph.h:37,
from /home/godofgrunts/temp/LibreSprite/src/./ft/freetype_headers.h:12,
from /home/godofgrunts/temp/LibreSprite/src/./ft/face.h:13,
from /home/godofgrunts/temp/LibreSprite/src/./she/common/freetype_font.h:11,
from /home/godofgrunts/temp/LibreSprite/src/./she/common/generic_surface.h:12,
from /home/godofgrunts/temp/LibreSprite/src/./she/alleg4/alleg_surface.h:14,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:18:
/usr/include/freetype2/freetype/config/ftconfig.h:63: warning: "HAVE_STDINT_H" redefined
#define HAVE_STDINT_H 1

In file included from /home/godofgrunts/temp/LibreSprite/src/./base/base.h:11,
from /home/godofgrunts/temp/LibreSprite/src/./config.h:40,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:8:
/home/godofgrunts/temp/LibreSprite/build/src/base/base/config.h:11: note: this is the location of the previous definition
#define HAVE_STDINT_H

In file included from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/base.h:41,
from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro.h:25,
from /home/godofgrunts/temp/LibreSprite/src/./she/alleg4/alleg_surface.h:11,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:18:
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/alcompat.h:44:22: error: conflicting declaration of C function ‘fixed fadd(fixed, fixed)’
AL_ALIAS(fixed fadd(fixed x, fixed y), fixadd(x, y))
^~~~
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/internal/alconfig.h:164:49: note: in definition of macro ‘AL_ALIAS’
static attribute((unused)) inline DECL
^~~~
In file included from /usr/include/c++/8.2.0/cmath:45,
from /usr/include/c++/8.2.0/math.h:36,
from /home/godofgrunts/temp/LibreSprite/src/./base/base.h:13,
from /home/godofgrunts/temp/LibreSprite/src/./config.h:40,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:8:
/usr/include/bits/mathcalls-narrow.h:24:20: note: previous declaration ‘float fadd(double, double)’
__MATHCALL_NARROW (__MATHCALL_NAME (add), __MATHCALL_REDIR_NAME (add), 2);
^~~~~~~~~~~~~~~
In file included from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/base.h:41,
from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro.h:25,
from /home/godofgrunts/temp/LibreSprite/src/./she/alleg4/alleg_surface.h:11,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:18:
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/alcompat.h:45:22: error: conflicting declaration of C function ‘fixed fsub(fixed, fixed)’
AL_ALIAS(fixed fsub(fixed x, fixed y), fixsub(x, y))
^~~~
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/internal/alconfig.h:164:49: note: in definition of macro ‘AL_ALIAS’
static attribute((unused)) inline DECL
^~~~
In file included from /usr/include/c++/8.2.0/cmath:45,
from /usr/include/c++/8.2.0/math.h:36,
from /home/godofgrunts/temp/LibreSprite/src/./base/base.h:13,
from /home/godofgrunts/temp/LibreSprite/src/./config.h:40,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:8:
/usr/include/bits/mathcalls-narrow.h:33:20: note: previous declaration ‘float fsub(double, double)’
__MATHCALL_NARROW (__MATHCALL_NAME (sub), __MATHCALL_REDIR_NAME (sub), 2);
^~~~~~~~~~~~~~~
In file included from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/base.h:41,
from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro.h:25,
from /home/godofgrunts/temp/LibreSprite/src/./she/alleg4/alleg_surface.h:11,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:18:
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/alcompat.h:46:22: error: conflicting declaration of C function ‘fixed fmul(fixed, fixed)’
AL_ALIAS(fixed fmul(fixed x, fixed y), fixmul(x, y))
^~~~
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/internal/alconfig.h:164:49: note: in definition of macro ‘AL_ALIAS’
static attribute((unused)) inline DECL
^~~~
In file included from /usr/include/c++/8.2.0/cmath:45,
from /usr/include/c++/8.2.0/math.h:36,
from /home/godofgrunts/temp/LibreSprite/src/./base/base.h:13,
from /home/godofgrunts/temp/LibreSprite/src/./config.h:40,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:8:
/usr/include/bits/mathcalls-narrow.h:30:20: note: previous declaration ‘float fmul(double, double)’
__MATHCALL_NARROW (__MATHCALL_NAME (mul), __MATHCALL_REDIR_NAME (mul), 2);
^~~~~~~~~~~~~~~
In file included from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/base.h:41,
from /home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro.h:25,
from /home/godofgrunts/temp/LibreSprite/src/./she/alleg4/alleg_surface.h:11,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:18:
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/alcompat.h:47:22: error: conflicting declaration of C function ‘fixed fdiv(fixed, fixed)’
AL_ALIAS(fixed fdiv(fixed x, fixed y), fixdiv(x, y))
^~~~
/home/godofgrunts/temp/LibreSprite/src/allegro/include/allegro/internal/alconfig.h:164:49: note: in definition of macro ‘AL_ALIAS’
static attribute((unused)) inline DECL
^~~~
In file included from /usr/include/c++/8.2.0/cmath:45,
from /usr/include/c++/8.2.0/math.h:36,
from /home/godofgrunts/temp/LibreSprite/src/./base/base.h:13,
from /home/godofgrunts/temp/LibreSprite/src/./config.h:40,
from /home/godofgrunts/temp/LibreSprite/src/she/alleg4/alleg_display.cpp:8:
/usr/include/bits/mathcalls-narrow.h:27:20: note: previous declaration ‘float fdiv(double, double)’
__MATHCALL_NARROW (__MATHCALL_NAME (div), __MATHCALL_REDIR_NAME (div), 2);
^~~~~~~~~~~~~~~
make[3]: *** [src/she/CMakeFiles/she.dir/build.make:76: src/she/CMakeFiles/she.dir/alleg4/alleg_display.cpp.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:1195: src/she/CMakeFiles/she.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:176: src/CMakeFiles/libresprite.dir/rule] Error 2
make: *** [Makefile:175: libresprite] Error 2

im rather new to this, so i might just being missing something and don't know how to deal with it. when i try to compile. cmake gives me an error that C compiler and CXX compiler identification is unknown.

LibreSprite, last commit f9002f2

• System , Windows 10, 64 bit

• https://github.com/AppImage/AppImageKit
• https://en.wikipedia.org/wiki/AppImage

Cast @probonopd

RELATED

• #17

When i download de installers show me a messenge telling me that the file was not secure and should not be dowload, also when and tried to install it on windows the S.O. show me another messege telling me that install that program could be dangerous. I think that kind of messenges hurts the people trust and take us credibility. P.S the anti-virus was desable all the time

When running aseprite-gpl after compilation, on the front page there is a notification of a new version. Since this project is separate from the original Aseprite, it should not notify you with updates, in my opinion.

Aseprite and System version

• Aseprite version: dev
• System: Arch Linux

Pixelated font and texture looks good but it is really stressful to the eyes. Why not have a option to choose between pixelated and not pixelated editor?

See #8 for the issue where you can propose new names for the project.

This issue is meant to discuss the technical stuff that will have to be done to properly rebrand the project. I'll make this a list of checkboxes, feel free to add new stuff in comments and I can edit the OP.

Things to do:

• Rename the repo (and potentially the GitHub organisation)
• Edit the README.md (and all other doc text files) to remove direct redirections to the @aseprite repo (reporting issues, etc.)
  • Add a section about the fork's purpose/history and link to the original project for attribution (and fair-play :))
• Rename (and edit) files containing aseprite in their name, e.g. desktop/aseprite.desktop. [partly done]
• Adjust license headers to keep credit for the original author, and add name and credit for the new project for 2016 onward.
• If wanted, ask GH staff to decouple the new repo from the original one (so that it's not always marked as "forked from aseprite/aseprite", which makes it a kind of sub-repo in GitHub)
• Likely other things, did not look to deep yet.

What we should avoid doing:

• Renaming stuff (methods, variables) in the source code that would contain aseprite. In a first time it would likely not add any value, and just make it more difficult to compare the two projects if the original one ever decided to go back to a GPLv2-compatible license.
• Removing credits (that's not something to avoid, that's a no go!)

All in the title

When compiling with -DUSE_SHARED_PIXMAN=TRUE, the build fails due to some code depending on pixman's internal code.

In file included from ../src/doc/blend_funcs.cpp:23:0:
../src/./doc/blend_internals.h:11:10: fatal error: ../../third_party/pixman/pixman/pixman-combine32.h: No such file or directory
 #include "../../third_party/pixman/pixman/pixman-combine32.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since pixman source code is required even when using a shared library, maybe it should be moved to src? At the very least, the documentation should be updated to clearly state this.

LibreSprite version: 0a01bb9
OS: Fedora 27

I shared this with a community I'm a member of, and they brought up concerns that it was showing as a virus by some online resources.

I did some checking with the windows installer and am showing similar hits, although low on the total:

Virus Total: https://www.virustotal.com/gui/file/0b97559ddb9979f67836941b52caadafba37c22b639aa8bc0643cd17916a5324/detection

Hybrid Analysis Results: https://www.hybrid-analysis.com/sample/0b97559ddb9979f67836941b52caadafba37c22b639aa8bc0643cd17916a5324

and from their VM test:
https://www.hybrid-analysis.com/sample/0b97559ddb9979f67836941b52caadafba37c22b639aa8bc0643cd17916a5324/5f57857e07ff291774537e6f

Looks like it could be related to Inno Setup, or something else.

The original Aseprite never cared about doing this because the author wanted you to buy their pre-built binaries, but for those of us that want to build from source, it's currently not easy. The release tarballs available on GitHub are simply generated from git tags. Since the repository has many submodules, the tarball is missing all of that code. So, the user must do a recursive clone of the repo and checkout the tag they want to build from. It would be great if this free software friendly fork could upload complete source releases that users can just unpack and build.

A trail of window forms while moving window. It does not happens in main window but only on secondary window. like while moving "New File" and "Open File"
picture

When i try to move child window, like window we get after press help > about button stranges recurring black outlines are draw and the moving of window is slow or slow down.
And I tried to re-install and the same result is samething

LibreSprite : v1.0-dev
System : Linux Mint 19.3

Describe your bug report or feature request here

After compiling libresprite and running it I get a segmentation after the window quickly pops up telling of a segmentation fault.

LibreSprite 1.1.7

1.1.7
KISS Linux(musl libc)

Attention MacOS users. As of right now, LibreSprite can't be compiled on a Mac. I think the trouble is at compiling skia. I do not have a Mac, so I am unable to try it for myself. If you have a Mac, please try to compile LibreSprite. The instructions are no longer on GitHub, but can be found right here. If you get it working, please create an issue on GitHub describing your workaround. I know GitHub issues isn't an ideal place for this, but I would like it to be here. A MacOS build is critical for our first release. The date of the release is heavily dependent on the MacOS build.

The hamburger button on the top right at the mobile version is dead on my Firefox

https://libresprite.github.io/

I'm not sure that this fork isn't too new. Commit 7750982 appears to be the start of the change in the original Aseprite's direction. Shouldn't this repo be rolled back to that point before continuing? I'm not positive that the following commit d7d5766 doesn't introduce potential GPL incompatibilities.

title says it all

When attempting to build the master branch. I get the error " Target missing executable" "libresprite.exe does not have an executable configured"

Is anyone else getting this bug?

For reference, the previous stable build (1.1.7) works fine and I can compile it with no issues.
I am using Visual Studio Community Edition.

LibreSprite and System version

• LibreSprite: (Current Master)
  0a01bb9

• System: Windows 10

App installs fine and is also working from "C:\Program Files (x86)\librespritestuff". It also shows at "Control Panel\Programs\Programs and Features" but application icon is not showing in start menu.

Describe your bug report or feature request here

when i run the libreSprite program downloaded from flathub my cpu reaches 50% of usage, there is any way to solve it?

LibreSprite and System version

• LibreSprite (current 2020/03/10):
• System (Zorin OS linux debian/ubuntu based):

Hi guys!
So I’ve just stumbled upon this repo, and I looked at #1. It looks like some of the contributors were up for making a website, but nothing left had been done. I’m wondering what the plan for the website is.

It’d really help put this project out there (LibreSprite is a noble cause!), and as said in #1, it’ll make this repo seem like more of a serious project.
Also, it’ll make it much easier for people to get their hands on the software.

LibreSprite still uses the .ase format from the original project; this can create problems, as those files might be incompatible with our version.

I propose changing the project and specification to use .lse; a quick Google search shows that it's not linked to a popular program, so it should be safe to use.

We could also make our program compatible with original .ase files, but we have to investigate if we have the permission to do so.

As mentioned in #65 , we should create some proper documentation. I'll try to set this up, and will create the basis for it. I would think MediaWiki is ideal for this project, because it is open-source, and has that classic Wikipedia look and feel.

2., there are a lot of issues that should be closed. Issue 40 should be closed, as it doesn't have a purpose anymore. LibreSprite should make an effort to close stale and solved issues.

I'm running ubuntu 18.04 and would like to use this, if anyone has a deb file that would be appreciated. :)

Well, i was looking for the dark theme and when i was on the "help" button, just the readme and about option was working , i think is a simple issue, but an important feature

• LibreSprite: v1.0-Dev
• System: PopOs 20.04

TODO

• https://github.com/aseprite-gpl/aseprite → http://github.com/LibreSprite/LibreSprite

RELATED

• #20

REFERENCE

• #8
• #10

Since https://github.com/aseprite/aseprite went proprietary on Aug 26th, 2016 (aseprite/aseprite@5ecc356), this fork and corresponding GitHub organization were created to preserve the last GPLv2 version of the code.

Our reasons for doing so are multiple and likely different for all fork initiators, but a strong belief in free software is definitely to name, and as the GPLv2 license allows us to, we want to safeguard this nice open source piece of software.

Development intent

We now have to discuss our plans for the future. There are several possibilities:

• Continue the development in parallel to the proprietary upstream version (i.e. effectively become a competitive upstream)
• Do minimal maintenance of the project, merging good PRs and doing some simple bug fixes here and there but no strong development
• Keep the repository as a more or less read-only archive of the code as it was before going proprietary, so that other interested parties can build it for themselves, for distribution, or fork it to continue development as a new upstream

Providing binaries

In parallel to this, we have the possibility to set up a small website where we would provide binaries for Linux, Mac OSX and Windows of the latest stable release and likely of the current master HEAD. These would be useful for people who prefer to use the libre version over the proprietary one but can't/don't want to build from source.

We can also choose not to do so, this is up for discussion. Of course, the GPLv2 allows us to distribute such binaries.

Branding

Depending on the decisions for the above points, we might end up being disliked by the original author and developer of the now proprietary version. I see no trademark policy so far, but it might come to a point where we need to rebrand this fork to avoid confusion and unnecessary friction.

If a new name is needed, it should be discussed in a new issue, please don't post alternative name suggestions on this topic.

Regardless of a potential name change, if we decide to further develop or at least maintain this fork, the various links and statements in the documentation files will have to be changed, to avoid having e.g. people reporting our own bugs to the proprietary upstream repo.

I already removed the EULA of the original developer, as it applied to his repository and not to the GPLv2 code itself. We obviously don't want to keep its terms which are unnecessary for a GPLv2 project.

Hello, does someone know where the source code for the windows installer can be found?

I noticed that the installer was generated with installsimple, a commercial product.
Would be be possible to use something freely available instead?

Some possible options are:

• Innosetup: https://jrsoftware.org/isinfo.php
• NSIS: https://nsis.sourceforge.io/Download
• WiX Toolset: https://wixtoolset.org/

LibreSprite and System version

• LibreSprite (latest):
• System (Windows):

This could be useful for linux to allow allegro5 to be used with the allegro4 code https://github.com/NewCreature/Allegro-Legacy

The gitter chat button in the readme is pointing to the now no longer used aseprite gitter chat.
It should be either removed or migrated to a separate chat service specific for this project.

Shortcuts like ctrl z and others don't seem to work. I tried changing languages and that still didn't work.
Edit: I am on windows 10 by the way.

I am currently working at the Spanish UI. I already have my LibreSprite compilation in Spanish but I was thinking of putting a welcome screen where the users can choose the language or put the option to change the language in preferences but for that I need to modify the base code and it will take some time.

What do you think, welcome screen or option in preferences?

What are the minimum system requirements to run libresprite smoothly?

• Operating System
• Processor
• RAM
• OpenGL?
• vram?

Describe your bug report or feature request here
Use Dark Theme breaks the program, even after reinstalling

LibreSprite and System version

• LibreSprite Current stable version:
• System Windows 7 and windows 10:

The button for travis builds in the readme is still pointing at aseprite/aseprite.
This project should setup our its own travis instance and update the button.

I've created a small web page at https://LibreSprite.github.io that has a button for a windows installer. I'm not very good at making cool-looking websites, so I've just created a repo for the website, and people can improve it.

Hello, I am Mint Studios.
I enjoy open source projects like Godot. I would like to become the maintainer of this project.

My first act as a maintainer would be making a proper website, and make compiling this much, much easier. Adding new features is not in my plan. Yet.

I hope this happens.

@Calinou
@akien-mga

Seems to me, y'all were the last people to maintain this project.

The windows installer create a folder named "Librespritestuff", thats not very proffesional, it should be renamed just "LibreSprite"