LodePaint: Painting Program

aardwolf · 2010-03-06 15:13:13

LodePaint is an open source painting program similar to (Kolour)Paint but with more advanced features, more filters, soft brushes, alpha channel support, some HDR image support, etc...

The program is aimed mostly at pixel artists, icons, texture editing, "programmer's art", etc...
It can be downloaded here: https://sourceforge.net/projects/lodepaint/files/

Just unzip & run. It requires SDL, and hardware accelerated OpenGL to run.

Please try it out!

Last edited by aardwolf (2010-03-06 15:20:01)

drcouzelis · 2010-03-06 16:01:38

It looks beautiful. Did you make the entire GUI with SDL?

Also, I'm curious, why does it require OpenGL?

aardwolf · 2010-03-06 16:03:48

drcouzelis wrote:

It looks beautiful. Did you make the entire GUI with SDL?
Also, I'm curious, why does it require OpenGL?

The entire GUI is made with SDL + OpenGL. That answers both the questions I think

OpenGL is just very nice to work with for graphics, even two dimensional graphics. The GUI was originally designed for computer games.

Gen2ly · 2010-03-06 19:20:47

Huh, neat. One thing that Linux is in need of is a good pixel/icon creation program.

aardwolf · 2010-03-07 08:46:12

Gen2ly wrote:

Huh, neat. One thing that Linux is in need of is a good pixel/icon creation program.

Well that's the intention of this program! So if there's anything you find missing or see improved, please let me know

Stefan Husmann · 2010-03-07 11:44:08

Is the source code available? Or at least, is the a x86_64-version?

aardwolf · 2010-03-07 11:55:17

Yes, the source code is available on sourceforge under SVN (https://lodepaint.svn.sourceforge.net/svnroot/lodepaint ).

Compilation instructions are included in the "doc" folder. If you try compiling it for 64-bit, it'd be interesting to know if it worked.

Last edited by aardwolf (2010-03-07 11:56:05)

panuh · 2010-03-07 12:04:54

Excuse the non-topic, but what town is this?

It kind of reminds me to much of Heidelberg in Germany but it's definitely not.
It collides in my head! ^^

aardwolf · 2010-03-07 12:06:34

panuh wrote:

Excuse the non-topic, but what town is this?
It kind of reminds me to much of Heidelberg in Germany but it's definitely not.
It collides in my head! ^^

It's Prague, taken from the roof of a cathedral iirc

panuh · 2010-03-07 12:12:47

Haha! Yeah! What a shame

I managed to find it on TinEye shortly before reading your post (which I had to find first because I didn't remeber its name)

Again, this shows a small-town guy's ignorance Thanks for the info.

Stefan Husmann · 2010-03-07 12:36:43

If you try compiling it for 64-bit, it'd be interesting to know if it worked.

It did not. Using this PKGBUILD

# Maintainer: Stefan Husmann <stefan-husmann@t-online.de>
pkgname=lodepaint-svn
pkgver=7
pkgrel=1 
pkgdesc="Painting program with full SDL+OpenGL GUI."
url="http://sourceforge.net/projects/lodepaint/"
arch=('i686' 'x86_64')
license=('GPL3')
depends=('sdl')
source=()
md5sums=()
_svntrunk=https://lodepaint.svn.sourceforge.net/svnroot/lodepaint
_svnmod=lodepaint
build() {
 cd "$srcdir"
LANG=C
  if [ -d $_svnmod/.svn ]; then
    (cd $_svnmod && svn up -r $pkgver)
  else
    svn co $_svntrunk --config-dir ./ -r $pkgver $_svnmod
  fi

  msg "SVN checkout done or server timeout"
  msg "Starting make..."

  rm -rf "$srcdir/$_svnmod-build"
  cp -r "$srcdir/$_svnmod" "$srcdir/$_svnmod-build"
  cd "$srcdir/$_svnmod-build/trunk"

  #
  # BUILD
  #
  g++ src/*.cpp src/lpi/*.cpp -o lodepaint -lSDL -lGL -W -Wall \
    -Wextra -pedantic -ansi -O2
  install -Dm755 lodepaint $pkgdir/usr/bin/lodepaint
}

I get

==> Determining latest svn revision...
  -> Version found: 7
==> Making package: lodepaint-svn 7-1 x86_64 (So 7. Mär 13:25:31 CET 2010)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
==> Extracting Sources...
==> Removing existing pkg/ directory...
==> Entering fakeroot environment...
==> Starting build()...
At revision 7.
==> SVN checkout done or server timeout
==> Starting make...
src/paint_filter_plugin.cpp: In constructor 'FilterPlugin::FilterPlugin(const std::string&, GlobalToolSettings&, const lpi::gui::IGUIDrawer&)':
src/paint_filter_plugin.cpp:52: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:69: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:82: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:83: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:85: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:86: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:87: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:88: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:96: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:97: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:98: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:99: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:100: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:101: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:102: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:103: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:104: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:105: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:106: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:107: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp:108: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_filter_plugin.cpp: In constructor 'FilterPlugin::FilterPlugin(const std::string&, GlobalToolSettings&, const lpi::gui::IGUIDrawer&)':
src/paint_filter_plugin.cpp:52: warning: dereferencing pointer 'p_getLodePaintPluginType.174' does break strict-aliasing rules
src/paint_filter_plugin.cpp:52: note: initialized from here
src/paint_filter_plugin.cpp: In constructor 'FilterPlugin::FilterPlugin(const std::string&, GlobalToolSettings&, const lpi::gui::IGUIDrawer&)':
src/paint_filter_plugin.cpp:52: warning: dereferencing pointer 'p_getLodePaintPluginType.174' does break strict-aliasing rules
src/paint_filter_plugin.cpp:52: note: initialized from here
src/paint_imageformats.cpp: In constructor 'ImageFormatPlugin::ImageFormatPlugin(const std::string&)':
src/paint_imageformats.cpp:403: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:422: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:435: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:442: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:449: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:456: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:463: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:464: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:465: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:466: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp:468: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/paint_imageformats.cpp: In constructor 'ImageFormatPlugin::ImageFormatPlugin(const std::string&)':
src/paint_imageformats.cpp:403: warning: dereferencing pointer 'p_getLodePaintPluginType.203' does break strict-aliasing rules
src/paint_imageformats.cpp:403: note: initialized from here
src/paint_imageformats.cpp: In constructor 'ImageFormatPlugin::ImageFormatPlugin(const std::string&)':
src/paint_imageformats.cpp:403: warning: dereferencing pointer 'p_getLodePaintPluginType.203' does break strict-aliasing rules
src/paint_imageformats.cpp:403: note: initialized from here
src/lpi/lpi_imageformats.cpp: In function 'bool lpi::decodeImageFile(std::string&, std::vector<unsigned char, std::allocator<unsigned char> >&, int&, int&, const unsigned char*, size_t, lpi::ImageFormat)':
src/lpi/lpi_imageformats.cpp:795: error: no matching function for call to 'CBitmap::GetBits(unsigned char*, size_t&, int)'
src/lpi/lpi_imageformats.cpp:593: note: candidates are: bool CBitmap::GetBits(void*, unsigned int&)
src/lpi/lpi_imageformats.cpp:607: note:                 void* CBitmap::GetBits()
src/lpi/lpi_imageformats.cpp:614: note:                 bool CBitmap::GetBits(void*, unsigned int&, unsigned int)
src/lpi/stb_image.cpp: In function 'stbi_uc* stbi_tga_load_from_memory(const stbi_uc*, int, int*, int*, int*, int)':
src/lpi/stb_image.cpp:2866: warning: 'trans_data$3' may be used uninitialized in this function
src/lpi/stb_image.cpp:2866: note: 'trans_data$3' was declared here
src/lpi/stb_image.cpp:2866: warning: 'trans_data$2' may be used uninitialized in this function
src/lpi/stb_image.cpp:2866: note: 'trans_data$2' was declared here
src/lpi/stb_image.cpp:2866: warning: 'trans_data$1' may be used uninitialized in this function
src/lpi/stb_image.cpp:2866: note: 'trans_data$1' was declared here
src/lpi/stb_image.cpp:2866: warning: 'trans_data$0' may be used uninitialized in this function
src/lpi/stb_image.cpp:2866: note: 'trans_data$0' was declared here
install: cannot stat `lodepaint': No such file or directory
==> ERROR: Build Failed.
    Aborting...

Process makepkg exited abnormally with code 2

the relevant error seems to be in

src/lpi/lpi_imageformats.cpp:795:error: no matching function for call to 'CBitmap::GetBits(unsigned char*, size_t&, int)'
src/lpi/lpi_imageformats.cpp:593: note: candidates are: bool CBitmap::GetBits(void*, unsigned int&)
src/lpi/lpi_imageformats.cpp:607: note:                 void* CBitmap::GetBits()
src/lpi/lpi_imageformats.cpp:614: note:                 bool CBitmap::GetBits(void*, unsigned int&, unsigned int)

Last edited by Stefan Husmann (2010-03-07 12:39:07)

aardwolf · 2010-03-07 13:24:54

Ok, I can see why that fails on 64-bit and not on 32-bit

I committed an updated lpi_imageformats.cpp to the svn that hopefully fixes it.

n0dix · 2010-03-07 14:15:13

Great work!!!,
Thanks for the program.

Stefan Husmann · 2010-03-07 15:00:44

Revision 8 builds now under x86_64. But when I start it,

. [haawda@frege ~]$ lodepaint 
PaintDebug Info: Starting LodePaint
PaintDebug Info: Version: Mar  7 2010 15:41:29
PaintDebug Info: OS: Linux
PaintDebug Info: Loading persistent data
PaintDebug Info: Persistent data loaded
PaintDebug Info: Creating screen width: 1024 height: 700 fullscreen: 0 resizable: 1
info: initing SDL
info: SDL inited
info: initing screen
info: screen inited
info: OpenGL Version: 2.1 Mesa 7.7
info: OpenGL Renderer: Software Rasterizer
info: OpenGL Vendor: Mesa Project
info: initing GL
info: GL inited
PaintDebug Info: Screen created. Creating gui drawer
PaintDebug Info: Gui drawer created. Creating main container
PaintDebug Info: Main container created
Files buttons32.png and buttons16.png not found. These are required to start the program

Wher in the filesystem does the program expect the button files to stand?

aardwolf · 2010-03-07 15:12:00

Stefan Husmann wrote:

Revision 8 builds now under x86_64. But when I start it,
Wher in the filesystem does the program expect the button files to stand?

In the same directory where the executable is. When the executable is ran, it reads its own path from the command line argument, so no matter where the executable is it always uses its own directory.

I see it says "Software Rasterizer" in the log, that might mean that the program will run too slow unfortunately

The program doesn't require that much from the video card, it works in a geforce 3 for example, but hardware acceleration is needed, without it I heard it goes slow even on the fastest video cards. Well, it's worth a try...

Last edited by aardwolf (2010-03-07 15:19:21)

Stefan Husmann · 2010-03-07 16:44:36

I see a problem which makes losepaint be unpackagable now. The two button files are needed at runtime and need to be in the same directory in which lodepaint was built. But that built directory will never be the install directory, usually /usr/bin. So the PKGBUILD above does not work and cannot work.

On the other hand, /usr/bin should only include archtecture dependent files, no pngs or other ressource files.

The program itself runs fine, but as you stated, rather slowly.

To make it ready for being packaged, it would be needed, that the build system distiguishes between build-time and run-time, and that at build-time a directory can be specified, where the ressorces are searched.

aardwolf · 2010-03-07 17:34:11

I think I'll study a bit how Archlinux packages work then! Because the above leaves me with questions, such as, how to communicate the directory with PNG's to the executable, and how to do this in a platform-independent way. Plus the program now also looks for a directory called "Plugins" in its own executable directory, and scans for dynamic libraries in there. That would also need to happen somewhere else then...

The reason for the current system (with the PNGs next to the executable) is because it can be easily unzipped & ran.

Stefan Husmann · 2010-03-07 18:25:58

This is not arch Linux specific. You will have to deal with such prroblems wherever you want to have a package. Normally, e.g. in rprojects that use the gnu autotools chain, you can run a configure script with the option --prefix. If the option is not given, the value defaults to /usr/local. There are several other variables that can (and sometimes must, if you want to package) be handled that way.

Another important step is the install step. Here often a new variable DESTDIR comes into the game.

Maybe you should take a look at the file /usr/share/pacman/PKGBUILD.proto . It is a "hello world" for packagers.

Arch Linux

#1 2010-03-06 15:13:13

LodePaint: Painting Program

#2 2010-03-06 16:01:38

Re: LodePaint: Painting Program

#3 2010-03-06 16:03:48

Re: LodePaint: Painting Program

#4 2010-03-06 19:20:47

Re: LodePaint: Painting Program

#5 2010-03-07 08:46:12

Re: LodePaint: Painting Program

#6 2010-03-07 11:44:08

Re: LodePaint: Painting Program

#7 2010-03-07 11:55:17

Re: LodePaint: Painting Program

#8 2010-03-07 12:04:54

Re: LodePaint: Painting Program

#9 2010-03-07 12:06:34

Re: LodePaint: Painting Program

#10 2010-03-07 12:12:47

Re: LodePaint: Painting Program

#11 2010-03-07 12:36:43

Re: LodePaint: Painting Program

#12 2010-03-07 13:24:54

Re: LodePaint: Painting Program

#13 2010-03-07 14:15:13

Re: LodePaint: Painting Program

#14 2010-03-07 15:00:44

Re: LodePaint: Painting Program

#15 2010-03-07 15:12:00

Re: LodePaint: Painting Program

#16 2010-03-07 16:44:36

Re: LodePaint: Painting Program

#17 2010-03-07 17:34:11

Re: LodePaint: Painting Program

#18 2010-03-07 18:25:58

Re: LodePaint: Painting Program

Board footer