AuthorTopic: Hackable pixel editors?  (Read 10642 times)

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Hackable pixel editors?

on: July 28, 2017, 04:51:56 pm
Are there editors that have modern-ish source code you could in theory hack? There is of course Gimp, but when I was looking at the build procedure I didn't even try. I quit right there and then. Another one was Grafx2, but it has a bit too old school C source code and it's probably too hard wired to 256 colors I guess. It would be really cool to have C/C++ project source code that doesn't require too many tricks to build. The way I see it most editors have problems in UI which could be fixed. I have my own project as well, but I've hit stone wall trying to work on the gui parts.

Offline surt

  • 0011
  • **
  • Posts: 570
  • Karma: +0/-0
  • Meat by-product
    • not_surt
    • http://pixeljoint.com/p/2254.htm
    • View Profile
    • Uninhabitant

Re: Hackable pixel editors?

Reply #1 on: July 28, 2017, 08:28:06 pm
Aseprite isn't open source any more but the source is still available for personal builds. https://github.com/aseprite/aseprite

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #2 on: July 29, 2017, 09:51:09 am
Maybe it's best to stick to my own project. It has problems like writing an entire GUI on top of SDL2, but at least the source code is better than anything I've ever seen. I was browsing aseprite's source code and randomly watching this guy (I presume the programmer is a male person) passing a pointer to constructor and then deleting it in destructor with some kind of condition. No, don't do that. Just go back to C, C++ is not for you. I'm sometimes wondering am I really that good as programmer? Why can't others be at least near my level?

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #3 on: July 29, 2017, 03:14:18 pm
Finding bad code should not stop you from helping open-source projects. I'm sorry you can't find the perfect project to work with (fun AND similar to your style AND popular), but you never know which part of your experience is going to help. SDL is very common, for example with game remakes (OpenXCOM), and there is a big field of image edition (filters like 2xSai, procedural image generation...)
 
IMO it's not very fun to build and maintain the GUI part of an editor, since it quickly becomes a time sink, and every little improvement for the user adds complexity. At least, it compiles and runs on many different OSes. On the other hand, existing GUI toolkits are ... peculiar. I mean, they do things their way, and they have their own style, there is no choice but adapt your code to it.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #4 on: July 31, 2017, 10:28:22 am
Maybe I could find out how difficult it is to compile Gimp. It could be fun to try at least? Gimp doesn't need a lot of fixes to become good (and useful for pixel art), so it could be worth it. It's not like it's impossible to build it, right?

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #5 on: August 02, 2017, 06:28:58 am
Gimp has two sets of instructions on how to build it (for Windows) and both of them are somewhat vague and bad in explaining what and why you need to do something. Gimp is also possibly designed only for 'make' and never supposed to work in any kind of IDE. I don't know if it's really worth the trouble to go through all that installing for stuff it needs, but since there are Windows builds it must be possible somehow. The source code itself is a sad example of old school C with tons of quirky macros, user defined data types etc. I think it's 700K lines for only a pixel art program. Makes you wonder how it's even possible to make something that bloated.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Hackable pixel editors?

Reply #6 on: August 02, 2017, 02:39:37 pm
Quote
Gimp is also possibly designed only for 'make' and never supposed to work in any kind of IDE.
Well, there is not a project file or anything. That kind of thinking is pretty Windows-centric, although some Linux apps facilitate it (KDevelop).

People are gradually moving away from make/autotools to things like meson, scons, etc.., but it has been the standard for a long time on Linux, and GIMP still uses it.

The reason I mention Linux is because opensource software is, in the overwhelming majority, developed on Linux. That's where the best development infrastructure is -> most volunteer devs do not want to bother developing for Windows.

(not coincidentally, building GIMP for Linux is easy. Make sure GEGL and BABL installs are up to date, then run the standard './autogen.sh;./configure;make;sudo make install')

.. why do you think GIMP is a pixel art program, though? It's more like Photoshop -- an image editor that you *can* use to do pixeling.
It does make me wonder if you are trolling... have you even used GIMP?
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #7 on: August 02, 2017, 04:16:53 pm
The reason I mention Linux is because opensource software is, in the overwhelming majority, developed on Linux. That's where the best development infrastructure is

Just by reading Gimp's source code doesn't tell me it's the best. More like worst. Gimp has never been a number one choice for most artists, because it's buggy (crashes randomly) and slow, and is missing some basic features. Those are characteristic to open source projects which most are linux based.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Hackable pixel editors?

Reply #8 on: August 02, 2017, 11:16:36 pm
Just by reading Gimp's source code doesn't tell me it's the best. More like worst. Gimp has never been a number one choice for most artists, because it's buggy (crashes randomly) and slow, and is missing some basic features. Those are characteristic to open source projects which most are linux based.
[/quote]
Yeah no lol.

As I said, Linux easily beats Windows for development infrastructure. That doesn't mean devs produce complete software (cause they are volunteers, and work on what is fun) - it means developing *is easy and reasonably fun*.  It means Windows-specific bugs hang around because no-one wants to bother with developing on Windows.
It also usually means that the Windows instructions are more complicated because the infrastructure has to be installed, rather than being there by default.

But you knew that right? Being a good programmer and all?
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #9 on: August 03, 2017, 07:13:52 am
It means Windows-specific bugs hang around because no-one wants to bother with developing on Windows.

There is no such thing as "Windows-specific" bugs. If you write a program that doesn't have bugs it works on any platform. The most common reason why some bugs appear on other platforms are subtle differences in memory layouts. They are still actual bugs in all platforms. From open source perspective it may look like Windows is not a preferable platform, but in reality majority of programs are developed on it. It's just commercial often, and freeware (closed source).

One of many things I noticed about Gimp's source code that it's using some kind of 'make' magic to link header files without actual directory structure. Something like #include "file.h" doesn't tell in which directory the header is. I don't know but it sounds like a bad practice. It also makes impossible (or hard) to set up a IDE project for source files.

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #10 on: August 03, 2017, 01:27:26 pm
Not sure where this thread is going, but I guess we may as well have some conversation.



I've dealt with plenty of platform specific bugs. If you rely on multi-platform frameworks that abstract from specific hosts, you can avoid a lot of this,
but even so there can still be problems. At any case, I guess that the overall number of bugs in the actual program core is usually higher, though.

Your program is of course embedded in a greater host system.
And each host may have different logic behaviour, in two ways:

Either it is obviously different in the interface.
So the part of your code that deals only with that host may have bugs that the software doesn't have on another host.

Or there are unspecified differences in the behaviour of the host implementation underneath.
An example I encountered were graphics driver problems I had on one system, that I didn't have on another.
The code was the same for both, and although valid in principle, needed additional provisions on the other.

I still have to deal with some such issues. Unfortunately, this time with the open source drivers on Linux.



There is a lot of things I like about open source projects, even though I don't see in it the greatest solution to every problem.



The Open Source movement is sometimes percieved as counter to proprietary industry.
But much more often it's complementary forces of something greater.

In reality, the industry has been very supportive to Open Source projects.
Many of the best projects have a good involvement with various companies.

Linux would not be where it is now, without it.
Some might say, it should be more, so they're bad.
But in many ways it's been plenty enough in my opinion.

The reason is simple: there is a need for Open Standards.
Open source software is part of the industry infrastructure.
At least with that code, you can bet it works pretty well.

However, agreement and compromise among many people is difficult to achieve,
and the need for that in a greater community project can also stifle development.
So it's not about what is the ultimate development pradigm.

Cooperative behaviour is not exclusive to just one side. And there are many ways of going about it.
At the same time, open source projects also have to compete for public interest, because it is voluntary.

And while this is great, that's also a challenge for Open Source development, as it is for anyone.
But it hits Open Source especially hard, because of its pronounced freedom, while limiting ownership.
This is not simply about greed. The question of ownership already starts with who directs the project which way.
And the often inconclusive answer to that has many difficult consequences.
The usual answer is forking development, so everyone can be happy in their own way.
But that too has caused many problems with splintered and weakened projects.

And that makes for weird contradictions. In theory, OS on average should be much more stable and save and service friendly, since anyone can look into it.
In practice it often isn't. Because not enough people are motivated to look into it, and there are big problems from a lack of accountable hierarchy structures.

So there have been several huge security holes that lasted more than a decade, and were a total embarrassment when discovered,
of a kind so bad you never saw happen on equivalent proprietary solutions in the first place.
Or terrible legacy constructs difficult to get rid of because of community politics.

The most important factors to good software is the combination of developer engagement with user feedback. That's the sort of Open that matters most.
And the idea of voluntary community service for the greater good is thousands of years old and was not invented by radical neckbeards on the internet.

Having said that, I'm glad these projects exist.

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #11 on: August 03, 2017, 02:44:44 pm
I also have lots of experience with porting programs by now, and I want to say, at some point you just don't care "who is wrong and who is right" : You just want to find one acceptable way to bridge the differences, and move on to the next incompatibility.

For example one OS which can compile Grafx2 only provides a very old version of GCC, and won't compile code where variable declarations occur after instructions. I weighted the arguments :
- Are there many users ? no
- Is it the only thing preventing Grafx2 from being perfectly usable on that OS ? yes
- Is it a big change for Grafx2 ? No, because the MS-DOS code was made on Borland C where it was mandatory anyway
- Is it difficult to maintain this restriction from now on ? No, because with compiler option "-Wdeclaration-after-statement", all coders on all platforms can see immediately if an incompatibility appears, and they can fix it immediately.

And thus there was another easy port, and a few users which can use Grafx2 now, instead of having to wait for a more modern GCC.

Offline Crow

  • 0011
  • **
  • Posts: 647
  • Karma: +0/-0
  • Technicanimal
    • View Profile

Re: Hackable pixel editors?

Reply #12 on: August 03, 2017, 03:42:28 pm
There is no such thing as "Windows-specific" bugs.

What? :huh:
Discord: Ennea#9999

Offline 0xDB

  • 0011
  • **
  • Posts: 873
  • Karma: +0/-0
  • Dennis inter-is.
    • dennisbusch_de
    • http://pixeljoint.com/p/1287.htm
    • 0xdb
    • View Profile
    • 0xDB

Re: Hackable pixel editors?

Reply #13 on: August 03, 2017, 03:56:24 pm
at some point you just don't care "who is wrong and who is right" : You just want to find one acceptable way to bridge the differences, and move on to the next incompatibility
That. Also, the situation is rarely that binary that one may say Alice is completely right and Bob is completely wrong. No two developers are the same, everyone comes with different experience levels and different points of view(which can change over time with experience) onto a field that is highly complex and extremely few(if any at all) should be able to claim to have a full understanding of everything involved and who would be right with that claim at the same time. I don't think anyone like that exists or will ever exist.

From my (own) experience (used to act like that myself 20 years ago) and also from countless discussions with other developers, the one who claims to know it all, know it all better even is usually the one with the least experience and thus has the most limited, narrow-minded point of view, sitting so high on top of Mt. Stupid (see graphic in spoiler below) that they are looking down upon a thick layer of clouds, unable to see the vastness and the complexity of the whole field below that layer.


Happy on their mountain, they think they know the one true way, the one ultimate eternal truth, smoking on the Dunning Kruger pipe everyday. It's a powerful, glorious feeling and it's perfectly understandable if one wants to linger and keep that grandiose feeling of superiority. But... it is an illusion.

They should keep digging, should learn more facts, keep exploring, descend from that mountain, seek other mountains, wade through the endless swamps and seas and forests and wastes, stay humble, practice, learn, never assume to know everything except maybe the "fact" that there is always more to learn and that there are a million different ways to do things and a million different tools to take along the paths.

This concludes the zenny part of this post.

the practical part:
For playing with stuff which originated in the GNU/Linux world under Windows, it helps to install a largely POSIX compliant subsystem like MSYS2 or Cygwin.
Regarding GIMP in particular, MSYS2 appears to be the way to go: https://wiki.gimp.org/wiki/Hacking:Building/Windows

Peace.

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #14 on: August 03, 2017, 04:58:01 pm
My point was rather: you can argue all day long about "Vendor B should have adopted Vendor A's choice, and made his product compatible", or the opposite. It will have no effect on how you adapt your software to work on both situations.

The worst case I have in mind is browsers and the CSS standards for not blurring zoomed images. The problem has started, like, 10 years ago, and ALL browsers are guilty of doing stupid stuff, starting standards, implementing in betas, arguing with other browsers , changing the standard, removing the first implementation without providing the new one, etc.
The result ? Users don't understand why a browser fixes the problem (when web designer takes into account new version of one browser) then breaks again (when browser update removes it) etc. Web designers run in circles every time a browser changes behavior, and in the end, 10 years later, website have to implement 8 frigging CSS fixes to allow sharp zoom, and it still can't work on every browser. The one who loses is the user.

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #15 on: August 03, 2017, 05:50:02 pm
The few moments you appreciate a monopoly setting standards. :p But yeah, I also think it's just part of life. Part of a coder's job. Dealing with different systems. So get used to it, painful as it may be. Many of these problems are pretty much unavoidable, no matter the paradigm, because that's just how humans do things. Unless someone makes it their business to bridge these differences for you with their middleware, engines, libraries, frameworks, etc. But even so, you could say Browser were meant to be like that with their standards, and see what chaos we got anyway. This is just what happens when you got all these people doing their thing. At some point you think about "how can we make something more interesting? How can we set ourselves apart from the others?" and there you go, doing things differently, "better". Kinda funny how this discussion meets with questions of Pixel Art definition. You could also describe that as a problem of standards. And just like artists seek to make something special, so do technicians. And then others have headaches how you can connect all that in one place.

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #16 on: August 03, 2017, 08:06:26 pm
But to specifically address a point I think you wanted to make most:
Even with the very best intentions of all parties for establishing a common standard,
there is a high likelyhood of things getting so messed up simply by mistake
and individual problems of execution, it may as well not be standard.

Plenty of examples, yeah. It again is a problem of scale, and we haven't fully figured this out yet.

Because this is not simply a problem of coding, altogether it's a fundemental problem of life.

We haven't really figured this shit out anywhere.

The attempt to create world wide standards that truly work without conflicts, may as well be the attempt to create god.

You shit flinging monkeys.


I don't even know what's worse. At least trying or not even bothering.

And is succeeding not our ultimate doom? The end of life's purpose.

To search. always search, struggle, with your own little life.

You have your peaceful standards when you meet your maker.

Just watch out that you didn't die because of boredom.

Since it's all just the same to you,

sitting there in silence,

until nothing's left,

to live for.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Hackable pixel editors?

Reply #17 on: August 04, 2017, 05:31:32 am
My point was rather: you can argue all day long about "Vendor B should have adopted Vendor A's choice, and made his product compatible", or the opposite. It will have no effect on how you adapt your software to work on both situations.
If this was intended to counter some of the points I made, then I want to be clear:

It's not that $FOO should have been standardized, though we live in hope ;)

It's not that open source software is necessarily better -- although the code is often less overtly horrifying IME.

It's just that a platform that is made by devs for devs, where you can look into everything and see how it works, is naturally dev-friendly, and becomes more so over time. (the beginning in Linux' case actually being in Unix times -- culture of sharing and the whole cluster of ideas comprising "Unix Philosophy")
;
and conversely, a culture of black-boxing (Windows being the worse offender, but Mac should also be mentioned) - gatekeeping what you can and cannot do / look at - , is hostile to developers.  No amount or quality of tools can compensate for this; it's a systemic problem resulting in the devs simply not using the marginal platform, and thus not noticing the bugs specific to it.

(I also have experienced personally that GIMP and Krita are both a lot more buggy on Windows, so I thought it was relevant that they aren't buggy on Linux.)


Quote
Happy on their mountain, they think they know the one true way, the one ultimate eternal truth, smoking on the Dunning Kruger pipe everyday.
I must admit, I was tempted to just link the wikipedia article on Dunning-Kruger after reading enough of the thread. You have certainly shown more patience than me, being willing to do the research to find whether it's MSYS or Cygwin rather than just implying that part of the toolchain is missing.
« Last Edit: August 04, 2017, 06:34:53 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #18 on: August 04, 2017, 06:35:49 am
The most important factors to good software is the combination of developer engagement with user feedback. That's the sort of Open that matters most.

I find this comment hilarious, because my experience is that open source developers are notoriously bad at listening people. A great example is Blender 3D and so called ngon case. I think we had to ask ngon feature for almost 10 years until the developers finally decided to add it, and after that everyone realized it was a good decision. The "reason" why it was opposed was just because it didn't "fit" to Blender's "style". Another example was when I asked Gimp's developers if they could add line drawing tool in Gimp, but they said no, because it's shift+pen to draw lines.

I think the reason why open source developers refuse to listen user feedback is that they don't have to. It's simple. In most cases they get their money anyway, from donations and other sources. It doesn't matter what they do, in fact some projects must be a dream job, because you don't have any kind of responsibility to provide working solutions and they still get enough money. And they can always throw that "hack it yourself" argument when everything else fails.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #19 on: August 04, 2017, 06:53:06 am
It's just that a platform that is made by devs for devs, where you can look into everything and see how it works, is naturally dev-friendly

You don't even know what you are talking about. Linux is based on old, outdated system that was and is a huge mess and that's why we have these bloated open source projects which are developed in incredibly slow pace and they still, after years of development, have long lists of bugs. Programming in linux is unnecessary difficult and unstable, which leads to a "solution" where everything is compiled frequently, because they can't make anything that has a minute of backward or forward compatibility.

Offline questseeker

  • 0010
  • *
  • Posts: 112
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #20 on: August 04, 2017, 08:16:18 am
Just by reading Gimp's source code doesn't tell me it's the best. More like worst. Gimp has never been a number one choice for most artists, because it's buggy (crashes randomly) and slow, and is missing some basic features. Those are characteristic to open source projects which most are linux based.
As I said, Linux easily beats Windows for development infrastructure. That doesn't mean devs produce complete software (cause they are volunteers, and work on what is fun) - it means developing *is easy and reasonably fun*.  It means Windows-specific bugs hang around because no-one wants to bother with developing on Windows.
It also usually means that the Windows instructions are more complicated because the infrastructure has to be installed, rather than being there by default.

You believe you disagree, but you are actually discussing two different things. Having better, or at least more supported, development tools on Linux, doesn't automatically mean that Linux software or open source software in general is good.
GIMP suffers from inadequate or dated technical choices (GTK+, complex plugin interface, complex and low bit depth image data structures, etc.) regardless of the platform and is as horribly difficult to compile and develop on Windows as other software of similar complexity.

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #21 on: August 04, 2017, 08:52:18 am
Krice, the GIMP is certainly too big to easily get into.
It's certainly too much of a general-purpose image editing suite to become a good pixel art editor.
It's well-known to be very Linux-centric, so don't imagine it can easily become Windows-friendly.
So can you please accept that it doesn't fit any of your needs ? Thank you.

Now, if your original question was guenuine, you can see if Evilpixie looks more like what you want to do.
It's around 6K lines of code. The stable editor is for indexed colors, but I see there's a rgba branch.
It can be the easiest way to get some experience with the Qt GUI, which has official Visual Studio package, apparently.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Hackable pixel editors?

Reply #22 on: August 04, 2017, 10:02:48 am
Quote
GIMP suffers from .. complex and low bit depth image data structures, etc.)
I'll just point out that GIMP doesn't suffer from low bit depth; that's an out-of-date critique. It's got pretty full hi-bit-depth support at this point. Roughly on parity with Krita, IIRC.

I agree that GTK+ is inadequate, particularly WRT the amount of macro incantations involved in defining objects (though properly that is a critique of GObject rather than GTK+, GTK+ is still heavily affected since it uses GObject). That said, there isn't a realistic alternative that I know of (since Qt is C++-based; it would be really asking for trouble to port the whole codebase across to C++. The idea that C++ is an adequate language choice is also contentious.)

As a plugin writer, I found registration to be the most needlessly complex area. I believe this is caused by the limitations of the PDB (no support for kwargs, etc); a project 'libpdb' was started to fix that, but it stalled IIRC.


« Last Edit: August 04, 2017, 10:13:07 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #23 on: August 04, 2017, 10:51:40 am
The thing I like to avoid most is when the issue boils down to either:

Someone arguing your're a bad person for not releasing your source. It's unethical. You should be ashamed.

And the other way around some critiques on Open Source projects come across way too ungrateful
and disparaging and blind towards the accomplishments and benefits they do bring to the table.


Besides that though, there are plenty of valid critiques on when proprietary products fail for various reasons.
As much as you can argue cases in which open source projects aren't quite where they need to be for serious consideration.

It can also be discussed if there may be even a causal relationship to these problems by virtue of the development paradigm.
Some might say, there is no downside to this or that. It's better on principle, it's just that people are not enlightened enough to take more advantage of it.

I believe that software development is a problem that exceeds pure technical consideration, because in the end the coders are just humans too.
So there is all kinds of questions about psychology, culture, motivations, economics, the situation, etc, that I think are important to factor in.
I think that there are at least associative relationships between these further factors and the development paradigms, that make the issue very complex.


As an example, I believe that a person's motivation is the most important key to the success.
We can then look at factors of motivation, and how powerful their psychological effect is.

Imagine that working on a snippet of code means, you are fully responsible for it, so far that you are held fully accountable for it. If the product succeeds because of your code, you may get a promotion and a higher income. If it fails because of you, you may lose your job, all your money. You may even go to jail in some cases. The company may sink, with all your colleages and friends. So you are sitting there, and maybe you give your code a couple more looks. Make a couple more test runs. Maybe listen more to customer complains. Maybe you even feel a greater sense of duty to do work that's not always fun and rewarding. The stakes are high, and your name is on it. So one person, from motivation to qualification, may put more value into a work than a hundred hobbyists.

Now I don't want to make the issue too simple. Because in a different scenario, that employee might be underpayed and frustrated with the job, feel like a cog with no say, etc, which also is bad for motivation. And in a project as a free hobby, you might be motivated because you just love to play with it and interacting with other creatives, and feel responsible for it as it grows on you.

Then we can argue about the difference of these as either a fully integrated development paradigm, or a mere fact of having companies release their sources. But there are such a huge amount of consequences to that too, what this means for companies and investors, one might not appreciate at first either. Then the discussion is at danger into devolving into fundamental critiques on society and life itself, it can get pretty awkward.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #24 on: August 04, 2017, 01:03:27 pm
Now, if your original question was guenuine, you can see if Evilpixie looks more like what you want to do.

It's missing X11/xpm.h, png.h and impy.h. They are all external image libraries and no idea if they could somehow compiled/installed on Windows. I think you need at least png support to load and save images I guess.

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #25 on: August 04, 2017, 02:53:59 pm
Compiling dependencies is often like opening russian dolls :/

I'm not 100% sure you can get it all using only Visual Studio, but in case it's useful (for evilpixie or any other software), you can gain lots of time by checking if somebody else hasn't compiled what you need already :
http://gnuwin32.sourceforge.net/packages.html
See for example libpng :
- The archive "Developer files" contains the headers (same on all platforms), and libpng.lib must be the only file you need for Visual Studio
- The archive "Binaries" contains the DLL, don't forget to put it alongside your exe for distribution.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #26 on: August 04, 2017, 03:45:01 pm
Getting libpng was quite easy, but not only png file support is not used in the project, but pngsupport.cpp has errors that prevents compiling it. Great way to release source code. Guess I can just exclude it from the project, but I even spent time to write a new error handler to replace Wobbly (wobbly.h, also missing from the project). Now I have to figure out how to handle that impy.h.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #27 on: August 05, 2017, 09:07:14 am
I think this is not worth the trouble. The source code is anyway in what I call a "transition phase C++" in which the programmer is moving from C to C++ but is doing most things the wrong way. Well that alone was not a reason to quit, but those pesky libraries. I think they could these days release raw .lib and include files for MSVC, because there is only Windows 10, right? When everyone knows how difficult it is to compile misc. shady linux libraries in Windows.