I'm making a paint program, so useful tools, ideas and features required please

[surt]

This build fixes all the problems I mentioned for the last one. Nice.  (well still slow zoom, but doesn't seem as bad, so tollerable)

A couple of things that bug me though:

• In windowed mode, can't resize the window. And similarly window shows a maximise button, but won't maximise.
  
• Can't zoom out beyond 1x. While not useful for pixel editing as such, can be useful for navigating large spritesheets, tilemap mockups etc.

[happymonster]

Thanks Surt! I could add a slider for zoom speed as well as let you zoom out beyond x1 (that might be better as an optional button though, as it could easily get annoying with some kinds of work).

The windowed/maximise button thing is an engine issue. I will try to look at that with my friend, but that's not completely within my control.

[Ai]

Thanks Surt! I could add a slider for zoom speed as well as let you zoom out beyond x1 (that might be better as an optional button though, as it could easily get annoying with some kinds of work).

Personally, I think stopping zoom at 1x and requiring the user to start zooming again after a short timeout would be effective to avoid the effect I think you're talking about (accidentally passing below the 1x mark)

So to be clear, what I mean is, what level you can zoom to depends on what level you are currently at;
if zoom > 1, you can zoom all the way down to 1 before the timeout takes effect (or zoom in; the timeout wouldn't take effect). If zoom < 1 (i'm envisioning negative zoom as a swapping of numerator and denominator -- so -1 = 1/2, -2 = 1/3, -3 = 1/4, -4 = 1/6) then you can zoom all the way up to 1/1 before activating the timeout (or zoom out; the timeout wouldn't take effect)

hmm, that wasn't very clear. What I mean is to activate a timeout when the user wants to pass from the 'smaller-than-actual-size' zooms into 'larger-than-actual-size' zooms and vice versa. During the timeout, zooming away from the threshold would reset the timeout and zooming over it would have no effect.

[happymonster]

I think I got what you meant Ai and that's a good idea..

[surt]

What exactly is the problem with zooms at less than one? If the user zooms further than they intended they can always zoom back. And I certainly don't like the sound of another unecessary delay. That's the problem with changing zoom currently.

A few more minor things:

• The sizing of the circle and square tools only takes into account the x-axis of the cursor. The min of the abs values of both axes would be nicer.
• Also with circle and square with stretch-from-corner one can only draw to the upper-left and lower-right quadrants.
• Panning doesn't scale with zoom, always moving the same number of image-space pixels for a mouse motion, so as you zoom in further it gets harder to control.

[Ai]

Surt: My idea, if implemented correctly, will reduce the need for a delay, and make things work better without 'overshooting'. When I'm editing pixel art, I almost never mean to zoom < 1. Combined with an 'invert zoom' command (2x zoom -> .5x zoom, 3x zoom = .3333..x zoom, etc), this could work much nicer than any existing solution, and it's quite uncomplicated.

[happymonster]

The delay wouln't have to be big.. What I could do is make it that you can't scroll below x1 magnification until the wheel mouse is left untouched for a few frames. This would stop accidental scrolling and you'd just have to scroll the wheel again to go below x1.

Well, these are just thoughts at the moment anyway.

I'm now starting to rip out some of the hardcoded GUI related stuff and put things in a more modular and data driven system. It won't be completely flexible as certain tools need functions to be called, but it will make it easier to save positions, variables and change layouts from data.

I wanted to get the latest demo out there before doing this though..

[happymonster]

The gui panels for the basic primitive tools (draw, line, box, ellipse and fill) are now all in and working via external data files.
I still need to add support for other GUI objects like text and sliders to do some of the other more complicated gui panels.

[happymonster]

Still making progress, although nothing visible yet as it's a lot of internal data/gui work.

[Ai]

Not me. Although I am of course caught up in preparation.

I've made the kind of posts that you've made here, in your last 4 posts, and nobody responds to them as a rule.
They're like non-sequitours. For myself, I've found that if there is something exciting (in a generally understandable sense -- I mean eg. spline
interpolation is pretty nifty, but hardly anyone knows much about it here.) and some aspect I can show to be a major benefit, I might get responses. Otherwise I just put it in my git commit-log.

Personally I am not in a position to test Pixe, since it doesn't yet run on Linux. If that changes, I shall certainly try it.

Suggestion: PoTrace support, for better auto-AA of single-color regions. Unless you actually vectorize things in your AA filter, it is always going to have less quality than a good tracer like PoTrace (with the tradeoff of staying slightly truer to the lines)
I've implemented this myself, by shelling out to potrace, connecting to its standard input and output to feed input image in and get output image, and requesting '--pgm' output format.

http://potrace.sf.net

Probably not so realistic suggestion: 2d inverse kinematics (IK). Usable for getting consistent proportions when animating, and
determining when a pose is physically impossible. Sort of like a stick figure, without gravity but with tension between line joints and adjustable proportions. (I was thinking that eg.. if the user resizes the head to match their character, the proportions of everything else should be scaled to keep the same proportion; and if they really want to adjust proportions (eg big head) they can do that with say ctrl+drag)
With a base skeleton according to some of the figures here: http://realcolorwheel.com/human.htm )
Yeah, complicated idea. Even if it didn't have IKA or proportion adjustment, just the ability to rotate the component lines without changing their length, that could be an effective animation aid.