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

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
SF3 uses it in an even greater degree than I described, because if you pay attention closely...they do not only have different hue information for every part of the sprite, they have two totally different and separate palletes that go from the brightest color to the darkest color for every single frame. That is how they make their two lightsources, they have the normal sprite and the blue sprite, then they use some kind of tool to tell the painting program which part uses the blue hue, and which one uses the normal white hue.

if you think this could be of any use at all...I have an even more complicated idea about this...involving actually completely diferent shadings for each hue.....it would be useful for characters that have chromed armor and normal clothing...

Are you thinking like a separate channel for each hue?[1] Or what?

(IMO, you'd be better off using the word 'ramp' where you use 'hue', since 'hue' also refers to a property of individual colors)




Another idea: thresholded gaussian blur (as a filter-brush type thing). The idea here is not to blur exactly, but to smooth the shapes without changing the pixel colors.
This is kind of apropos to the 'interface morphology tool' in that it would work on the interface between two colors.
I used a two-step process amounting to this recently when I had some partly lumpy regions that really should have been smooth. This is particularly useful if you've just rotated or skewed the image, it tends to get odd stick-outy pixels where you really don't want them.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Conzeit

  • 0100
  • ***
  • Posts: 1448
  • Karma: +3/-0
  • Camus
    • conzeit
    • View Profile
    • CONZEIT
* You have to use LAB colorspace to obtain brightness measurements of the colors in the base and target ramps. Otherwise, you FUBAR the brightness in inconsistent and unpredictable ways.
* This method is best thought of as sampling over a 2d color-grid, where X is brightness, Y is color, and
   colors may repeat on some scanlines (where less colors than base ramp length are used)
   The method I was working on for CGing would allow sampling at fractional coordinates (ie. between colors / color ramps). What you describe only allows integer coordinates.

* the 'two lightsources' trick can be thought of as a third (albeit binary) dimension to the sampling.
   So you have something like a 17bit format here :). Of course, typically it'd be more like 3 + 3 + 1 = 7 bits (ramp of <= 8 brightnesses, <= 8 different ramps, 1 bit for palette toggle)
   Which leads me to think that this kind of thing might be doable as mainly an adjunct to palette editing.
   recoloring mode could just look at base ramp length and current drawing color to recolor pixels.
   essentially:
Code: [Select]
   targetramp = int (FGcolorindex / baserampsize)
   sourceramp = int (pixel[y][x] / baserampsize)
   pixel[y][x] = (pixel[y][x] - (sourceramp * baserampsize)) + (targetramp * baserampsize)
  
  You might not like the duplicate palette entries that occur for ramps shorter than baserampsize,
  but IMO that is the job of either the saving code or external optimization software to fix
  (you might not want to optimize them out anyway, if you want realtime ramp swapping)

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:

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)

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.

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.

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.


And you are totally right about the 2bit fuck up. Although familiar with the term and the concept, I dont often use it so I fucked up even though I knew 1 bit is 0s and 1s  :o should just man up and say two colors lol.
« Last Edit: December 15, 2008, 04:10:37 am by Conceit »

Offline surt

  • 0011
  • **
  • Posts: 570
  • Karma: +0/-0
  • Meat by-product
    • not_surt
    • http://pixeljoint.com/p/2254.htm
    • View Profile
    • Uninhabitant
Tried the build.
Wine kept complaining about DLL's, so I booted into windows (:blind:) and it ran fine though full screen as the others mention.
Things I noted:
  • When zoomed and using a one-pixel brush the brush isn't correctly placed on the pixel the cursor is over.
  • With grid fit on the ellipse snaps a pixel too short on each axis with stretch and a pixel too long with expand.
  • The inverted panning is yech!
  • Slow zoom is yech!
Otherwise quite nice, runs nice and responsively, stroke samples very smoothly.

Offline TrevoriuS

  • 0011
  • **
  • Posts: 550
  • Karma: +1/-0
  • Pixels... everywhere!!
    • View Profile
  • When zoomed and using a one-pixel brush the brush isn't correctly placed on the pixel the cursor is over.
I don't seem to have this :O
Quote
  • The inverted panning is yech!
Nah, this is natural, you're just used to the wrong :P

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Woah! Far too many comments to reply to..

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.

I'll try to write more tonight, but got to go to work now.

Offline Frychiko

  • 0010
  • *
  • Posts: 211
  • Karma: +0/-0
  • Don't waste garbage here.
    • View Profile
It's coming along very nicely, feels very slick and I like the animation in the GUI (fading text). The whole app just barely fit on my netbook screen! (1024 x 600). Keep it up!



Congratulation this story is happy end. Thank you. - Ghost & Goblins

Offline surt

  • 0011
  • **
  • Posts: 570
  • Karma: +0/-0
  • Meat by-product
    • not_surt
    • http://pixeljoint.com/p/2254.htm
    • View Profile
    • Uninhabitant
I don't seem to have this :O
For me it's by about half a vertical pixel. Horizontal looks right.
Nah, this is natural, you're just used to the wrong :P
Not according to GraphicsGale, Gimp and Blender. AFAIAC if the canvas is moving and the cursor is moving they should be moving together, if the cursor was locked I could live with inverted panning (see Transport Tycoon).

Cursor locked panning would be nice as an option anyway, as then you can pan off mouse mickeys, rather than cursor displacement, and not be window limited.

Offline Jad

  • 0100
  • ***
  • Posts: 1048
  • Karma: +0/-0
    • View Profile
Woah! Far too many comments to reply to..

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.

I'll try to write more tonight, but got to go to work now.

Don't be disencouraged, save all these resourceful replies and use them later if the need arises! I'd say what you've got going is super cute (yes, pixel software can be cute), so go ahead and take the suggestions you can work with and DON'T FEEL PRESSURED! I'm super impressed with what you've got!
' _ '

Offline surt

  • 0011
  • **
  • Posts: 570
  • Karma: +0/-0
  • Meat by-product
    • not_surt
    • http://pixeljoint.com/p/2254.htm
    • View Profile
    • Uninhabitant
I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.
A good argument for using an existing widget toolkit, no?

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
Woah! Far too many comments to reply to..

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.
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 :)
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.