AuthorTopic: I'm making a paint program, so useful tools, ideas and features required please  (Read 156439 times)

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
I never really thought about it in the sense that we'd extrapolate the exact brightness trough lab colorspace X/Z cordinates or something like that...mostly because I am an artist and I've never been able to stand coding..so I dont have that thought set...I think your skillset gives you the capability to understand it with better metaphores in color theory and coding, but you tend to understimate the usefullness of just letting the end user customize things  :crazy:
s/extrapolate/interpolate

Basically it's because not every ramp is going to end and start on the same brightnesses, we need to know how each destination ramp maps onto the base ramp. Your idea of what would need duplication is slightly different from mine.

Yeah, as a programmer who cares about UI, I try pretty hard to minimize the requirement for customization.
Every additional customization increases the amount of confusion around a program geometrically

Quote

Ideally, I think it should just be a way of handling palletes that is ramp-oriented. That is so that when as you said there are ramps of diferent length than the "baserampsize" it is the user that decides how exactly they match up...because no matter how accurate LAB or whatever is it just doesnt know what you're going for.

Say you have the sprite's clothes, then you have his metal armor...and his hair or whatever.


 You know that his hair has two extra shadow tones, while the armor has two extra highlight tones...you just scroll the two ramps so they overlap in the way you know they should (excuse the hideous pallete....:p)
So just to be clear, this is your 'more complicated idea'? Explicitly-known ramp ends so you can visually offset them so they line up appropriately?
Actually, that is complicated. And surprising -- apparently I misunderstood your original, simpler  idea, because what you describe above is in my understanding not compatible with the above
(because in order for the simpler idea to work (single master ramp mapped to multiple maybe shorter ramps), you basically have to have the equivalent of that offset information anyway :)

Quote
In practice I guess the program would handle the tones from ramps with greater length as duplicate pallete entries (anything past the brightest red color will still be handled as the brightest red) but the idea would be that the program would only do it in a internal file format which would 'know' which are the duplicate entries, and you'd be able to export the file with clean single entries.
Oh I see, you're aiming for just a drawing tool, not also to be able to do strongly controlled colorswaps like I guessed you meant SF3 did. Maybe they didn't have such a thing.

Anyway there's some real benefit to exporting it with duplicate entries, and I would count the result as clean..
What I was thinking is like this:
1. Measure the brightness of the first and last color in the 'base' ramp
2. Normalize the destination ramps according to  this (measure their endpoints in order to do this)
3. Allow the user to override the brightness that the end colors of destination ramps are considered as.
4. Nearest-neighbor 'interpolate' and extrapolate each destination ramp so each ramp maps in a fairly reliable way to the original ramp.
(it's trivial to recover the without-duplicates version, providing you store the 'endpoint brightnesses' information with the ramps. duplication is just so ramp-swapping is just a quick matter of copying a tiny chunk of data.)

Now, with this scheme, you could always make sure that all of the colors in your ramps were accounted for, there might be duplicates before or after the original ramp contents (or even during, since the ramp might be stretched.),
and you would always be able to do ramp swapping in a snap. (normally, palette swapping is a snap but not ramp swapping. This is just because the ramps differ in length.)
Let me demonstrate:



It's nothing mind-blowing, but it does make sure a) you only have to do a single lot of shading and b) every ramp can be used in place of any other ramp for that sprite.

Quote
Now, suppose you wanted to add the extra shadow tones to the metal as well, but you dont want to add any extra tones
you just tell the program to use the two hair shadow tones for that, we already do that but we've no way of recording that those two entries in the ramp although the same tone as the ones in the hair one, are from the metal ramp. The idea would be to fix that...so that if suddenly it turns out that your game is going to a new platform that allows 2 more shades (or more likely you just decide to feck the limitations) it isnt a mess to recolor.
Oh right. yes, that's kind of problematic. I've been working on that too, it's fairly involved though, I have
'Master palette', 'Resource Ramps', 'Rendering Ramps', 'Rendering palettes'
we're talking about 'Resource Ramps' here (ordered lists of indices into the master palette, basically).
'Rendering ramps' are, roughly, formulae for combining and resampling ramps; 'rendering palettes' are just ordered lists of references to rendering ramps (with possible uneven spacing, but that's only of interest for CGing), which render into normal palettes (among other things.)

I've suggested a simplified version for OHRRPGCE over here:
http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php?title=Talk:Plan_for_256_color_sprites&curid=5027&diff=18503&oldid=18502

[/quote]
The whole third dimension view to it when adding multiple light sources ( I wonder if light sources is correct..more like chromatic filters..heh) sounds very smart.
[/quote]
It sounded better originally.. but basically, you had just described a new 3-dimensional colorspace..
Not very like RGB, LAB, HSL, Yiq, etc but nevertheless, same basic idea. Lightness Ramp Palette -- LRP colorspace. 

Two colors is good.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
To answer a few key posts:

Conceit
Quote
the whole HUD feels just WAAAAY WAAAY too big, way excessive for the few tools you have
No need to shout..  :P

It has a few tools now, but it won't in the future as it will have a lot more. Hence why the space is reserved until most of the tools are in there and then I can reorganise things.

Quote
Funny how being a pixelartist you'd go for bigger fonts and bigger icons instead of smaller...keep em regular size...and give us an option to disable the descriptions..eventually we should know everything by icon.
I never said I was a pixelartist! I'm a poor artist who likes to play with gfx and techniques. I like the little descriptions, but I suppose they might be unneccessary after a while.

Quote
BTW what's with the 2bit icons? I think that's hurting your ability do describe the tool easily a bit...you have to rely on thicker/thinner full/dotted line to convery things you could easily convey otherwise trough contrast in colors.
Your right, but I'm not an artist..

For everyone who has commented on the GUI, Icons, etc.. Do you want to help me with some new icons, fonts, designs, mockups to show me what you mean and to help me in general? If not, then don't expect me to be able to achieve what you'd like on my own!  :P There must be some good artists and graphics designers on here after all.  ;)

Quote
What's with having four chosen colors? in practice they seemed to work just like regular foregrond/background colors, expect two extra colors were chosen...I think I just didnt understand that feature at all.

You can use the normal left and right mouse button drawing or hold shift to draw with another two colours (useful when you are wanting to draw using 3 or 4 colours and don't want to keep changing the current pen colour from the palette or with a dropper on the canvas)

Ai:

Quote
Suggestion: Programmatic interface (like a scripting commandline). Because GUIs are severely un-expressive (they trade expressiveness for obviousness). This is the most realistic way to avoid having a bloated GUI imo -- allow your GUI to only show the commonly used options, and allow the user to express complex combination of commands and options using a command line. Python, Ruby, or Lua are all pretty painless in this role (with Python being the more powerful and Lua being the simplest to write bindings for)
I am thinking of moving towards a more data driven design with configuration files. It's just that this is the kind of low level work with which I can lose motivation and get frustrated. This time I want to get a lot of the program in there before trying to refine things. It might be a bit backwards and inefficient, but I'm not a classically trained programmer. :)

Quote
(in the style of what I posted @ http://www.wayofthepixel.net/pixelation/index.php?topic=922.msg80524#msg80524). In combination with number-entry fields for when you truly need to get some exact specific color, this should allow sliders to become irrelevant.
I did look at that.. you are obviously a very intelligent guy and have thought about things like this deeply. The maths you refer to in your posts sadly goes over my head..  :-[
For this particular point I am thinking of having several icon tabs where you can select from a range of colour selection methods, i.e. sliders, colour box, etc..

Quote
You might be able to play to them better if you use a GUI toolkit that's already made. This does not obligate you to have lots of light gray. http://www.clutter-project.org/ for example, is OpenGL based, fast, and the license doesn't require you to release your sourcecode. And they seem to like darker appearances Smiley
True, but I'm not too good at using other libraries as I get frustrated quickly with setting them up and using them properly (especially Object Orientated ones).

Jad:

THANK YOU!
I must admit I was feeling pretty discouraged when I saw some of the C&C. While a lot of it is valid, please remember that I'm doing this as a hobby, I'm not a professional programmer and I'm not trying to sell it!  ;D

Finally, mockups showing me a better GUI, icons, fonts, design etc would be welcome.. I'm sure some of you always wanted to do your own designs for a paint program! I'm not saying I'll use them, but it might help me. :)
« Last Edit: December 15, 2008, 05:42:11 pm by happymonster »

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Ok, I've updated the zip file. I don't know it the new program file will open up as a window now, I hope it does. I've also added a Pixe_desktop.exe in there which tries to open a window the full size of the desktop - the taskbar and title bar. No idea if it will work for you though! :)

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
You can use the normal left and right mouse button drawing or hold shift to draw with another two colours (useful when you are wanting to draw using 3 or 4 colours and don't want to keep changing the current pen colour from the palette or with a dropper on the canvas)
I think you'll need to monitor this and make sure it isn't YAGNI (You Ain't Gonna Need It), especially considering you do (or will, presumably) have keys to move to next or previous color. IMO it might be more obvious to provide a shortcut that swaps the first two colors with the (otherwise unknown and not shown) second two colors and vice versa.

Quote
Quote
Suggestion: Programmatic interface (like a scripting commandline). Because GUIs are severely un-expressive (they trade expressiveness for obviousness). This is the most realistic way to avoid having a bloated GUI imo -- allow your GUI to only show the commonly used options, and allow the user to express complex combination of commands and options using a command line. Python, Ruby, or Lua are all pretty painless in this role (with Python being the more powerful and Lua being the simplest to write bindings for)
I am thinking of moving towards a more data driven design with configuration files. It's just that this is the kind of low level work with which I can lose motivation and get frustrated. This time I want to get a lot of the program in there before trying to refine things. It might be a bit backwards and inefficient, but I'm not a classically trained programmer. :)
This makes me wonder if you write unittests for your code. If not, consider it -- Test Driven Development solves a lot of the motivation problems with anything where you can't obviously see or interact with the result. (such as.. pretty much anything that's not UI:)

Quote
Quote
(in the style of what I posted @ http://www.wayofthepixel.net/pixelation/index.php?topic=922.msg80524#msg80524). In combination with number-entry fields for when you truly need to get some exact specific color, this should allow sliders to become irrelevant.
I did look at that.. you are obviously a very intelligent guy and have thought about things like this deeply. The maths you refer to in your posts sadly goes over my head..  :-[
Thank you; If the math goes over your head I've not explained accurately.
There is no specific math inherent in it. My setup assigned a formula to each cell, but it needn't be so customizable,
it could be hard-coded and still be effective; so the only math involved is in calculating each cell's color
(interpolation, hue offsetting, etc..)

For example, as cells you could include:
(where i say 'first color' I mean the color you draw with on the left button without shift.)
* the two next and two previous colors in the current ramp (relative to first color), 
* 4 steps of interpolation between first and second color ie (aXXXXb)
* 4 versions of first color with saturation offset (two more, two less)
* 4 versions with increased/decreased lightness (whether you treat lightness as L of LAB, L of HSL, or V of HSV is up to you)
* 8 versions with various color-theory relationships to the first color (counterpart, contrast, triad, tetrad)

Thus, a somewhat different calculation is used to choose each cell's color, and is applied each time the foreground/first color changes (eg. clicking on a color to select it in the table of cells modifies the fore/first color, so all cells including that one must then be regenerated).
The only other very important part of that mockup I showed is really being able to swap between colors by clicking on the fore or back color
(it's designed for 2 colors, but you could modify that scheme to work for your 4-color setup)

Quote
For this particular point I am thinking of having several icon tabs where you can select from a range of colour selection methods, i.e. sliders, colour box, etc..
Yeah; I just meant, if you implement a relative color selector such as the one I described earlier and above, there's much less need for sliders.

Quote
Quote
You might be able to play to them better if you use a GUI toolkit that's already made. This does not obligate you to have lots of light gray. http://www.clutter-project.org/ for example, is OpenGL based, fast, and the license doesn't require you to release your sourcecode. And they seem to like darker appearances Smiley
True, but I'm not too good at using other libraries as I get frustrated quickly with setting them up and using them properly (especially Object Orientated ones).
At this point I have to ask whether you seriously think that, in the writing of a paintprogram, you can avoid writing and debugging enough GUI code that your frustration surpasses the frustration of setting up and using a premade GUI library. If you do, your frustration must be astronomical.

Quote
Finally, mockups showing me a better GUI, icons, fonts, design etc would be welcome.. I'm sure some of you always wanted to do your own designs for a paint program! I'm not saying I'll use them, but it might help me. :)
Mm, I have a few of those, relating to palette/ramp editing, plus some other ideas from my own pixel software I'm working on. You are welcome to those. If you PM me with an email address, I can send you the entire SVG (300k, mostly of text), or you can wait and I'll take a few captures of some areas and post them here.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Just got back in after seeing friends before Christmas. No time to reply properly, but I will just say that for the 4 pen colours thing I don't think it's overkill. After all it's completely transparant to the user if he/she doesn't want to use the extra two pens. In the situations where it would be useful, they always have the option.

*Added fill to colour (which if you fill with the left mouse button will only stop when it hits the colour in the right mouse button pen - useful for filling to outlines, etc..)
* Made zoom steps multiply, ie. x1, x2, x4, x8, x16, x32, x64. Much faster, but less precision. Not sure if it's too low..

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
Just got back in after seeing friends before Christmas. No time to reply properly, but I will just say that for the 4 pen colours thing I don't think it's overkill. After all it's completely transparant to the user if he/she doesn't want to use the extra two pens. In the situations where it would be useful, they always have the option.
It's only transparent if it doesn't occupy any screen space when not used.

Quote
*Added fill to colour (which if you fill with the left mouse button will only stop when it hits the colour in the right mouse button pen - useful for filling to outlines, etc..)
Interesting -- essentially 'binary fill'.

EDIT - Oh! This inspired an idea, so I fired up IPython and SciPy and tested it.

Higher order floodfilling -- eg. 12-way, 20-way.

12-way : dither fill, less invasive.  Fills most regular dithering in one click.
Queues pixels to fill like normal 8-way fill:
Code: [Select]
###
#.#
###
[code]

then checks the locations shown as *
[code]
  * 
 ###
*#.#*
 ###
  * 
and may queue them for filling if
a) the pixel is of the seed color
b) the immediately adjacent pixel (which has already been checked) is NOT of the seed color

I already have a slow implementation of this myself, available on request.

20-way : dither fill, more invasive. Fills even irregular dithering in one click.
Queues pixels to fill like 12-way fill,
Code: [Select]
  * 
 ###
*#.#*
 ###
  * 
Then checks the locations shown as !
Code: [Select]
!*!
!###!
*#.#*
!###!
 !*!
and may queue them for filling if
a) the pixel is of the seed color
b) the immediately adjacent two pixels (which have already been checked) are NOT of the seed color
(I also have a slow implementation of this)

(original image by me)
This is what they look like. each weird color represents one N-way floodfill.
First the original is shown, then the 12-way floodfill, then the 20-way floodfill.
You can see that 20-way does a more comprehensive fill, while also jumping around corners more.

another example:
(original image by Riva)

I think a lot of people around here would appreciate that kind of tool:)

EDIT2: Checking your ideas.xls, you actually have that general idea, without the specifics or testing shown here.
that thing is huge and intimidating :)

Quote
* Made zoom steps multiply, ie. x1, x2, x4, x8, x16, x32, x64. Much faster, but less precision. Not sure if it's too low..
Well, personally I think x3 is important (x128 is not so important, I would just like it). I like the idea of a sequence like this:
[1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128]

And it would probably be easier to have a precomputed lookup table of zoom levels rather than computing them in real time, and just have internal_zoom as an integer value from 0.. (length_of_zoom_lookup - 1). That'd also make it pretty easy to experiment with different zoom steppings.
[/code][/code]
« Last Edit: December 17, 2008, 07:00:13 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 Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
Just spotted this in the ideas.xls:
Quote
AA layers - Layers store colour sum and weight sum seperately for better quality alpha mixing and AA
I think I 'get' the motivation behind this, and it might be fulfilled by simply blending correctly (that is, when calculating a mix between two colors A and B, convert from standard gamma-encoded sRGB to linear RGB before doing the calculation.). I think this idea is simply motivated by the weird unpredictable AA that blending in a gamma-encoded space causes (if not, Surt, feel free to enlighten me). I would guess you already had gamma-correctness on the list, but you don't. Solving this should also improve the state of #49, 'simple rgb average, real as perceived'

If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline questseeker

  • 0010
  • *
  • Posts: 112
  • Karma: +0/-0
    • View Profile
Ellipses are awful. Rounding the center to pixel centers and radius to whole pixels, so that even sizes are impossible, is even worse than rounding incorrectly.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Quote
[1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128]
Yes, I was thinking of doing something like with a look up table. Just not had chance to implement it yet..

I like the flood fill testing, but I have an idea which might work better? Instead of testing horizontally and vertically like you do now (when most flood fills use horizontal or vertical spans) why not match the source pixel to ones in a target pattern? That would allow you to fill in custom dither pattens, as well as small patterns and potentially shapes that have previously been filled in with a pattern from a brush. Finding the XY offset for the pattern might be a bit tricky, as would trying to automatically find repeating patterns.

What do you think? :)

Quote
It's only transparent if it doesn't occupy any screen space when not used.
True again! But it's only two small pen gfx.. ;)

Quote
Ellipses are awful. Rounding the center to pixel centers and radius to whole pixels, so that even sizes are impossible, is even worse than rounding incorrectly.
Er.. thanks!  :P ProMotion seems to work in the same way.. Can you give me an example of how to do it?

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Right, the windowed->fullscreen thing was apparantly an engine issue. I think we've fixed that in the latest uploaded zip file.

I've also added the zoom look up table feature using this set of values:
1, 2, 3, 4, 6, 8, 10, 12, 16, 24, 32, 48, 64, 96, 128

It works nice for me when zooming, what do you think?
I've also updated the spreadsheet to reflect some of the features which have been implemented in the last week or so.

Any more ideas on the gui designs from the dissenting voices then? :P