Re: [Tuxpaint-dev] TuxPaint 0.9.14 Mac OS X Build Available to Test
On Wed, 2004-11-10 at 12:56, Bill Kendrick wrote: > On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote: > > Also, this isn't posted to this list because you've > > blocked non-subscribers. I wish you wouldn't do that. > > The [EMAIL PROTECTED] way is the right way. > > Well, if you want 95% spam on the list, sure, I can allow non-subscribers to > post. :) I'm not seeing that on the [EMAIL PROTECTED] mailing list. I think I get about 1 spam per day. The list has been around for a while, and it has been mentioned all over: freshmeat.net, the procps web site, every release announcement, emails on linux-kernel, etc. The linux-kernel list gets a bit more, but not much. Just a couple spams per day make it past the filters, in a flood of 100 to 400 legitimate messages per day. Dropping HTML mail eliminates most of the spam. The positive benefits of an open list are huge. Bug reports can come in freely. Also, do NOT force replies to go to the list or not. Decent mailers provide both reply-tosender and reply-to-all (group reply) abilities; these must be left distinct to be useful. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] TuxPaint 0.9.14 Mac OS X Build Available to Test
On Wed, 2004-11-10 at 14:57, Bill Kendrick wrote: > On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote: > > Quoting various people: > > > > > 1. 'Starters' are broken, ... > > This is not only a MacOS problem. I get it too. > > > > Tuxpaint: from CVS yesterday > > OS: Debian-unstable with the 2.6.9-rc4 kernel > > Video: 24-bit (in 32-bit, AFAIK), w/ big display > > Hardware: Mac G4 Cube (yes, running Linux) > > > > So, while I'm not running MacOS, I do use a Mac. > > Odd features of the Mac hardware include: > > > > 1. big-endian > > 2. "char" is unsigned by default!!! > > 3. most (not all) audio hardware is big-endian only > > Hrm, okay, so this might be a clue as to what's going on. > Unfortunately, without a Mac to debug on, I can't help here. I just tried compiling TuxPaint like this: make CC='gcc -fsigned-char' PREFIX=/usr There was no change. If starter images use some unusual feature of the SDL library, the problem could be in SDL. I suggest adding more warnings, like the ones used for procps: PKG_CFLAGS := -fno-common -ffast-math \ -W -Wall -Wshadow -Wcast-align -Wredundant-decls \ -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return \ -Wstrict-prototypes -Wmissing-prototypes > Are you able to build with debugging printf()'s turned on? > Do they provide any hints as to what's going on? I can build any way you like, but I wouldn't know what to look for. Nothing obvious stood out in a grep like this: egrep -i4 -- 'starters|-back' src/*[hc] | less -i > > BTW, the sound is messed up too. I just get static. > > Unfortunately, this is /not/ an issue on the latest Mac OS X build. > Can you try altering the buffer size being set when the SDL sound system > is first being initialized? Assuming you mean the last parameter to Mix_OpenAudio, I tried 8192, 2048, and 256. Sound is still bad. My sound goes through esd (Enlightenment sound daemon) to USB speakers. I don't think the USB speakers support more than one sampling rate. I can play MP3s just fine, the game Abuse works OK, the game SuperTux is staticy... ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] TuxPaint 0.9.14 Mac OS X Build Available to Test
On Wed, 2004-11-10 at 14:57, Bill Kendrick wrote: > On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote: > > BTW, the sound is messed up too. I just get static. > > Unfortunately, this is /not/ an issue on the latest Mac OS X build. > Can you try altering the buffer size being set when the SDL sound system > is first being initialized? Using AUDIO_S16MSB fixes it: if (Mix_OpenAudio(44100, AUDIO_S16MSB, 2, 1024) < 0) Now that I have sound working, I notice that latency is a problem. I can take the buffer size way down, but it doesn't help. (I tried 64) Maybe the sound files need to be trimmed. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] contributing -- how?
I can't seem to figure out the procedure for getting changes accepted, or at least rejected. I could use a comparison between the proper procedure for TuxPaint and the Linux kernel procedure that I'm far more familiar with. I've already tried sending a patch. (unified diff format, in the body of an email with a subject that starts with "[PATCH]"). I don't seem to have the needed permission to check something into CVS. What's the story here? It's a pain to write code without knowing if previous changes have been accepted or rejected. I can't count on the state of things. BTW, if I violate some unspoken rule, please gently explain things to me. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] [PATCH] misc fixes
So, here's a patch. It's in the style used for Linux work.
For those not familiar with this:
cd tuxpaint-source-directory
patch -p1 -E -s < this-email-perhaps-including-headers
Hopefully somebody can apply this soon. It does:
1. add some warning flags to the Makefile
2. adjusts the colors (fixing bug #1053065)
3. fixes the purple tint for some tools
4. fixes audio on a Mac running Linux
5. increases MAX_STAMPS to 512
diff -Naurd old/Makefile wip/Makefile
--- old/Makefile2004-10-24 17:02:51.0 -0400
+++ wip/Makefile2004-11-20 21:42:56.0 -0500
@@ -93,7 +93,11 @@
# The entire set of CFLAGS:
-CFLAGS=-O2 -Wall
+CFLAGS=-O2 -Wall -fno-common -ffast-math \
+ -W -Wall -Wcast-align -Wredundant-decls \
+-Wbad-function-cast -Wwrite-strings -Waggregate-return \
+ -Wstrict-prototypes -Wmissing-prototypes
+
DEFS=-DDATA_PREFIX=\"$(DATA_PREFIX)\" \
-D$(NOSOUNDFLAG) -DDOC_PREFIX=\"$(DOC_PREFIX)\" \
-DLOCALEDIR=\"$(LOCALE_PREFIX)\" -DCONFDIR=\"$(CONFDIR)\"
diff -Naurd old/src/colors.h wip/src/colors.h
--- old/src/colors.h2004-02-09 23:48:42.0 -0500
+++ wip/src/colors.h2004-11-20 21:34:47.0 -0500
@@ -17,20 +17,22 @@
enum {
COLOR_BLACK,
+ COLOR_GREY,
+ COLOR_SILVER,
COLOR_WHITE,
COLOR_RED,
COLOR_PINK,
COLOR_ORANGE,
COLOR_YELLOW,
- COLOR_LIME,
+ COLOR_NEON,
COLOR_GREEN,
- COLOR_CYAN,
+ COLOR_SKYBLUE,
COLOR_BLUE,
COLOR_PURPLE,
- COLOR_FUCHSIA, /* ... */
+ COLOR_MAGENTA,
COLOR_BROWN,
- COLOR_GREY,
- COLOR_SILVER, /* ... */
+ COLOR_TAN,
+ COLOR_BEIGE,
NUM_COLORS
};
@@ -39,20 +41,22 @@
int color_hexes[NUM_COLORS][3] = {
{0, 0, 0}, /* Black */
+ {128, 128, 128}, /* Gray */
+ {192, 192, 192}, /* Silver */
{255, 255, 255}, /* White */
{255, 0, 0}, /* Red */
- {255, 128, 160}, /* Pink */
+ {255, 165, 211}, /* Pink */
{255, 128, 0}, /* Orange */
{255, 255, 0}, /* Yellow */
- { 0, 255, 0}, /* Lime */
- { 0, 132, 64}, /* Green */
- { 0, 255, 255}, /* Cyan */
+ {140, 255, 0}, /* Neon */
+ { 33, 148, 33}, /* Green */
+ {138, 168, 205}, /* Sky blue */
{ 0, 0, 255}, /* Blue */
{ 96, 0, 128}, /* Purple */
- {255, 0, 255}, /* Fuchsia */
+ {255, 0, 255}, /* Magenta */
{128, 96, 0}, /* Brown */
- {128, 128, 128}, /* Gray */
- {192, 192, 192} /* Silver */
+ {226, 189, 166}, /* Tan */
+ {247, 228, 219}, /* Beige */
};
@@ -60,18 +64,20 @@
char * color_names[NUM_COLORS] = {
gettext_noop("Black!"),
+ gettext_noop("Gray!"),
+ gettext_noop("Silver!"),
gettext_noop("White!"),
gettext_noop("Red!"),
gettext_noop("Pink!"),
gettext_noop("Orange!"),
gettext_noop("Yellow!"),
- gettext_noop("Lime!"),
+ gettext_noop("Neon green!"),
gettext_noop("Green!"),
- gettext_noop("Cyan!"),
+ gettext_noop("Sky blue!"),
gettext_noop("Blue!"),
gettext_noop("Purple!"),
- gettext_noop("Fuchsia!"),
+ gettext_noop("Magenta!"),
gettext_noop("Brown!"),
- gettext_noop("Gray!"),
- gettext_noop("Silver!")
+ gettext_noop("Tan!"),
+ gettext_noop("Beige!"),
};
diff -Naurd old/src/tuxpaint.c wip/src/tuxpaint.c
--- old/src/tuxpaint.c 2004-10-24 17:25:17.0 -0400
+++ wip/src/tuxpaint.c 2004-11-20 21:39:06.0 -0500
@@ -28,6 +28,10 @@
#define VER_VERSION "0.9.15"
#define VER_DATE"2004-10-24"
+#define VIDEO_BPP 15 // saves memory
+//#define VIDEO_BPP 16 // causes purple discoloration
+//#define VIDEO_BPP 24 // compromise
+//#define VIDEO_BPP 32 // might be the fastest, if conversion functions removed
/* #define DEBUG */
/* #define LOW_QUALITY_THUMBNAILS */
@@ -506,7 +510,7 @@
SDL_Surface * img_title_names[NUM_TITLES];
SDL_Surface * img_tools[NUM_TOOLS], * img_tool_names[NUM_TOOLS];
-#define MAX_STAMPS 256
+#define MAX_STAMPS 512
#define MAX_BRUSHES 64
#define MAX_FONTS 64
int num_brushes, num_stamps;
@@ -4997,7 +5001,7 @@
else
{
#ifndef WIN32
- if (Mix_OpenAudio(44100, AUDIO_S16, 2, 1024) < 0)
+ if (Mix_OpenAudio(44100, AUDIO_S16SYS, 2, 1024) < 0)
#else
if (Mix_OpenAudio(44100, AUDIO_S16, 2, 2048) < 0)
#endif
@@ -5043,10 +5047,10 @@
{
#ifdef USE_HWSURFACE
screen = SDL_SetVideoMode(WINDOW_WIDTH, WINDOW_HEIGHT,
- 16, SDL_FULLSCREEN | SDL_HWSURFACE);
+ VIDEO_BPP, SDL_FULLSCREEN | SDL_HWSURFACE);
#else
screen = SDL_SetVideoMode(WINDOW_WIDTH, WINDOW_HEIGHT,
- 16, SDL_FULLSCREEN | SDL_SWSURFACE);
+ VIDEO_BPP, SDL_FULLSCREEN | SDL_SWSURFACE);
#endif
if (screen == NULL)
@@ -5064,9 +5068,9 @@
if (!fullscreen)
{
#ifdef USE_HWSURFACE
- screen = SDL_SetVideoMode(WINDOW_WIDTH, WINDOW_HEIGHT, 16,
SDL_HWSURFACE);
+ screen = SDL_SetVideoMode(WINDOW_WIDTH, WINDOW_HEIGHT, VIDEO_BPP,
SDL_HWSURFACE);
#else
- screen = SDL_SetVideoMode(WINDOW_WIDTH, WINDOW_HEIGHT, 16,
SDL_SWSURFACE);
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Sun, 2004-11-21 at 20:25, Mark K. Kim wrote: > Turning on extra error messages sounds good. That's all you can turn on without... a. being gcc version-specific b. getting warnings for standard include files c. going insane :-) Regarding the last, there are a couple warnings that may look impossible to eliminate at first glance, but are not bad once you get what the concise message is all about. Adding "static" in places (default for C++, but not for C) will be helpful. > -ffast-math should be okay, but it also turns on > -funsafe-math-otpimizations which I'm kind of weary of... Any experts on > this option? It's not really unsafe. :-) Normally, math is seriously slowed down by requirements related to the following: a. must set errno for sqrt(-5.2) and other bad math b. must not do algebraic optimization c. must cause SIGFLT signal in the right places Some people like to trap division by zero so that they can substitute in a "correct" value. Some people like to trap overflow so that they can fudge the exponent for greater range. There's no way Tux Paint will be doing this kind of thing. > > - COLOR_LIME, > > + COLOR_NEON, > >COLOR_GREEN, > > - COLOR_CYAN, > > + COLOR_SKYBLUE, > >COLOR_BLUE, > >COLOR_PURPLE, > > - COLOR_FUCHSIA, /* ... */ > > + COLOR_MAGENTA, > >COLOR_BROWN, > > - COLOR_GREY, > > - COLOR_SILVER, /* ... */ > > + COLOR_TAN, > > + COLOR_BEIGE, > >NUM_COLORS > > }; > [snip] > > I like these color names better than the previously defined ones, but if > we're going to change the names of the colors, let's use the canonical > names, perhaps adopting the color names in /etc/X11/rgb.txt file. We may > also have to retranslate the color names. I went for kid-friendly. I struggle to spell fuchsia. I asked my wife for an opinion, and she reports that a kid's toy and/or TV show (both I guess) uses "magenta". A kid trying to pronounce "fuchsia" could get offensive. :-) The "Sky blue" is actually that now, computed as the average value of the sky in numerous images of the sky. (if you try this, remember to allow for gamma) Likewise, tan and beige were computed from many images. I don't care for "silver", since it doesn't sparkle or gleam, but I figured "light grey" might be to difficult to read. BTW, both "grey" and "gray" are considered correct spellings. > > -#define MAX_STAMPS 256 > > +#define MAX_STAMPS 512 > [snip] > > If we're gonna increase the stamps, is 512 enough? What's our stamps > collection size? It'll do as an emergency fix. I hit the limit with about three dozen local stamps. > [snip] > > #ifndef WIN32 > > - if (Mix_OpenAudio(44100, AUDIO_S16, 2, 1024) < 0) > > + if (Mix_OpenAudio(44100, AUDIO_S16SYS, 2, 1024) < 0) > > #else > > if (Mix_OpenAudio(44100, AUDIO_S16, 2, 2048) < 0) > > #endif > > This change is for Mac, right? Does this change negatively affect Linux > and/or BeOS (or Sun, etc.)? It should help more machines than it hurts. CPU soundcard notes LE LECommon PC. Unchanged. LE BEBroken before, and broken now. (rare) BE LEBroken now, but expected to be rare. BE BEMac. Now works, even if the drivers won't byteswap. It's rare to have a soundcard that only works with a byte order that is opposite to the CPU. I believe that the MacOS port will handle both; we'll see. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] rainbow tools
I think it would be good to have a tool, or tools,
for drawing rainbows.
For the primary rainbow, the inside angle is 80 degrees
total (40+40) and the outside angle is 84 degrees. If we
assume that a tuxpaint canvas has a 70-degree vertical
field of view, same as used for popular FPS games, the
rainbow size in pixels is determined.
One might wish to draw a partial rainbow, and one might
wish to place the horizon anywhere. So, trouble...
The interface that comes to mind is that the user does
a click-and-drag with rubber band effect to see where
the rainbow will go. Constrain the second point to be
within the diameter of the rainbow and not directly
above or below the first point. Then there are exactly
two circles passing through the two points, each divided
into two arcs by the points. Eliminate the arcs that have
an upside-down portion. This leaves one arc to be rendered
as the rainbow.
The next problem is endpoint treatment. They can be cut
horizontally, but that is no good near the edges of the
screen. Fading out is an option. Fading out is especially
useful for realistic (as opposed to cartoon-like) rainbows.
Cartoon-like rainbows have nicely distinct colors. In some
ways though, they propagate a lie about how rainbows look.
Realistic rainbows are beautiful and educational, but can
be trouble. Going from inside to outside, you get:
a. a bright area
b. blue to red (40 to 42 degrees) bright primary bow
c. a dark area
d. red to blue (50 to 53 degrees) dim secondary bow
e. slightly bright area
When the Sun is low, you only see the yellow-red part.
When the raindrops are big, the top is missing. (the
drops are no longer spherical) When the drops are small,
you get green and magenta bands just inside the primary
bow. (caused by interference effects)
I have the data I need to produce this. The problem of
course is that the whole screen must be updated in order
to get the light areas ("a" and "e") right. This pretty
much means that usage must be:
1. draw the background (sky,clouds,airplanes...)
2. add the rainbow
3. draw the foreground
Thoughts?
BTW, something involving spline paths also comes to mind.
See the Inkscape "write your name" example in the tutorial,
and imagine a rainbow rendered along the path. It wouldn't
have the correct shape and size, but might be useful for art.
(it's messy and near-useless for teaching about rainbows)
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] image usage terms
Are these terms acceptable for Tux Paint? http://gallery.hd.org/terms.html ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] image usage terms
On Mon, 2004-11-22 at 16:27, Ben Armstrong wrote: > On Mon, 2004-11-22 at 16:02 -0500, Albert Cahalan wrote: > > Are these terms acceptable for Tux Paint? > > http://gallery.hd.org/terms.html > > No. Redistribution is not allowed. Oh, duh. Somehow I missed that. I suppose I could ask for an exception. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] hu_HU.UTF-8
Why is it that this language alone does not set both LANGUAGE and LC_ALL in tuxpaint.c? Would it be harmful to set them both? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Reminder to CVS commiters!
On Mon, 2004-11-22 at 18:32, Bill Kendrick wrote: > Along with describing your changes in the CVS commit logs, please > try to also update "docs/CHANGES.txt" with your changes, so that when > we go to release the next version, we'll be able to tell people what > has been changed. So, this is including changes that are not user-visible? You'll filter those out for the users? How is the docs/CHANGES.txt file different from a copy of the CVS log data? (important, because there are ways to dump out the CVS log data if that is all you need) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] mouse movement bug
Here are two problems which might be the same bug. You may need a slow computer or large display to hit them. BTW, I have sound off right now. When placing a stamp, marks can get left on the screen. This is especially so if the mouse is moved quickly just prior to placing the stamp. When drawing a line, the end can remain undrawn. As the mouse moves, bits of the line are rendered. If the mouse is moved quickly, it can get ahead of the rendering. Then, if the mouse is suddenly stopped, there will be an unrendered gap next to the mouse pointer. The gap becomes permanent if the mouse button is released, but the gap is fixed if a tiny mouse movement is made. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 06:13, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in > > +#define VIDEO_BPP 15 // saves memory > > This causes severe dithering artifacts. It's particularly visible > on the colour buckets, which look look *really* bad now. Odd. Is your display actually in 16 bpp mode? For me, the 16 bpp value was horrid, and the 15 bpp value is indistinguishable from 24 or 32. My display is 32 bpp. > > +//#define VIDEO_BPP 16 // causes purple discoloration > > And even white (!) aren't properly handled! This setting is severely defective. Try this: Fill the screen with dark grey. Put a bunch of small light grey spots packed closely together, so that you can blur them to make a medium grey color. Now do that... and you see a purple tint after a while. > > +//#define VIDEO_BPP 24 // compromise > > +//#define VIDEO_BPP 32 // might be the fastest, if conversion > > functions removed > > Is there any reason we can't use 32 bit mode? Pro: 1. accurate 2. less bit shifting and alignment trouble 3. can rip out some slow N-bpp to 32-bpp conversion code Con: 1. undo buffers take up 2x space 2. less of the image will fit in the CPU's cache The record/playback feature could be used to benchmark this. After drawing enough to use up all the undo buffers, memory usage could be examined with ps, top, and pmap. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 06:29, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > The "Sky blue" is actually that now, computed as the average > > value of the sky in numerous images of the sky. (if you try > > this, remember to allow for gamma) Likewise, tan and beige > > were computed from many images. > > The sky blue looks a bit too grey. I'll play around with a bit. I'd rather you didn't just manually tweak it. If you'd like a less overcast sky, I could compute what that would be. Unless you're in Arizona, look outside some time. The sky really is that grey. Maybe I should post a program for computing this; it'd expect to read in a correct (sRGB gamma, NOT 1.0 gamma) *.ppm file filled with patches of sky. (you cut-and-paste from a wide variety of sky pictures to get this) > I really like the tan and beige colours, by the way. > > I'm really tired of apps using only fully-saturated colours. > (Especially cyan hurts my eyes.) A more subdued palette is easier > on the eye, and images drawn with these colours really look > better. (And no, bright, satuared colours are not more 'fun' for > kids!) In the sRGB color space, blue is dark and saturated. Yellow and cyan are not saturated. Yellow is bright. If we had more slots (could be an option -- they get smaller) I'd choose a dozen hues, with the brightness of both blue and yellow, at the maximum saturation (not much!) that can be shared by all the hue+brightness choices. > > I don't care for "silver", since it doesn't sparkle or gleam, > > but I figured "light grey" might be to difficult to read. > > Huh? These are not colors: silver, gold, sparkely, chrome They refer primarily to some non-color light reflection properties. Well, the Tux Paint "silver" is a plain color. It doesn't do anything exotic and impossible, and doesn't even attempt to mimic the look via white highlights. > But anyway, the buttons for all the greyscale colours look > almost the same, so we should think about removing some of them. > I'll try to come up with a proposal for a new colour palette. No, we should think about changing the way the buttons look. Either that, or live with it. The current buttons are pretty, but they don't handle all of the colors well. We need all 4 shades of grey -- I didn't change them, BTW. Clarity can be had at the expense of some beauty. Well, maybe you would find this beautiful! Beauty is in the eye of the beholder. Suggestion for clarity: Put some horizontal black stripes as the background of the color selector. (2 to 5 pixels thick) Add some elliptical patches of color, perhaps turned 15 degrees to the right. The color is the button, unmolested by shading effects that don't work quite right on black and white anyway. > (This is easier said than done. One important thing to be aware > of, is that all colours must give different tints when tinting > stamps. We had a problem with magenta and purple before. The two > colours looked completely different, but gave the same colour when > tinting stamps. Some very minor modifications to the colour values > fixed this.) I don't think that's a big problem. I'd rather have the original magenta and purple. (didn't change it back though) If the tinting code doesn't handle brightness, then that's the problem that needs fixing. Choosing less-desired colors to work around this problem hurts much more than the minor limit on the few rare tintable stamps. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] (void*)str;
+ void * kluge; + + kluge = (void *) str; /* So 'str' param _is_ used when DEBUG is off; +thus avoiding compiler warnings */ + You don't need the extra variable. Just do this: (void*)str; ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] high-resolution stamps work now
In the *.dat file, you put a line like one of these: scale 2 scale = 2 scale=2 scale 2.71 scale 2:3 scale=5/12 scale 5 / 12 scale 80% Before this gets out into the wild, scale factor direction needs to be set in stone. According to a 3rd-party (my wife), this is most intuitive: (considering a 640x480 display) 200% makes the stamp twice as wide 2 means that the stamp file is 2x what it should be 2/1 ? (didn't ask, but same as above would make sense) 2:1 ? (didn't ask) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 15:38, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in >> [somebody] > >> Is there any reason we can't use 32 bit mode? > > > > Pro: > > > > 1. accurate > > 2. less bit shifting and alignment trouble > > 3. can rip out some slow N-bpp to 32-bpp conversion code > > > > Con: > > > > 1. undo buffers take up 2x space > > 2. less of the image will fit in the CPU's cache > > Well, then I think it's worth moving to 32/24 bit. Memory is > cheap, and we really can't have a drawing program that doesn't > handle colours properly, can we?! I tried to benchmark this, but the --playback option doesn't seem to work. Does it word for anybody? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 15:26, Karl Ove Hufthammer wrote: > Yes, I know. But that doesn't mean that a greyish blue is a > *good* colour to use for drawing cartoon-like sky in a childrens' > program. We don't need photo-realistic colours; we need useful, > good-looking colours. > > >> I'm really tired of apps using only fully-saturated colours. Conflict? :-) > > In the sRGB color space, blue is dark and saturated. > > Yellow and cyan are not saturated. > > I did not know that sRGB defines a formula for saturation. But at > least in my image processing progams, both bright yellow and > bright cyan have full (100%) saturation (the HSL colour model). > This is also in line with how the word 'saturation' is used in > everyday language. The sRGB space maps to the CIE XYZ space, which is based on careful measurement of human subjects comparing colors. There is a perceptually uniform mapping of CIE XYZ, called the L,a*,b* color space, that is very human-friendly if you put the "a" and "b" part into polar coordinates. The radius is saturation, and the angle is hue. The HSL color model, to put it bluntly, is a disaster. Surely you don't believe that yellow and cyan have the same saturation and brightness, yet HSL would have this be so. > > If we had more slots (could be an option -- they get smaller) > > We actually had fewer in earlier versions. But I really don't want > to increase the number. A better solution would be a palette tool. > See bug #1070398: > http://sourceforge.net/tracker/index.php?func=detail&aid=1070398&group_id=66938&atid=516298 That's not an easy user interface, unless the palette simply sits where to color picker does today. I guess that means multiple rows. Three rows in a honeycomb layout would be OK. > Yes, I know. That's why I don't like to use 'silver' as a colour. > What I didn't understand was why you thought 'light grey' might be > difficult to read. lig-hit grey > >> But anyway, the buttons for all the greyscale colours look > >> almost the same, so we should think about removing some of > >> them. I'll try to come up with a proposal for a new colour > >> palette. > > > > No, we should think about changing the way the buttons look. > > Either that, or live with it. The current buttons are pretty, > > but they don't handle all of the colors well. We need all 4 > > shades of grey -- I didn't change them, BTW. > > Why? Do kids use all shades of greys in their images? (Ordinary > crayons often doesn't even contain *one* shade of grey.) I would > rather believe that 'colourful' colours would be useful. And > there's always the darken/lighten tool if you really need more > greyness. Crayons are easier to control for light/dark. The fade tool is nowhere near as easy and accurate. > I think black, white and grey (around 50 % black) should suffice. I was thinking that a 3rd grey would be nice. > >> (This is easier said than done. One important thing to be > >> aware of, is that all colours must give different tints when > >> tinting stamps. We had a problem with magenta and purple > >> before. The two colours looked completely different, but gave > >> the same colour when tinting stamps. Some very minor > >> modifications to the colour values fixed this.) > > > > I don't think that's a big problem. I'd rather have the > > original magenta and purple. (didn't change it back though) > > If the tinting code doesn't handle brightness, then that's > > the problem that needs fixing. Choosing less-desired colors > > to work around this problem hurts much more than the minor > > limit on the few rare tintable stamps. > > The stamp tinting code tints stamps to the tint of the colours, > and AFAICS works correctly. The colours were the problems, and > were easy to fix. The new colours weren't less-desired, The tinting code does not work correctly, because it ignores the brightness. Purple is dark magenta. I'm not sure what to call that color there now, but it isn't purple. Purple-blue? The original was much nicer. For good tinting, you really need a second grey+alpha image. For a reasonable job using the current image files, this might work: 1. convert stamp to L,a*,b* 2. find the average color 3. find the most saturated color with a hue within a few degrees of the average color (this will be considered the old color and hue) 4. without modification, copy over all pixels with a hue that is more than a few degrees from the old hue 5. change hue of remaining pixels 6. scale the saturation to match the new saturation 7. adjust brightness along a linear slope that is along the hue axis, such that the old color becomes the new color and a half-saturated color with the old hue will have a brightness change that is half that of a full-saturation color (as the saturation approaches zero, so does the brightness change) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] high-resolution stamps work now
On Wed, 2004-11-24 at 16:02, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > (considering a 640x480 display) > > > > 200% makes the stamp twice as wide > > 2 means that the stamp file is 2x what it should be > > 2/1 ? (didn't ask, but same as above would make sense) > > 2:1 ? (didn't ask) > > Perhaps just using a floating point number? E.g.: > > 0.4 > > The stamp should now by default be scaled to .4 its original size > when placed in a 640×480 window. I support that, but it goes the other way. While I would have done the direction you chose, our opinions are not terribly important. We know about software development. My wife, mostly a non-programmer, would use 2.5 for that. (the reciprocal -- she views the problem as her having made a stamp that is 2.5 times too large) > (In higher resolutions we may want to change the scaling so the > image stays physically the same size. E.g. for 1280×960 resolution > a stamp with width 250 would by default get rendered with width > 250*.4*1280/640 = 200 instead of 100.) I did this, but as a function of the square root. As the screen gets larger, you want two conflicting things to happen: 1. you can put more objects on the screen 2. you get more-detailed objects I split the difference. So if the object is 100x100 on a 500x300 canvas, it'll ideally be 141x141 on a 1000x600 canvas. The code will find the nearest integer ratio to this, currently 3/2, resulting in a 150x150 stamp size. > Here one can either use the old system of pushing to buttons, or > move the (stepless) slider to set the size. (One annoyance I have > with the current system is that the steps are too large, > particulary when scaling up. This would fix this.) There is a table of steps now, expressed as integer ratios. You can add 10/7, 13/10, 8/5... whatever you like. Don't hesitate to define truly insane sizes. They won't be allowed. The code requires a surface area of 20 pixels, and requires that neither dimension be over 2x the screen size in that dimension. > Unless someone objects, I'll add a feature request for this to the > SF tracker. It seems complicated. :-( ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 20:18, Bill Kendrick wrote: > One problem I noticed on my wife's laptop (with some of the new colors, > especially), was that the color selector buttons wash them out too much. > I guess I'll need to go in and change the code a bit. Enable the "low quality" color selector and you're all set. :-) Imagine that, with the colors as ellipses, on a background with a woodgrain pattern. I think it would look fairly nice. > > (This is easier said than done. One important thing to be aware > > of, is that all colours must give different tints when tinting > > stamps. We had a problem with magenta and purple before. The two > > colours looked completely different, but gave the same colour when > > tinting stamps. Some very minor modifications to the colour values > > fixed this.) > > Yeah, I was a little concerned that Albert may have affected this, > and was hoping you'd take a moment to tweak any, if needed. > > Could you do me a favor and add a note (and any tips you can think of) > regarding this in a /* comment */ inside src/colors.h? Don't bother just now. I'm partway through fixing the tinter. I have the most CPU-intensive part done already, and it's not even noticable on a 450 MHz Mac with 100 MHz memory bus. (that is, a SLOW machine by modern standards) So, yes you can afford to do full colorspace conversion with a sin(), a cos(), a sqrt(), an atan2(), and 8 calls to pow(). Well, it surprised me anyway. Math is shockingly cheap IMHO. If this works out, colors like 50,0,50 and 255,0,255 will look very different when tinted. There won't be a need to avoid having a proper purple. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] high-resolution stamps work now
On Wed, 2004-11-24 at 20:12, Bill Kendrick wrote: > On Wed, Nov 24, 2004 at 05:11:03PM -0500, Albert Cahalan wrote: > > > Unless someone objects, I'll add a feature request for this to the > > > SF tracker. > > > > It seems complicated. :-( > > On the contrary. I like the idea of a slider over the "Grow"/"Shrink" > (up-arrow/down-arrow) buttons we have now. > > Those buttons don't provide any feedback as to how big the stamp will be, > just whether or not you can make it any smaller or bigger. > (If you can't make it any bigger, you know it's the biggest... > If you can't make it any smaller, you know it's the smallest... > Otherwise, you have no idea what size it's set to.) My kid just looks at the outline. He does that as soon as he selects the stamp. He then presses the buttons and re-checks as needed to get the size right. I've been thinking that the audio could provide a hint. If you're at the limit, you just get a thump sound. If you're right before the limit, you get the regular swoop sound and then the thump. The swoop sound could change based on size. For example, there could be one octave from the minimum to the default, and another octave from there to the maximum. minimum: 200 Hz default: 400 Hz maximum: 800 Hz Sweep the appropriate fraction in 1/4 second, using a nice major chord sound. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] [PATCH] new tinter
To show off the new tinter, the enclosed patch restores
the original purple. Yellow is much, much, nicer with
this new tinter.
The one trouble is that pickup truck. It isn't anywhere
near constant hue. It varies from blue to green so much
that going plus-or-minus 25 degrees from the primary hue
is not enough. I could widen that up, but then I would
not be able to have tail lights and turn signals on a
green car remain unaffected by the tinting.
//
diff -Naurd t2/src/colors.h tx/src/colors.h
--- t2/src/colors.h 2004-11-22 20:28:45.0 -0500
+++ tx/src/colors.h 2004-11-25 00:18:52.0 -0500
@@ -52,7 +52,7 @@
{ 33, 148, 33}, /* Green */
{138, 168, 205}, /* Sky blue */
{ 0, 0, 255}, /* Blue */
- { 96, 0, 128}, /* Purple */
+ {128, 0, 128}, /* Purple */
{255, 0, 255}, /* Magenta */
{128, 96, 0}, /* Brown */
{226, 189, 166}, /* Tan */
diff -Naurd t2/src/tuxpaint.c tx/src/tuxpaint.c
--- t2/src/tuxpaint.c 2004-11-24 18:35:15.0 -0500
+++ tx/src/tuxpaint.c 2004-11-25 00:31:35.0 -0500
@@ -3009,58 +3009,266 @@
}
+//
+// stamp tinter
+
typedef struct multichan {
double r,g,b; // linear
double L,u,v; // L,a,b would be better -- 2-way formula unknown
double hue,sat;
- unsigned char or,og,ob,oa; // old 8-bit sRGB values
- unsigned char nr,ng,nb,na; // new 8-bit sRGB values
+ unsigned char or,og,ob; // old 8-bit sRGB values
+ unsigned char nr,ng,nb; // new 8-bit sRGB values
+ unsigned char alpha;// 8-bit alpha value
} multichan;
+#define X0 ((double)0.9505)
+#define Y0 ((double)1.)
+#define Z0 ((double)1.0890)
+#define u0_prime ( (4.0 * X0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+#define v0_prime ( (9.0 * Y0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+
+static void fill_multichan(multichan *mc)
+{
+ double tmp,X,Y,Z;
+ double u_prime, v_prime; /* temp, part of official formula */
+ double Y_norm, fract; /* severely temp */
+
+ // from 8-bit sRGB to linear RGB
+ tmp = mc->or / 255.0;
+ mc->r = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc->og / 255.0;
+ mc->g = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc->ob / 255.0;
+ mc->b = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+
+ // coordinate change, RGB --> XYZ
+ X = 0.4124*mc->r + 0.3576*mc->g + 0.1805*mc->b;
+ Y = 0.2126*mc->r + 0.7152*mc->g + 0.0722*mc->b;
+ Z = 0.0193*mc->r + 0.1192*mc->g + 0.9505*mc->b;
+
+ // XYZ --> Luv
+ Y_norm = Y/Y0;
+ fract = 1.0 / (X + 15.0*Y + 3.0*Z);
+ u_prime = 4.0*X*fract;
+ v_prime = 9.0*Y*fract;
+ mc->L = (Y_norm>0.008856) ? 116.0*pow(Y_norm,1.0/3.0)-16.0 : 903.3*Y_norm;
+ mc->u = 13.0*mc->L*(u_prime - u0_prime);
+ mc->v = 13.0*mc->L*(v_prime - v0_prime);
+
+ mc->sat = sqrt(mc->u*mc->u + mc->v*mc->v);
+ mc->hue = atan2(mc->u,mc->v);
+}
+
static void tint_surface(SDL_Surface * tmp_surf, SDL_Surface * surf_ptr)
{
+ unsigned i;
+ int xx, yy;
- float col_hue, col_sat, col_val,
-stamp_hue, stamp_sat, stamp_val;
+ unsigned width = surf_ptr->w;
+ unsigned height = surf_ptr->h;
- Uint8 r, g, b, a;
-int xx, yy;
+ multichan *work = malloc(sizeof *work * width * height);
- rgbtohsv(color_hexes[cur_color][0],
- color_hexes[cur_color][1],
- color_hexes[cur_color][2],
- &col_hue, &col_sat, &col_val);
-
+ // put pixels into a more tolerable form
+ SDL_LockSurface(surf_ptr);
+ for (yy = 0; yy < surf_ptr->h; yy++)
+{
+ for (xx = 0; xx < surf_ptr->w; xx++)
+{
+ multichan *mc = work+yy*width+xx;
+ SDL_GetRGBA(getpixel(surf_ptr, xx, yy),
+ surf_ptr->format,
+ &mc->or, &mc->og, &mc->ob, &mc->alpha);
+}
+}
+ SDL_UnlockSurface(surf_ptr);
- /* Render the stamp: */
+ i = width * height;
+ while (i--)
+{
+ multichan *mc = work+i;
+ fill_multichan(mc);
+}
- SDL_LockSurface(surf_ptr);
- SDL_LockSurface(tmp_surf);
+ // initial hue guess
+ double alpha_total = 0;
+ double u_total = 0;
+ double v_total = 0;
+ i = width * height;
+ while (i--)
+{
+ multichan *mc = work+i;
+ alpha_total += mc->alpha;
+ // more weight to opaque high-saturation pixels
+ u_total += mc->alpha * mc->u * mc->sat;
+ v_total += mc->alpha * mc->v * mc->sat;
+}
+ double initial_hue = atan2(u_total,v_total);
- for (yy = 0; yy < surf_ptr->h; yy++)
- {
- for (xx = 0; xx < surf_ptr->w; xx++)
- {
- SDL_GetRGBA(getpixel(surf_ptr, xx, yy),
- surf_ptr->format,
- &r, &g, &b, &a);
-
- rgbtohsv(r, g, b, &stamp_hue, &stamp_sat, &stamp_val);
-
- if ( stamp_tintgray(cur_stamp) || stamp_sat > 0.25 )
- hsvtorgb(col_hue, col_sat, stamp_val, &r, &g, &b);
-
Re: [Tuxpaint-dev] high-resolution stamps work now
On Thu, 2004-11-25 at 01:14, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in > > I split the difference. So if the object is 100x100 on a > > 500x300 canvas, it'll ideally be 141x141 on a 1000x600 > > canvas. The code will find the nearest integer ratio to > > this, currently 3/2, resulting in a 150x150 stamp size. > > I'm not sure I like this. If we have several stamps (e.g. the > fruit stamps) they should scale by the *same* amount, not by an > integer ratio. If I have understood things correctly, your code > means that an apple may look larger than a banana when scaled. That's not changed. With simplified names, the code now works like this: scale = global_scale_factor * stamp_scale_factor; Normally, stamp_scale_factor is 1. You can change it via the scale option in a *.dat file. The global_scale_factor is set based on screen size. If the canvas is 4 times as wide as the original one that Tux Paint started with, you'll get a 2. From a 9 (huge!!!) you'd get a 3. From 2, you get 1.414... Prior to use, the scale factor is rounded off to the nearest available step. So 1.414 gives 1.5 currently. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] new tinter
On Thu, 2004-11-25 at 00:49, Albert Cahalan wrote: > To show off the new tinter, the enclosed patch restores > the original purple. Yellow is much, much, nicer with > this new tinter. So... anybody try it? Any objections? Good? Bad? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] high-resolution stamps work now
On Thu, 2004-11-25 at 14:59, Karl Ove Hufthammer wrote: > The outlines shown when placing a stamp doesn't work as well as > before (both for unscaled and scaled stamps). I've noticed. Rather than fixing it, I think the outline code should be redone. As noted by a #define option, the current code is slow. It also screws up on rectangles with certain (odd? even?) sizes, leaving off one edge. So the new problem is just one more reason to redo this code. > And one of the higher scale factors doesn't give very smooth > edges. You can see it on both the new tyre stamp and the updated > grapes stamp. The tyre looks round and smooth with one scale > factor, not with the next, but *with* the one after that one. > > I of course know that doubling and quadrupling the size will get > better result than arbitrary scaling, but my image program does > seem to be able to handle the intermediate steps well, while Tux > Paint does not. Something wrong with SDL's rescaling algorithm? SDL isn't used for this. The thumbnail generator was modified to do general stamp resizing. The algorithm is really, really, simple. It simply grabs a square of pixels from the source, averages them, and then fills in a square of pixels for the destination. If linking against libfftw2 is OK, really nice arbitrary scaling would be easy. (take FFT, truncate or zero-pad, inverse FFT) Otherwise, maybe something like lanczos3. My notes on this: --- accurate and slow: FFT/Chirp-z http://www.worldserver.com/turk/computergraphics/ResamplingFilters.pdf google for: fft image interpolation http://www.mplayerhq.hu/DOCS/tech/swscaler_methods.txt http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html lanczos3 --- ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] new tinter
On Thu, 2004-11-25 at 14:50, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > On Thu, 2004-11-25 at 00:49, Albert Cahalan wrote:
> >> To show off the new tinter, the enclosed patch restores
> >> the original purple. Yellow is much, much, nicer with this
> >> new tinter.
> >
> > So... anybody try it? Any objections? Good? Bad?
>
> I got an error message while trying to apply it for tuxpaint.c.
> Could you try resending it, now as a an attachment (line-breaking
> in e-mail programs easily mangles patches) and diffed against
> latest CVS version?
Don't cut-and-paste. Save the email, then run the whole
thing through patch. If you still get an error, check to
be sure that some lame "helpful" mail gateway hasn't
decided to "prevent damage" by using printed-quotable
MIME encoding. Never use such evil mail gateways.
Remember:
cd root-of-tuxpaint-source
patch -s -E -p1 < path-to-this-email
Use the --dry-run option if you want to check first.
> But I have one comment. As far as I can see, you have completely
> removed the notintgray feature. We do really *not* want to try to
> be clever and (by default) only render parts of a stamp which has
> the same hue. This has lead to problems in the past.
>
> (But if a stamp require not tinting 'grey' parts, the 'notintgray'
> option should still be available.)
If there are problems, I'll deal with them.
I don't special-case grey. Tinting grey is a no-op.
I can change the hue, but that means nothing. Here's
what happens to it:
double u = sat * sin(mc->hue);
double v = sat * cos(mc->hue);
double L = mc->L;
As you may guess, "sat" is the saturation, which will be 0.0
for grey. So the hue doesn't matter. Both u and v become 0.0.
I'll try again with a patch in the body. This needs to work.
Attachments are hard to quote in email responses. Speaking
of which, this mailing list makes my "reply" and "group reply"
buttons to the same thing, limiting my communication choices.
-- the patch -
diff -Naurd t2/src/colors.h tx/src/colors.h
--- t2/src/colors.h 2004-11-22 20:28:45.0 -0500
+++ tx/src/colors.h 2004-11-25 00:18:52.0 -0500
@@ -52,7 +52,7 @@
{ 33, 148, 33}, /* Green */
{138, 168, 205}, /* Sky blue */
{ 0, 0, 255}, /* Blue */
- { 96, 0, 128}, /* Purple */
+ {128, 0, 128}, /* Purple */
{255, 0, 255}, /* Magenta */
{128, 96, 0}, /* Brown */
{226, 189, 166}, /* Tan */
diff -Naurd t2/src/tuxpaint.c tx/src/tuxpaint.c
--- t2/src/tuxpaint.c 2004-11-24 18:35:15.0 -0500
+++ tx/src/tuxpaint.c 2004-11-25 00:31:35.0 -0500
@@ -3009,58 +3009,266 @@
}
+//
+// stamp tinter
+
typedef struct multichan {
double r,g,b; // linear
double L,u,v; // L,a,b would be better -- 2-way formula unknown
double hue,sat;
- unsigned char or,og,ob,oa; // old 8-bit sRGB values
- unsigned char nr,ng,nb,na; // new 8-bit sRGB values
+ unsigned char or,og,ob; // old 8-bit sRGB values
+ unsigned char nr,ng,nb; // new 8-bit sRGB values
+ unsigned char alpha;// 8-bit alpha value
} multichan;
+#define X0 ((double)0.9505)
+#define Y0 ((double)1.)
+#define Z0 ((double)1.0890)
+#define u0_prime ( (4.0 * X0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+#define v0_prime ( (9.0 * Y0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+
+static void fill_multichan(multichan *mc)
+{
+ double tmp,X,Y,Z;
+ double u_prime, v_prime; /* temp, part of official formula */
+ double Y_norm, fract; /* severely temp */
+
+ // from 8-bit sRGB to linear RGB
+ tmp = mc->or / 255.0;
+ mc->r = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc->og / 255.0;
+ mc->g = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc->ob / 255.0;
+ mc->b = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+
+ // coordinate change, RGB --> XYZ
+ X = 0.4124*mc->r + 0.3576*mc->g + 0.1805*mc->b;
+ Y = 0.2126*mc->r + 0.7152*mc->g + 0.0722*mc->b;
+ Z = 0.0193*mc->r + 0.1192*mc->g + 0.9505*mc->b;
+
+ // XYZ --> Luv
+ Y_norm = Y/Y0;
+ fract = 1.0 / (X + 15.0*Y + 3.0*Z);
+ u_prime = 4.0*X*fract;
+ v_prime = 9.0*Y*fract;
+ mc->L = (Y_norm>0.008856) ? 116.0*pow(Y_norm,1.0/3.0)-16.0 : 903.3*Y_norm;
+ mc->u = 13.0*mc->L*(u_prime - u0_prime);
+ mc->v = 13.0*mc->L*(v_prime - v0_prime);
+
+ mc->sat = sqrt(mc->u*mc->u + mc->v*mc->v);
+ mc->hue = atan2(mc->u,mc->v);
+}
+
static void tint_surface(SDL_Surface * tmp_surf, SDL_Surface * surf_ptr)
{
+ unsigned i;
+ int xx, yy;
- float col_hue, col_sat, col_val,
-stamp_hue, stamp_sat, stamp_val;
+ unsigned width = surf_ptr->
Re: [Tuxpaint-dev] Tux Paint 0.9.14 in LockerGnome
On Thu, 2004-11-25 at 15:58, Bill Kendrick wrote: > Cool, check it out! ;) They claim Tux Paint requires Win98/2k/XP. They only provide a link to a Microsoft Windows installer. They don't even mention the Mac port, much less the Linux port or anything weird. This is not helping. :-( ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tux Paint 0.9.14 in LockerGnome
On Thu, 2004-11-25 at 16:08, Bill Kendrick wrote: > On Thu, Nov 25, 2004 at 03:52:27PM -0500, Albert Cahalan wrote: > > On Thu, 2004-11-25 at 15:58, Bill Kendrick wrote: > > > Cool, check it out! ;) > > > > They claim Tux Paint requires Win98/2k/XP. They only > > provide a link to a Microsoft Windows installer. > > They don't even mention the Mac port, much less the > > Linux port or anything weird. > > Well, admittedly, it /was/ in their "Windows" section. > It also came via a Windows freeware/shareware site that I submitted to. > > > This is nothing compared to the utter frustration that TUCOWS has been. > An ancient version of Tux Paint for Linux is listed in their Linux section. > No version is in their Mac section. No version is in their Windows section. > I submitted 0.9.14 to their BeOS section and it was up within a few days. I can't tell if it does, but the Windows installer could mention that Tux Paint is available for less-infested OSes. Computer labs without porno pop-up windows are possible. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] new tinter
On Thu, 2004-11-25 at 15:46, Albert Cahalan wrote: > On Thu, 2004-11-25 at 14:50, Karl Ove Hufthammer wrote: > > I got an error message while trying to apply it for tuxpaint.c. > > Could you try resending it, now as a an attachment (line-breaking > > in e-mail programs easily mangles patches) and diffed against > > latest CVS version? > > Don't cut-and-paste. Save the email, then run the whole > thing through patch. If you still get an error, check to > be sure that some lame "helpful" mail gateway hasn't > decided to "prevent damage" by using printed-quotable > MIME encoding. Never use such evil mail gateways. > > Remember: > > cd root-of-tuxpaint-source > patch -s -E -p1 < path-to-this-email > > Use the --dry-run option if you want to check first. The patch came back to me OK. It applies without complaint. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] reentrancy, thread-safety, etc.
Consider the code for drawing a stamp outline, and the code for responding to a stamp control button press. Can those run at the same time? Can one preempt the other one? I'd like to have the stamp controls set up a bitmap for the stamp outline renderer. I need to know if I must use an SDL surface with locking, or if I can use something simpler and faster. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, 2004-11-26 at 17:31, Bill Kendrick wrote: > On Fri, Nov 26, 2004 at 11:24:37AM -0500, Albert Cahalan wrote: > > I'd like to have the stamp controls set up a bitmap for > > the stamp outline renderer. I need to know if I must use > > an SDL surface with locking, or if I can use something > > simpler and faster. > > If what you do interrupts the event loop (as most things do, like saving, > loading, etc.), then if I understand things right (which I admittedly may > not ;^) ), you can probably do it your 'faster' way. > > Though I'm curious, what would that be? > > > Also, you don't happen to be considering alpha-blended stamps under the > mouse before placement...? :) I didn't think of that. It has a bit of a downside though. The outline might be easier to see. I did think of filling in the outline though. I was just preparing to cache the stamp outline. When the stamp changes (new choice, flip, mirror, or scaling), the outline needs to be recomputed. There's no need to be computing it every time the mouse moves a tiny bit. The code in CVS is prepared for this now. Notice that update_stamp_xor has been split out of stamp_xor. Now there are two reasonable options: a. check for stamp changes in update_stamp_xor, and return early (without computation) if no changes b. move the update_stamp_xor call from stamp_xor to the code (flip button, etc.) that causes the stamp outline to need replacement If this works out well, maybe the low-quality stamp outline code will be pointless to keep. BTW, there's a bit of a problem with flicker. I suppose the solution might involve a canvas-sized bitmap for the outline. Then there would never be a need to clear the old outline prior to painting the new one; the clearing and painting would take place in one operation. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, 2004-11-26 at 18:52, Bill Kendrick wrote: > On Fri, Nov 26, 2004 at 06:30:21PM -0500, Albert Cahalan wrote: > > I was just preparing to cache the stamp outline. When the > > stamp changes (new choice, flip, mirror, or scaling), the > > outline needs to be recomputed. There's no need to be > > computing it every time the mouse moves a tiny bit. > > Yes, I've noticed that. :^) On my 450MHz Celeron, the recomputation > takes up QUITE a bit of time. So much so that if I move the mouse > quickly enough, the event handler seems to loose the last few > positions. We may be having a contest for slowest computer. I have a 450 MHz Mac with PC100 memory. Unlike your computer, mine is pushing 32-bit video to a 1600x1024 display, uphill both ways. :-) I have nothing fancier than a bit of basic 2-D acceleration. > This causes the outline to stay where it was, while the "+" mouse > pointer > has moved a few inches away. If I click to place the stamp, of course > (part of) the old outline remains. :^( This is a serious bug. Stamp outline performance improvements will not fix the root cause of this bug; they'll just make the bug harder to reproduce. > > The code in CVS is prepared for this now. Notice that > > update_stamp_xor has been split out of stamp_xor. Now > > there are two reasonable options: > > I tried simply moving the 'update_stamp_xor()' call to whenever the > stamp shape changes (mousewheel rolls or user specifically clicks a > stamp > button on the right). Mousewheel? That doesn't change the stamp AFAIK. Changes would be: 1. startup (very important!) 2. click on new stamp 3. mirror 4. flip 5. scale up 6. scale down Tinting changes the stamp too, but it won't matter for this. > > If this works out well, maybe the low-quality stamp > > outline code will be pointless to keep. > > I notice that's "gone" all of a sudden. ;^) What, "I didn't do it, and nobody saw me." ? > > BTW, there's a bit of a problem with flicker. I suppose > > the solution might involve a canvas-sized bitmap for the > > outline. Then there would never be a need to clear the > > old outline prior to painting the new one; the clearing > > and painting would take place in one operation. > > What's flickering, exactly? flickering == flashing, going on and off, producing an annoying sensation of variable brightness... You don't see it? As a stamp is moved before placement, the outline refresh is visible. I see the outline go and then come back in the new location. This is not good. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 2004-11-26 at 18:54, Bill Kendrick wrote: > Tinting in CVS is a bit broken right now, and VERY slow (on my 450MHz Celeron, > at least). > > Best example is the cartoon butterfly. It doesn't change color (it's always > orange), and takes about 2 seconds between my clicking, and it appearing > on the canvas. > > Ideas? :) > > (This is with the latest CVS for both stamps and code) First of all, the butterfly is looking better than ever for me. It tints perfectly. I'll send you an example. I'd have expected your PC to be very fast at this, because the PC has built-in trancedental math functions in the CPU. You have instructions for sin(), cos(), tan(), and so on. Unlikely to be the problem, but... One thing that may need to change for a PC is the place where a double is compared against zero. Instead of this: if(dst.sat>0) You might be better off with: if(dst.sat>0.0001) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
This may have something to do with the performance: gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-3) This compiler does alias analysis and whole-file optimization. If that does the job for you, then don't worry. Most users will be getting binaries compiled with gcc 3.4 or later. For the Windows build, ensure that the fast math options are enabled. (using the x86 transcedental math instructions) If alias analysis is an option, enable that too. There are plenty of opportunities for hand-optimizing the code if compiler adjustments don't do the job. I didn't bother, because a bone-headed implementation was easier to develop and plenty fast on my system. Some ideas are: a. reduce the size of the multichan struct b. re-use original sRGB data for unmodified pixels c. use a look-up table for sRGB to L,u,v d. [painful and inaccurate] interpolate for L,u,v to sRGB It would be great if you could run a line-by-line profiler on the code to see where the time is going. Try using oprofile and kcachegrind to find where cache misses happen. (this is where the --playback option would be great) Windows profiler output might be helpful too. Surely there are some suitable tools... maybe Intel provides some? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 2004-11-26 at 21:23, Mark K. Kim wrote: > On Fri, 26 Nov 2004, Albert Cahalan wrote: > > > One thing that may need to change for a PC is the place where > > a double is compared against zero. Instead of this: > > > > if(dst.sat>0) > > > > You might be better off with: > > > > if(dst.sat>0.0001) > > How does that offer performance increase??? Generally, it doesn't. It's a matter of accuracy in being able to determine if the destination color is greyscale. This is just a possible bug that popped into my head while thinking about the code, nothing more. (a Mac handles this well, but a PC has a variable number of fraction bits because of the truncation that occurs when an 80-bit float is spilled to a 64-bit stack location) There could be a place where something like the above would send the code around for a loop though. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] code simplification
Now that Tux Paint is in 24-bit mode, I wonder what happens if you have a 16-bit display and you remove these lines from getpixel() and putpixel(). else if (bpp == 2) *(Uint16 *)p = pixel; else if (bpp == 2)/* 16-bit display */ pixel = *(Uint16 *)p; I also wonder what happens if SDL_MapRGB becomes a macro that ignores bit depth. Does it work OK? BTW, it would be nice if getpixel() would simply grab the nearest pixel when the dimensions are out of bounds. This would be great for a smudge tool. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] need to document stamp creation workflow
I can't find good step-by-step documentation for creating the right kind of images. Presumably the gimp is a part of this, for lack of a decent tool. Well, here's a start, gripes included. Some things I've stumbled across while suffering: You need to start with a good image. You want it big, generally a side view, and free to use. Don't worry about minor obstructions like wires; they can be removed with the clone tool and smudge tool. One might as well start with this. The clone tool is useless until you do control-click to start it. This would also be a good time to remove color casts with the curves tool. Use the jpegtran program if you will be making a greyscale stamp from a color JPEG, since it preserves data better than the GIMP. Ideally, one would do rotation last. This does not work well though, because a gimp bug will destory parts of an RGBA image. (learned the painful way) Gimp has three notions of what we might call alpha. 1. the selection, which is a hidden 8-bit channel (not a binary channel). 2. the layer mask 3. the alpha channel No reason is given for why the layer mask and alpha channel both exist. You can have both. You can, very awkwardly, convert one into the other. Many operations will only work on one. You can also convert either of these to or from the selection. Then there's quickmask mode, enabled by a button on the lower left of an image. It lets you paint the selection as a red haze over the image. Woe to you if your image looks like a red haze. Since the selection can be (awkwardly) converted to an alpha channel or layer mask, quickmask mode can be used to rough out the needed alpha channel. The basic problem when dealing with alpha is that you can't see it. The GIMP does not provide a good way to handle this problem. Ideally, one could drag-and-drop arbitrary channels and layers and images all over into each other, and could have many differently composited views all with mouse pointers and simultaneous updates. One can toggle layer visibility to flip between a layer with the image and one with the future alpha channel. With an actual alpha channel, you can't do anything. With the data as a layer mask, you can use an awkward and error-prone feature to choose what you see and what you draw on: use control-click and shift-click on the layer mask and/or layer (two side-by-side icons in the layers dialog) to muck with this. You can thus draw on the image while seeing the alpha channel, or draw on the alpha channel while seeing the image. Most likely you will, unintentionally and repeatedly. Away from your stamp object, you have some dead space on the drawing canvas. Fill this with a solid color to get better compression. Near the edge of your stamp object you will need to do some tedious pixel-by-pixel painting. Most image sources have JPEG artifacts that mess up the border. You'll need to color over these. Use the color picker and pencil, or use the clone tool. Extend the border of the image outward by many pixels to ensure that undesired colors don't leak into the image later as it is scaled, rotated, and so on. Be careful to ensure that the solid colors of your alpha channel (layer mask, whatever) and background are really solid colors. To do this, first select the region by color. Then, invert the selection. Now zoom in at least 4x and look for the moving selection ants. Color over them with the pencil tool set to full opacity. Redo the selection to check if you are done. When saving the image, be sure that you do not have a floating layer. (a cut-and-paste result for example) A gimp bug will mess up the output file if you forget. Avoid rotation entirely if you can. The GIMP operates without concern for gamma. Images can become noticably darker near light-dark transitions, including any areas with high noise. Thin features like antennas need special treatment. Paint over them with a broad brush, using what you imagine to be the oringinal color. (the original color is almost entirely lost to JPEG compression) The original image can sometimes be used as the alpha channel; use of the curves tool on a selection will be required to get the right contrast. For thin features that are nearly horizontal or vertical, complete replacement is required to avoid aliasing. (It's best to locate vertical antennas at locations p*n+x where p is a power of two, n is a per-antenna value, and x is a value shared by all antennas. This ensures that the antennas are all equally blurry or sharp when the image is scaled to common sizes.) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] UK govt copyright?
Do UK government works fall into the public domain or what? Copyright to the queen or something? In other words, are they free to use? (any other non-US info?) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] stamp production tool
Here's a little tool I just made for creating alpha channels.
It should be useful whenever you have a simple background.
1. save the original as a binary *.ppm file
2. save another copy, with the foreground painted away
3. save another copy, with the background painted away
4. run the tool to create an alpha image
Now you have a rough alpha image. Edit it as needed to
make the opaque parts fully white and the transparent
parts fully black. To avoid background color fringes on
the finished stamp, use the tool again. Feed it all 4
images you have, and you'll get back a new foreground
image that doesn't have any background mixed with it.
Note: the crazy colors are somewhat OK; they come from
the effectively limited bit depth of foreground objects
in semi-transparent areas being expanded to a full 8 bits.
Things should work out OK when the image is used.
A possible enhancement might be to blur the images in
proportion to transparency. This would reduce noise.
BTW, the alpha image is not a true *.pgm file. It's linear.
The *.ppm files all use the sRGB color space.
/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static unsigned width, height;
#define TYPE_PGM '5'
#define TYPE_PPM '6'
//
// quick hack reader for binary P*M files
static unsigned char *readpnm(const char *name, int desired){
int fd = open(name, O_RDONLY);
char *cp;
int type;
struct stat sbuf;
fstat(fd, &sbuf);
cp = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, fd, 0);
close(fd);
if(cp[0] != 'P') exit(7);
type = cp[1];
if(type != TYPE_PGM && type != TYPE_PPM) exit(56);
cp += 2;
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
width = strtoul(cp, &cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
height = strtoul(cp, &cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
if(strtoul(cp, &cp, 10)!=255) exit(33);
cp++;
if(type==desired)
return cp;
if(type==TYPE_PGM){
// desired must have been 6 (color), but we want 5
// let'd pick the red channel
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
data[i] = cp[i*3];
}
return data;
}
if(type==TYPE_PPM){
// desired must have been 5 (greyscale), but we want 6
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
unsigned char tmp = cp[i];
data[i*3+0] = tmp;
data[i*3+1] = tmp;
data[i*3+2] = tmp;
}
return data;
}
exit(93);
}
// project 1st vector onto 2nd vector, then divide by 2nd magnitude
static double vdist(double x, double y, double z, double x2, double y2, double
z2){
double dot= x *x2 + y *y2 + z *z2; // the dot product
double magsquared = x2*x2 + y2*y2 + z2*z2; // the magnitude, squared
return dot / magsquared;
}
///
// passed original, foreground, and background images, return an alpha channel
static unsigned char *mkalpha(const unsigned char *o, const unsigned char *f,
const unsigned char *b){
unsigned char *ret = malloc(width*height);
unsigned i = width*height;
while(i--){
unsigned char or = o[i*3+0];
unsigned char og = o[i*3+1];
unsigned char ob = o[i*3+2];
unsigned char fr = f[i*3+0];
unsigned char fg = f[i*3+1];
unsigned char fb = f[i*3+2];
unsigned char br = b[i*3+0];
unsigned char bg = b[i*3+1];
unsigned char bb = b[i*3+2];
if(fr==br && fg==bg && fb==bb){
// foreground and background are same color... uh oh
ret[i] = 128; // a random value :-(
continue;
}
if(or==br && og==bg && ob==bb){
// original and background are same color: alpha is 0
ret[i] = 0;
continue;
}
if(fr==or && fg==og && fb==ob){
// foreground and original are same color: alpha is 1.0 or 255
ret[i] = 255;
continue;
}
double tmp;
// convert from sRGB to linear (gamma==1.0) RGB
tmp = or / 255.0; double oR = (tmp<=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = og / 255.0; double oG = (tmp<=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = ob / 255.0; double oB = (tmp<=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = fr / 255.0; double fR = (tmp<=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = fg / 255.0; double fG = (tmp<=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = fb / 255.0; double fB = (tmp<=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tm
[Tuxpaint-dev] memory usage
I don't know where it's all going, but --nostamps reduces memory usage by 75%. I'm at about 60 MB. Plan? Things that I think should be kept in memory: a. sounds for all stamps visible in the selector b. image data for the active stamp c. icons for all stamps visible in the selector d. icons for next-to-visible stamps So when you scroll down, Tux Paint should load: a. sounds for the two stamps just made visible b. icons for the two stamps beyond that The load_arbitrary function is lots of trouble. It kind of enforces everything to be kept in memory. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] color selector
Aside from the *.jpg compression damage, how's this? <>___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] memory usage
On Thu, 2004-12-02 at 20:49, Bill Kendrick wrote: > I think it's fine to keep 'everything' in memory, but to continue with > my original plan on managing just WHAT 'everything' is. > > In other words... split up the stamps into collections of 10-20 each, > rather than load all 200 up at once. There's still no UI for that AFAIK, and I'm not sure that one will be found without abandoning the target audience. Navigating a tree structure, even a 2-level one, is much more complex than simply using the scroll wheel. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] color selector
On Thu, 2004-12-02 at 20:54, Bill Kendrick wrote: > On Thu, Dec 02, 2004 at 07:59:13PM -0500, Albert Cahalan wrote: > > Aside from the *.jpg compression damage, how's this? > > > > That's not too bad. I think I'd prefer the palette colors to > still be shaped more similar to the other buttons, though. > And it'd be nice if we could have SOME slight 3D or glass effect on the > colors. Hrmm.. How about _around_ the colors instead? That could make the colors look sunken in, like watercolor paint wells. > Also, related to this last one, a recent article I read on GUI usability > mentioned that greyed out items are bad, esp. nowadays when there are so > many items in pulldown menus in huge applications like MS Office. Yes, but the alternatives are far worse. :-) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] sound needed
The new smudge tool needs a suitable sound. It also needs an image. (using the blur one now) The tool is lots of fun. It gives the feel of fingerpainting with the image. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Thu, 2004-12-09 at 20:48, Bill Kendrick wrote: > Albert put this into CVS just now: > > Modified Files: > tuxpaint.c > Log Message: > narrowed down the massive starter bug to load_starter, maybe involving > SDL_CreateRGBSurface or SDL_SetAlpha > > > Martin, can you pull the latest from CVS and see if this helps fix the > starter bug? That won't, but 1 or 2 commits later should do the job. SDL_BlitSurface does not copy alpha. This caused the alpha to get lost when adjusting starters for a different screen size. There is simply nothing in SDL that will do the job. I wrote NondefectiveBlit as a correct, but horribly slow, replacement for SDL_BlitSurface. I really dislike starters through and through. Besides making the code slower and harder to understand, they complicate the user interface. Starters appear as saved files in the dialog for loading an image, but they are not saved images in any way. As they presumably increase in number, they will crowd the image load dialog. The interactions with "magic" are gross too, with the tools being unable to distinguish the starter from the user's work. Try a flood-fill on the San Francisco skyline, w! Also note the funny effects when drawing around the edge of that palm tree. I think it could be confusing when parts of the image are not drawable. So... how about scraping at least some of this? The foreground part is the worst. I can imagine backgrounds, perhaps even tilable ones, being almost worth the trouble if they appeared in a dialog for new images instead of in the dialog for loading files. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Thu, 2004-12-09 at 23:21, Martin Fuhrer wrote: > On 9-Dec-04, at 7:13 PM, Albert Cahalan wrote: > > > On Thu, 2004-12-09 at 20:48, Bill Kendrick wrote: > >> Albert put this into CVS just now: > >> > >> Modified Files: > >>tuxpaint.c > >> Log Message: > >> narrowed down the massive starter bug to load_starter, maybe > >> involving SDL_CreateRGBSurface or SDL_SetAlpha > >> > >> > >> Martin, can you pull the latest from CVS and see if this helps fix the > >> starter bug? > > > > That won't, but 1 or 2 commits later should do the job. > > I'll keep my eye out on this thread and recompile once the commits are > in. Keep me posted! I meant commits that were done. So, at the time of that email, the problem of starters being totally broken should be gone. There were two problems. First, a /usr/local path was in the code. This was no good if you installed elsewhere. Second, when working with a large screen, the foreground alpha channel got lost. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Fri, 2004-12-10 at 04:03, Bill Kendrick wrote: > I'm using Tux Paint from today's CVS (Dec. 9th), and it seems to be > crashing whenever I go to place a tintable stamp (e.g., one of the > cars, the butterfly, etc.) > > I don't have time to debug it just yet. Albert, can you take a looksee? > > I'm using Debian Testing and X/SDL/etc. that comes with it. > My display is 16bpp, if it matters. ;) It's not crashing here. Type of crash? (SIGKILL, SIGFPE, SIGSEGV, SIGBUS...) Going into 16bpp is not easy for me, as it's a kernel setting that requires /etc/yaboot.conf (like lilo.conf or grub.conf) changes and a reboot. I also have: big-endian default unsigned char a sane FPU ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Fri, 2004-12-10 at 13:52, Martin Fuhrer wrote: > > > > I meant commits that were done. So, at the time of that email, > > the problem of starters being totally broken should be gone. > > Thanks Albert, the problem is fixed under Mac OS X. There is still a > bit of a glitch in 800x600 mode, however: > http://pages.cpsc.ucalgary.ca/~fuhrer/tuxpaint/tuxpaint800x600.jpg > > Note that the left and right edges of the picture are smudged. This > does not happen in 640x480 mode. That's somewhat intentional. It makes more sense for typical kid drawings. Probably there should be a flag to choose an alternate way of handling things. The 800x600 display has a different-shaped canvas. Rather than filling with white or screwing up the aspect ratio, I smeared the edges. Again, it makes more sense with typical kid drawings. Consider a drawing with green grass, a blue sky, and a house. I first scale the image to be as large as possible without messing up the aspect ratio or being too big. That usually leaves space on the sides, but could leave space at the top and bottom. Then I smear to fill. The sky gets wider, the grass gets wider, and the house grows proportionally. There are fancier ways to do this, involving one or more of: a. wavelets b. vectors (like hq4x scaling, but to extrapolate outward) c. markov modeling Some of these can properly extend a lawn with dandilions! In the reef example, new coral would be generated. If you have trouble believing this, try the resynthesize plug-in for the gimp. If you know the math and can make it run in no more than a few seconds, go right ahead. :-) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Fri, 2004-12-10 at 15:52, Ben Armstrong wrote: > On Fri, 2004-12-10 at 14:57 -0500, Albert Cahalan wrote: > > The 800x600 display has a different-shaped canvas. Rather than > > filling with white or screwing up the aspect ratio, I smeared > > the edges. > > Maybe the simpler solution is to change the layout of 800x600 mode so > that the canvas isn't a different shape? I'd agree if monitor shapes weren't changing. I have fixed-resolution 1600x1024. For development, I like to use a 640x768 window. None of the new Macs come with the old 4:3 ratio. The standard canvas shape would look very silly on my screen. There would be lots of dead space, or a very different layout for the buttons. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Fri, 2004-12-10 at 16:14, Ben Armstrong wrote: > On Fri, 2004-12-10 at 15:46 -0500, Albert Cahalan wrote: > > I'd agree if monitor shapes weren't changing. > > > > I have fixed-resolution 1600x1024. For development, I like > > to use a 640x768 window. None of the new Macs come with the > > old 4:3 ratio. > > > > The standard canvas shape would look very silly on my screen. > > There would be lots of dead space, or a very different layout > > for the buttons. > > But at the moment there are only two supported Tux Paint geometries, > 640x480 and 800x600, aren't there? Or have things changed since I last > looked? There's 1 fully working geometry, a number of slightly-tested ones, and a near-infinite number of allowed geometries. Try them all! > It seems to me that Tux Paint was designed to be inflexible in terms of > window layout to keep things simple. If we want to make it flexible in > light of changing monitor aspect ratios (i.e. support arbitrary > geometries) then we had better solve that problem first, and *then* > solve the starters images problems that will ensue (perhaps by a > setting, as you have suggested, or by allowing the user to decide how > the image is to be imported -- stretch, smear, scale up to most > constrained dimension & then crop) per image (or if not the user, the > administrator by specifying in the .txt file). Also, isn't this a > problem for imports in general, not just starters? I set out to improve the general problem of loading mis-matched images. Dealing with starters was undesired and unavoidable. My goal was to nicely handle images like these: http://www.newbreedsoftware.com/tuxpaint/gallery/tali/Dolphin.png http://www.newbreedsoftware.com/tuxpaint/gallery/pescara/classeprimab6.png http://www.newbreedsoftware.com/tuxpaint/gallery/ashlyn/20030503171534.png http://www.newbreedsoftware.com/tuxpaint/gallery/ashlyn/20030428165845.png With a bit of touch-up, this works too: http://www.newbreedsoftware.com/tuxpaint/gallery/billkendrick/20031223034753.png ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Fri, 2004-12-10 at 20:05, Bill Kendrick wrote: > On Fri, Dec 10, 2004 at 11:52:05AM -0700, Martin Fuhrer wrote: > > > > > >I meant commits that were done. So, at the time of that email, > > >the problem of starters being totally broken should be gone. > > > > Thanks Albert, the problem is fixed under Mac OS X. > > Awesome! > > Can we 'backport' the fix to Tux Paint 0.9.14 and release a Mac OS X > version? I'd rather do that, then wait until 0.9.15 is settled, > since so many Mac users have been asking me where the new Tux Paint is, > and the latest out there is still 0.9.12! :^) I suppose. There were two fixes. First, I got rid of the explicit /usr/local path. Second, I added the new blit function, NondefectiveBlit, and used it. Are things really too unstable for a 0.9.15 release? You could just disable starter support for MacOS X. Heck, you could do that for Linux and Windows too. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] New Magic tools
On Sat, 2004-12-11 at 08:29, Bill Kendrick wrote: > I've created three new Magic tools tonight: > > Darken - Opposite of Fade It seems to me that "darken" should be the opposite of "lighten", and "fade" should change only saturation. > Cartoon - (Still needs work) Makes the image look like a cartoon (vs. real) That's a weird one. I was thinking of doing this as a whole-image operation. It's kind of pointlessly destructive as a concept though. In any case, my idea for an algorithm: 1. do an edge detect (in color) 2. threshold that, to just black and white 3. trace the lines with a black brush (now it looks like the chicken and jet starters) 4. flood-fill each white area with the right color The color for each flood-fill is determined from the original image. It is the average (linear RGB) color, or a gradient determined by a best-fit slope. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] glass of water
I spotted "glass of water" in the stamps TODO list. Glass is hard to deal with. There's no way I can do this one, but here are two ideas for it: 1. PovRay 2. Careful photography I can produce the stamp if someone can do the photography. You'll need a tripod, a remote shutter trigger button, a device (blocks of wood?) for reproducably positioning the glass of water, some very black and very white material for the background, and the glass of water. Take two photos. The glass goes in the exact same place. (positioning is critical, including rotation) The camera can not be touched, so a timer will not do. You place black material both under and behind the glass, take a photo, and then repeat with the white material. You'll have to stay far away for the photo, so that your shadows and reflections are not anywhere near the glass. Don't bump the light or the table. It's best if you can use a light source that isn't yellow tinted; second best would be a filter on the lens. Be sure that the black material is the same thickness as the white material to avoid changing the glass position. Make the photos large, without JPEG artifacts. While set up, might as well also do: milk, beer, orange juice, Mountain Dew, tomato juice, wine... ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Sun, 2004-12-12 at 05:07, Bill Kendrick wrote: > On Fri, Dec 10, 2004 at 07:33:12AM -0500, Albert Cahalan wrote: > > It's not crashing here. Type of crash? > > (SIGKILL, SIGFPE, SIGSEGV, SIGBUS...) > > Sigsegv. I think my gcc didn't like "while (i--)" or something? > (or maybe there was a double free()... i wasn't debugging it very > professionally ;^) ) > > anyway, seems fixed and works fine now! What compiler do you use? I hope it's 3.3 at least. Random code tweaks are unreliable and unsafe. BTW, some of the stuff you found odd: Declaring variables right before use is less error-prone. If you declare them at the top of the function and then share them, the compiler is less able to correctly warn about uninitialized variables. (the variables might be initialized for one use, but not for later uses) Considering these: work = malloc(sizeof *work * width * height); work = malloc(sizeof(multichan) * width * height); In general, the "sizeof *work" one is safer. If the data type is ever changed, the "sizeof(multichan)" one breaks. I didn't check free() because: 1. Linux generally won't return an error anyway; the kernel will send SIGKILL if it can not provide the memory. (this is configurable, to satisfy financial institutions) 2. There is no reasonable way to handle the error. Calling exit() is really just a crash. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] alpha generation program
I added a new mode especially for pure light sources,
such as fire against a black background. I added a
new mode for compositing a test image with your choice
of foreground, background, and alpha. I improved the
handling of tiny values, reducing the crazy colors.
There's a new -T option that sets a cut-off for what
is considered tiny; I used 29 for the palm tree.
Basic usage remains the same: make your best attempt
at editing away the foreground, do the same for the
background (weird, I know), and then feed *.ppm images
into the program. You'll get alpha as a *.pgm image.
Edit that, feed it back into the program, and you'll
get an improved foreground image. Repeat as desired.
For the final *.png file, use pnmtopng:
pnmtopng -force -alpha a.pgm f.ppm > stamp.ppm
Anybody using this tool?
/
//
///
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/
static void usage(const char *s, int code, int err){
if(s){
if(err){
perror(s);
}else{
fprintf(stderr, "Error: %s\n", s);
}
}
fprintf(stderr, "Usage:\n"
" ./a.out -b background.ppm -o original.ppm -f foreground.ppm >
alpha.pgm\n"
" ./a.out -b background.ppm -o original.ppm -a editedalpha.pgm -f
foreground.ppm > newforeground.ppm\n"
" ./a.out -b background.ppm -o original.ppm -a editedalpha.pgm >
newforeground.ppm\n"
" ./a.out -b background.ppm -f newforeground.ppm -a editedalpha.pgm >
likeoriginal.ppm\n"
" ./a.out -b background.ppm -o fire-like-original.ppm > foreground.ppm\n"
);
exit(code);
}
/
static unsigned width, height;
#define TYPE_PGM '5'
#define TYPE_PPM '6'
//
// quick hack reader for binary P*M files
static unsigned char *readpnm(const char *name, int desired){
int fd = open(name, O_RDONLY);
if(fd<3) usage("fd open failure",80,1);
char *cp;
int type;
struct stat sbuf;
fstat(fd, &sbuf);
cp = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, fd, 0);
if(cp==MAP_FAILED) usage("mmap failure",81,1);
close(fd);
if(cp[0] != 'P') exit(7);
type = cp[1];
if(type != TYPE_PGM && type != TYPE_PPM) exit(56);
cp += 2;
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
width = strtoul(cp, &cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
height = strtoul(cp, &cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
if(strtoul(cp, &cp, 10)!=255) exit(33);
cp++;
if(type==desired)
return cp;
if(type==TYPE_PPM && desired==TYPE_PGM){
// let'd pick the red channel
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
data[i] = cp[i*3];
}
return data;
}
if(type==TYPE_PGM && desired==TYPE_PPM){
unsigned i = width*height;
unsigned char *data = mmap(0, i*3, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
unsigned char tmp = cp[i];
data[i*3+0] = tmp;
data[i*3+1] = tmp;
data[i*3+2] = tmp;
}
return data;
}
exit(93);
}
// This goes from 8-bit sRGB (range 0 to 255) to linear (range 0 to 1).
// The math to produce a table entry:
//tmp = oldvalue / 255.0;
//result = (tmp<=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
static const float sRGB_to_linear_table[256] = {
0.00, 0.000304, 0.000607, 0.000911, 0.001214, 0.001518, 0.001821,
0.002125, 0.002428, 0.002732, 0.003035, 0.003347, 0.003677, 0.004025,
0.004391, 0.004777, 0.005182, 0.005605, 0.006049, 0.006512, 0.006995,
0.007499, 0.008023, 0.008568, 0.009134, 0.009721, 0.010330, 0.010960,
0.011612, 0.012286, 0.012983, 0.013702, 0.01, 0.015209, 0.015996,
0.016807, 0.017642, 0.018500, 0.019382, 0.020289, 0.021219, 0.022174,
0.023153, 0.024158, 0.025187, 0.026241, 0.027321, 0.028426, 0.029557,
0.030713, 0.031896, 0.033105, 0.034340, 0.035601, 0.036889, 0.038204,
0.039546, 0.040915, 0.042311, 0.043735, 0.045186, 0.046665, 0.048172,
0.049707, 0.051269, 0.052861, 0.054480, 0.056128, 0.057805, 0.059511,
0.061246, 0.063010, 0.064803, 0.066626, 0.068478, 0.070360, 0.072272,
0.074214, 0.076185, 0.078187, 0.080220, 0.082283, 0.084376, 0.086500,
0.088656, 0.090842, 0.093059, 0.095307, 0.097587, 0.099899, 0.102242,
0.104616, 0.107023, 0.109462, 0.111932, 0.114435, 0.116971, 0.119538,
0.122139, 0.124772, 0.127438, 0.130136, 0.132868, 0.135633, 0.138432,
0.141263, 0.144128, 0.1470
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, 2004-12-12 at 18:26, Bill Kendrick wrote:
> So okay, I'm seriously confused. How did moving i-- cause an array overrun?
>
>
> This code is crashing for me:
>
> while (i--)
> {
> mc = work + i;
If you have N items and need 0-based access to them,
the "while(N--)" loop is a nice idiom for handling
the problem.
When you moved the i-- past the assignment of mc, the
values assigned to mc become 1-based instead of 0-based.
Add -lefence to your compiler flags to link in Electric
Fence if you want to reliably see the problem.
Valgrind would be even better.
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, 2004-12-12 at 18:26, Bill Kendrick wrote: > I see what's happening. "i" drops down to zero, but you've got a > "goto" in there which jumps back up. That goto should almost never execute. When it does, the stamp is a poor candidate for tinting and ought to be fixed. (thus the warning I had added about the fall-back processing -- did that actually print???) > Can we get rid of the goto? It's difficult work. Since my machine is slow, I don't use emacs. I use joe, which is like WordStar. Two things about the coding style are very hostile to my editor: 1. The usage of mixed tabs as spaces prevents me from using a block indent command. (^K-,) Either spaces or tabs would be fine, but not mixed. 2. The indentation of '}' breaks autoindent. My editor does not contain a whole figgin LISP interpreter and a LISP compiler and LISP libraries and a kitchen sink. BTW, this also causes the human to make many errors. Basically, I am unable to change the indent level. The coding features of my editor work great on just about any style except the one used by Tux Paint. I feel like I'm using notepad.exe, though I'm not. I think /usr/src/linux/Documentation/CodingStyle is sane, even though it isn't my favorite. You need this for it: (defun linux-c-mode () "C mode with adjusted defaults for use with the Linux kernel." (interactive) (c-mode) (c-set-style "K&R") (setq tab-width 8) (setq indent-tabs-mode t) (setq c-basic-offset 8)) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [fwd] Re: Tux Paint in Gnome? [panel crashing bug]
On Mon, 2004-12-13 at 00:03, Bill Kendrick wrote: > I was unable to reproduce the Gnome-panel-crashing bug with Tux Paint 0.9.15 > from CVS. Can someone out here with a Gnome setup test this? (Esp. if you're > able to crash with 0.9.14 :^) ) I had that happen just today. I assumed that the kernel chose to kill the panel to get more memory. The system was swapping like crazy when it happened. Fortunately, Tux Paint died and GNOME restarted the panel. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, 2004-12-12 at 23:24, Bill Kendrick wrote:
> On Sun, Dec 12, 2004 at 08:53:55PM -0500, Albert Cahalan wrote:
> > 1. The usage of mixed tabs as spaces prevents me from
> >using a block indent command. (^K-,) Either spaces
> >or tabs would be fine, but not mixed.
>
> I blame VIM! Damned thing!!! I used to use only emacs, but have
> been finding VI varients load a LOT quicker, plus take the least effort
> to get syntax highlighting going. Beyond that, though, it's actually quite
> a pain in the butt to use.
That explains the use of default emacs style with errors.
> Maybe we should throw the code through prettyprint or something?
These are pretty standard:
indent -kr -ncs -i8 (Linux kernel style)
indent -kr -ncs -nut -i4(what many people like to read)
indent -kr -ncs -nut -i2(close to my usual style)
> > 2. The indentation of '}' breaks autoindent. My editor
> >does not contain a whole figgin LISP interpreter and
> >a LISP compiler and LISP libraries and a kitchen sink.
> >BTW, this also causes the human to make many errors.
>
> Can you explain this one? Do you mean the Emacs style of this:
>
>
> if (blah)
> ..{
> stuff();
> ..}
>
> If so, then yeah... it's a pain when PARTS of the code is indented
> like that, and others are indented in the more standard way:
>
> if (blah)
> {
> ..stuff();
> }
Yes. While I'd much rather have the '{' on the line above,
it's the indented '}' that kills me. Things just don't line
up right, so it's hard to tell if I'm editing correctly.
> Also, way down at the end of the to-do-list in my brain is a note to
> break tuxpaint.c up into sane pieces. It wasn't a big deal when the code
> was only ~2000 lines long, but now that it's reaching 15,000 it's getting
> a little insane. (I can still navigate the code with relative ease... it
> just takes far longer to compile than it should.)
That crossed my mind too. Then I thought, hey, having it in
one big blob might make it run a tiny bit faster. I can search.
(the compiler can cheat on the ABI for intra-file calls)
You can save 1325 lines by moving the '{' up to the
previous line. :-) That's an over 9% reduction.
A bigger concern for me is the cascaded if...else stuff.
Combined with the odd indentation, I often get very lost.
The performance won't scale, though it's hard to tell how
much of a problem this is.
I'd use structs containing function pointers. So the active
tool is defined by a pointer to a struct with methods for
handling a mouse click, mouse move, mouse release, selection
of the tool (for initialization), selection of some other tool
(for freeing memory), and so on. Then the tools can be more
self-contained, not having scraps of code all over.
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] currency
My take on it is this: 1. we can produce digital images for Tux Paint 2. when done with them, they must be destroyed 3. kids can use these images for their art 4. printout size must not be between 75% and 150% 5. printout must not be 2-sided I'm thinking of using these images: http://www.moneyfactory.com/section.cfm/4 I sent a few questions in, and hopefully will get some useful response, but in case I don't get one... does my interpretation look correct? There was a Slashdot article a while back about some government agency providing a set of images specifically for artwork and/or web use. I can't find the article now. I'd appreciate help in finding it. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] CVS problems?
I added some gravestones to the Halloween stamps, and I deleted the erroneous top-level mil directory. Both changes were accepted without error. Neither change has made it to the CVS web or to the commit mailing list. What is going on here? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
On Sat, 2004-12-18 at 00:48, John Popplewell wrote:
> Hi,
>
> just checked out cvs and tried to build it - lots of errors, no surprise
> - its been a while.
>
> A number of them are because I had to change to compiling 'tuxpaint.c'
> as C++ code because of new variable declarations in the middle of
> functions - a style I like, by the way.
Ugh. It's still C. The 1999 standard introduces the ability
to declare variables that are not at the beginning of a block.
(even the 1989 standard allowed declarations at the beginning
of any block, such as right after the "{" of an "if")
> These points are about MSVC++ errors not warnings:
> - mixing signed/unsigned char*
> - 'missing' casts on the return value of malloc() and calloc()
That's because you're not using a C compiler. It's 2004 now,
can't you come up with a 1999-standard C compiler for Windows?
I'd much rather move the variable declarations to the beginning
of a block (not all the way to the top of functions) if you are
unable to come up with a 1999+ compiler for Windows.
> Shall I just check in my changes and be dammed? :-)
No. It's really nasty the way C++ castrated void. I think the
committee basically hated void and wanted to kill it.
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
Doesn't Intel offer a free compiler that you can use? I think it even drops right into Visual Studio, in case you like that environment. There's also gcc for Windows. Oh, and let's not forget Watcom, which is Free Software now and seeing some development. Probably the Intel compiler is the way to go. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] How's the grass?
I just made a tool for drawing grass. The grass is tintable. Sometimes the color selector doesn't show though, so you might need to temporarily choose some other tool for changing the colors. It's best to work from back to front, laying grass down on some nice dirt. I like light grey tinted grass for sunny spots, and black tinted grass for the shadows. Use red for grass that needs water. During development, I noticed a _huge_ slowdown when I switched to going pixel by pixel. I needed to do this to support tinting, both user-selected and random. (random tinting is needed to keep the grass from turning into a featureless blob) Something should be done about this. Maybe have separate functions, indexed by SDL_Surface type, for getting and setting the R,G,B,A data? If the functions were simplified, perhaps by eliminating all non-32-bit surfaces, inlining them would be OK. BTW, the bucket mechanism used for the grass can produce a very smooth random layout. Perhaps the sparkle magic could use this. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
On Sat, 2004-12-18 at 09:20, John Popplewell wrote: > On Sat, Dec 18, 2004 at 02:08:38AM -0500, Albert Cahalan wrote: > > Doesn't Intel offer a free compiler that you can use? > > I think it even drops right into Visual Studio, in case > > you like that environment. > > > I don't think it's free. There is mention of $399. That's if you want suport, or want to do a for-pay project. There's an eveluation and education version that you are allowed to use for stuff like Tux Paint. (last I checked) Intel supports some of the special gcc features too. > > There's also gcc for Windows. > I'm going to have a go at using the VC built libraries, and build Tux > Paint with the MinGW/MSYS tools. > > I've had limited success in the past though, successfully building SDL > and a few other libraries but horrible auto* problems or no support at > all for the other dependencies I had enough trouble on an AMD64 system once. > I think I'll have a look at the Microsoft Visual C++ Toolkit 2003 that > they are giving away as well. Ah yes, I forgot that one. You can get the command-line compiler for free, right? It should plug right into your existing Visual Studio. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
On Sat, 2004-12-18 at 11:37, John Popplewell wrote:
> It _compiles_ existing projects OK, and stuff like this now works:
>
> for(int i = 0; i < 10; i++) printf(".");
> for(int i = 0; i < 10; i++) printf(".");
>
> whereas it used to choke on the second definition of i. Brain-dead!
I excuse them for that one. The evil C++ standards committee
changed the language, for no necessary reason, in a way that
was not backward-compatible.
See the g++ -ffor-scope and -fno-for-scope options.
> but I can't get it to _link_. From reading around, to build Windows
> applications, it seems to need some bits from the platform SDK which is
> 320M or the .NET SDK which I seem to remember swearing never to touch.
I think I recall that .NET basically makes you swear to not
develop GPL code. Go with the platform SDK.
> You want Tux Paint? Boot off this customised Knoppix CD and shut-up!
> Save your pictures onto a USB pen-drive or that network-share over there
> :-)
I have mixed feelings. Things would be better if the installer and
spash screen mentioned that Tux Paint is primarily developed on
Linux and might run best on Linux.
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
On Sat, 2004-12-18 at 16:31, John Popplewell wrote: > On Sat, Dec 18, 2004 at 11:58:24AM -0500, Albert Cahalan wrote: > > On Sat, 2004-12-18 at 11:37, John Popplewell wrote: > > > but I can't get it to _link_. From reading around, to build Windows > > > applications, it seems to need some bits from the platform SDK which is > > > 320M or the .NET SDK which I seem to remember swearing never to touch. > Actually, I managed to get it to link in release mode by suppressing > calls to _ftol which were generating link errors. Sadly, the code didn't > work correctly anymore :-( Something to do with the FIST instruction and > FPU rounding modes when truncating. A well documented can of worms. Go ahead and set the FPU rounding mode to either "toward infinity" or "toward zero" as desired. This will help with float-to-integer conversions, while not causing serious errors for other math. The error would be well under 1 ppm for regular float math. Then, if the compiler can be set to directly use the right instructions, you're all set. Otherwise, you need to make a _ftol() function with some assembly. (either inline, or in a *.asm file) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] color selector
On Sat, 2004-12-18 at 18:32, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > Aside from the *.jpg compression damage, how's this? > > Well, quite ugly, in my honest opinion. I think the current colour > buttons would be fine if the 3D effect just were reduced somewhat. Nope. The colors are getting horribly mangled. Here's the core of the problem: if (nc1 > 200) nc1 = 200; Removing that would give the less-serious problem of white not having highlights. I'd much rather see fully unmolested colors though. WYSIWYG, hmmm? Any 3D effect on the color itself is a WYSIWYG violation. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] color selector, w/ 3D look
How's this? <>___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] value of various tools
On Sun, 2004-12-19 at 05:36, Karl Ove Hufthammer wrote: > But now the magic toolbar is really getting too big (feature- > bloat, anyone?). We should try reduce the number of tools to the > most useful (and used) ones. (Besides, the tools you need to > scroll to use is much less 'discoverable'.) > > I recommend at least removing the 'thin' and 'thicken' tools. They > have never really worked very well, and I doubt they are most > used. The one single tool that I think is critical: fill Except to discover what they do, my son has never used the 'thin' and 'thicken' tools. I think this is partly because they don't really work, and partly because they often don't appear to do anything. If somebody can find a way to fix the tools, including a color-agnostic treatment of lines, I'd like them to stay. Otherwise, they should go. (a red line on blue should thicken, and not just because of a change to treat blue as being darker than red) When asked which tools are good and which are yucky, my son chose only drip as being yucky. This is a bit of a surprise to me, since he initially liked it. I think he just liked the sound; perhaps the sound could be recycled for something else. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Building TuxPaint for Win32 and Linux (Swahili) request for help.
On Tue, 2004-12-21 at 06:40, John Popplewell wrote: > I've previously built the win32 build, but the current version in cvs > doesn't work anymore with the Microsoft compiler I was using. I have > successfully built Tux Paint using the MinGW http://www.mingw.org/ > toolset and I'm currently working on building all the libraries with > this (struggling a bit with smpeg). Isn't smpeg for playing MPEG video streams? If it's needed by SDL, perhaps you can just configure it out. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] dead space and New dialog
I think that "New" should have a dialog. It would be like the "Load" dialog, containing the starters and a blank canvas. This gets the starters out of the "Load" dialog, reducing confusion. It also makes for easy selection of a background color. (if the starters don't get moved, then instead the "New" button should be eliminated in favor of an all-white starter) The "Load" dialog has lots of dead space. The obvious solution is to enlarge the dialog to cover the tools, tool options, and color selector. There are some other possibilities though: the toolbar could be active, so that the "Back" button becomes unneeded. The buttons could go in the tool option area on the right, or even in the far right side of the Tux area. Better yet, the buttons could be eliminated (one click to load a file) if the highly-dangerous delete feature were moved elsewhere. BTW, the green labels can simply be removed. Especially the "Colors" one is useless, but I don't think the other two are particularly useful either. Little kids simply click on them instead of reading them, thus receiving no benefit and a loss of screen space. Thoughts? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] locale stuff
I've tried to neaten up the locale stuff, moving it all to one part of the tuxpaint.c file. There are some things I find strange about the code. First of all, why so many setlocale() calls? It seems like all except the ones right before a call to set_current_language() are useless. Second, why set environment variables? Normally, one sets environment variables before calling exec(). Within a program, data is usually passed around via normal C variables. Third of all, what is with the LANG usage for Polish and Lithuanian? It looks like a bug. Fourth, why doesn't Hungarian set LC_ALL like the others? This too looks like a bug. Current call graph: main setlocale(LC_ALL, "") setup parse_options (system conf file) set_langstr parse_options (user conf file) set_langstr set_langstr\ either do_locale_option / order LANG=foo setlocale(LC_ALL,"") setup_language if polish or lithuanian, set_langstr() (WTF???) LANGUAGE=foo LC_ALL=foo setlocale(LC_ALL, ""); set_current_language *** setlocale(LC_MESSAGES, NULL) and lots of monkey business *** load_locale_font LANG=C OUTPUT_CHARSET=C setlocale(LC_ALL, "C") set_current_language() *** setlocale(LC_MESSAGES, NULL) and lots of monkey business *** ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] fonts
Japanese didn't work until I commented out the line that makes it require a non-standard font. Now it appears to work perfectly. (well, it looks kind of asian you know...) I don't know if this includes the Han (Kanji) characters, or just the Katakana and Hirigana, but it appears to cover enough for Tux Paint. Greek also works fine w/o a funny font. It looks much better in fact, with the text correctly sized. Even Hebrew works without a funny font, except that the stamps are untranslated and the English runs the wrong way. So, if these locales are going to be listed, the font loading code needs to NOT give up on the locale when a locale-specific font can't be found. It might be best to load fonts on demand, as missing characters are needed. It would be nice if gettext() had a hook for this or would only translate when the characters are in the loaded fonts. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] fonts
On Wed, 2004-12-29 at 04:44, Bill Kendrick wrote:
> The default UI font was changed a while back, so it seems we're now using
> one that includes some of these glyphs.
I was thinking that the fonts have been growing.
Because the fonts certainly could grow, I think it
best to continue on in the locale when loading the
locale font fails, instead of reverting to English
or exiting. Little boxes might be no more unreadable
than English. The code would be simpler that way I
think, and one can always specify --lang=english if
desired.
It's annoying that TTF_RenderUTF8_Blended does not
return an error for missing characters. Perhaps the
output of a test image could be examined, like this:
// translate this as a string of characters that you
// fear may be unavailable in common fonts
char *s = gettext("troublesome");
BTW, half-serious even...
Given the shear number of things that Hebrew users
want mirrored, it might be easier to just mirror
all of tuxpaint.
a. load and save with mirroring
b. mirror the mouse movement
c. mirror when updating the display
d. mirror all stamps
e. mirror the fonts
This gets Tux on the right side, facing the desired
direction. It gets the toolbars on the correct sides.
It gets the load and save icons flipped correctly.
It gets the colors flipped. It gets dialog box buttons
on the correct side. It gets wordwrap at least as
correct as it is now.
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] text tool
How about text controls? See attached image. Without text controls: 4 sizes * 2 boldness * 2 italicness == 16 Also, double-wide buttons would be nice. This would allow for more-useful example text like this: ag4ytIl10O <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] text tool
The text tool now has controls. I'd like to leave a few printf() lines in until everybody (Red Hat, Mac, SuSE, Windows, BSD...) gets a chance to run the code. Sorting through fonts is quite an error-prone mess, thanks to font foundries that use irregular style naming and sometimes don't supply a full set. I now have 34 user-visible choices. I might cut that down a tiny bit via a list of common clones. For example, "Courier" is nicer than "Courier New" and "Courier 10 Pitch". Purposely failing to match up italic and non-italic font styles might be of use. In that case, the FreeType italic emulation will always be used. This allows for double-italic, which often looks nice. In general, italic emulation looks good and bold emulation looks gross. BTW, don't let me forget to free the style array. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] text tool
On Fri, 2004-12-31 at 03:49, Bill Kendrick wrote:
> I like! (We need better icons for the italic/bold controls, obviously... :^)
> )
In the mockup, I used 36-pt Ariel Black for the bold button.
> Seems happy under Debian Linux (Testing branch) using
> xserver-xfree86 4.3.0.dfsg.1-8.
That's nearly what I tested with. I also poked around on
a Red Hat box at Sourceforge, to see where Red Hat likes
to store fonts.
> I have a ton of fonts installed on my system, and Tux Paint picked them up!
> Most look pretty good.
Any that fail horribly?
> Now... I have a suggestion. Can we allow for even bigger text?
Maybe. It detracts from the WYSIWYG interface, unless the
buttons grow to fit the example text.
BTW, I chose "ag" because those two letters vary a lot.
There are two types of "a" and two types of "g".
For 36-pt without --upercase I'd like to use that.
With --uppercase, I'd like to use "FJ" or "L7". These
letters kern closely together. "AV" is nice too, but it
doesn't have any curves. (BTW, if --uppercase is going
to stay, it needs to quiet down before the release)
In large sizes, switching to just "a" would be useful.
This would allow going up to around 96-pt without needing
to break the WYSIWYG interface. In smaller sizes, another
letter would fit. I thought of adding "F", but maybe the
Brittish would be bothered? ("Fag" is slang for a cigarette)
Perhaps 12-pt should be added. (or 13-pt, but...)
I notice you added these: 56, 64, 96, 112, 128, 160.
Oddly, you left out 72 and 144. Maybe it doesn't matter
these days, with the FreeType engine and modern fonts,
but traditionally it's safer to pick simple ratios of 72.
Other sizes, at least historically, tend to look bad.
Perhaps this is only the case for tiny sizes, when a
patent-licenced rendering engine uses the hinting code
embedded in the font files.
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] new btn_off.png
Here are two proposed btn_off.png replacements. (imagine that the "Colors" label matches) Copy to /usr/share/tuxpaint/images/ui/btn_off.png and see what you think. Which one more clearly indicates "disabled"? Note: they go with the latest CVS tuxpaint, which puts the text and icon in grey for disabled tools. <><>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] TODO list
Just to let people know what I'm thinking of... flat green labels scroll wheel doesn't go too far scroll wheel works for Open dialog wider Open dialog add New dialog grey outlines for all disabled stuff "Colors" label should be grey too, not black or missing free font style memory #if out bulk free at shutdown brick morter standard "B" and "i" for text controls disabled font and stamp controls should turn grey magic shrink magic grow a few gradient starters (horizon, with varying sky and surface) magic 3-D paint (like Gimp Quickmask, stipled like stamp outline; draw on release) magic stamp (like Gimp Quickmask, stipled like stamp outline; make stamp on release) always separate controls from tool choice (move above label or force scroll bars) brick tool with longer layout memory, surviving button release rough-looking 3-D brick surfaces faster grass via blit over it? (blit keeps destination alpha) brick sound, ONLY when a brick is placed correct screen update for grass gamma-aware alpha blend for paint -- need faster getpixel/putpixel for tiny stamp sizes, act like an image hose for large stamp sizes, draw on release (allowing center off-screen) resolve WYSIWYG problem with font sizes wide font buttons maybe? large and small UI options backwards and upside-down UI options ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. I have 3 ideas for this. I'll send them in separate mails. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. I have 3 ideas for this. I'll send them in separate mails. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. I have 3 ideas for this. I'll send them in separate mails. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. Here's another. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. Here's #5. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. Another! One more coming. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: > I think the buttons TuxPaint uses for controlling the size and other > properties of stamps (or in this case, text) take too much screen > space, letting the user with only a few stamps/fonts visible. Things line up better with Tux being 48 high. <>___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] different layouts
When considering the layout, remember to think about where excess vertical space should go. Currently, the canvas height is the largest multiple of 48 that fits. Any leftover space (up to 47 rows) goes to the Tux area. Some of the proposed layouts work naturally with this. Some will require that buttons grow to fill ugly gaps, and this may cause alignment problems or non-square control buttons. It's nice if the layout still looks good with the tool option area (right button bar) consumed by a dialog. Imagine the "Open" dialog being a bit wider, extending to the right by 96 additional columns. Well anyway... what do people like? (usable, pretty at all sizes, easy to code...) ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] different layouts
On Sat, 2005-01-01 at 22:45, Ben Armstrong wrote: > On the other hand, now that I look at it again, won't kids miss when > pressing the black or grey color chooser buttons, and accidentally hit > print or quit instead? I think that's more of a problem when painting near the edge of the canvas. In any case, I have a solution for this: have the edges of the buttons ignore mouse clicks. Two to four pixels should do. > Most of your layouts have this problem, except > for number two (four small square buttons in a row at bottom right) and > number four (four small square buttons in two rows at bottom right). Of > these two, I think I'd choose number two, by virtue of having larger > color chooser buttons, I think that one is fairly nice looking (almost the best, but not quite) and easy to code. It also will look good when the screen is larger -- the gap below is not half as ugly as the one that would form when a lovely layout with perfect-fitting 2x2 controls is made taller. For widths of 912 and up, the buttons follow the color buttons in shape and size. For widths of 912 and below, the buttons are square. At 1728, they can go back to being square (half a color button at that size) again. > although I worry that in some languages, the loss > of extra text area space may be a problem. The button face font can be used. (either it is readable, or it isn't -- either way, it's in use right now) > (Oh, I see number three also > doesn't have that problem, but I really really don't like the font style > & size button placement in that one.) How about if those buttons were on the other side, with a similar arrangement, instead of wrapped around Tux? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] event handling
Much to my horror, I discovered that Tux Paint has distinct near-duplicated code for handling various mouse-related options. This leads to lots of trouble. For example, when the variable-size erasers were added, somebody forgot to update the code that changes the mouse cursor. This means that the cursor does not respond to the difference between active buttons (valid erasers) and inactive ones. Another example: I fixed scrolling of tool options when using the purple buttons. The display does not scroll too far anymore. I missed the existance of separate mouse wheel code, so that didn't get fixed. I see a lot of code duplication there. So, what should the fix be? Here's one idea: do all the mouse cursor updates via an SDL_Surface where each pixel is abused for the storage of a mouse cursor index. When drawing buttons or whatever, also draw to this surface. When the mouse moves, simply examine the "color" of this surface to determine the proper mouse pointer. For the scrolling, have a global function pointer that gets called. Both the scroll wheel and the purple buttons call the same code. The function pointer can change as needed to allow scrolling of other things. Here's another idea: create a real widget set, like a sort of cut-down GTK. Widgets get passed events, and may pass events on to child widgets, etc. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] event handling
On Mon, 2005-01-03 at 18:11, Bill Kendrick wrote: > On Mon, Jan 03, 2005 at 11:53:19AM -0500, Albert Cahalan wrote: > > Much to my horror, I discovered that Tux Paint has > > distinct near-duplicated code for handling various > > mouse-related options. This leads to lots of trouble. > > (Whistling innocently) > > Honestly, 2.5 years ago, I didn't think we'd even still be messing > with the event handling, or much of Tux Paint's internals at all! :^) > Sorry! Heh. Sorry for what now looks like rudeness on my part. Perfectly reasonable code turns horrible when it gets outgrown by the surrounding code. I'm sure it was all quite sane before stamp options, various dialogs, etc. Then, 1+ lines later, it needs some reworking. > I'm not sure about making a complete widget system, but I think some > code consolidation might be good. The difficulty is that there is sort of an inversion in the control flow. Early on, events get split apart by type. (mouse move, mouse click, mouse release, etc.) Then, these events all end up needing the same sort of computation to find out what screen object got affected. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
These all need to be assigned a meaning. (boldness level, italic, don't-care, or reject-this-evil-font) I'd like to know the full family and style names, along with your idea of what the font looks like. If you can share the fonts, do so. I'll take some example guesses: Font style parser stumped by " regular". boldness=1 Font style parser stumped by "10". ??? Font style parser stumped by "Atom Light". boldness=0 Font style parser stumped by "Busted". reject-this-evil-font Font style parser stumped by "Embossed". ??? Font style parser stumped by "Inline". ??? Font style parser stumped by "Normal". boldness=1 Font style parser stumped by "Painty". ??? Font style parser stumped by "Rounded". move style into family (see "Condensed" treatment) Font style parser stumped by "SuperBold". boldness=3, or treat like "Condensed" Font style parser stumped by "SuperGross". ??? Font style parser stumped by "Wet". ??? Font style parser stumped by "\040Regular". ??? (is that supposed to be a space?) ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Mon, 2005-01-03 at 18:30, Bill Kendrick wrote: > Tux Paint in CVS (as of Jan 3, 23:30 UTC) is segfaulting on startup, I tried to crash Tux Paint using Electric Fence with a variety of environment variable settings. No luck. > right as (or after) it's loading the fonts: > > $ tuxpaint > ... > ::: 5 FreeSans > Medium > Oblique > BoldOblique > Bold > Medium > duplicates, discarding: FreeSans, Medium > b 0, spot 0 > occupancy 0x82d4f20 0x844cb50 0x82df000 0x8308e28 > Segmentation fault > $ What you see there is that Tux Paint found two files in the same directory that both mapped to non-bold, non-italic. It's the default_font.ttf symlink. One of the files must be discarded. Hopefully you never see this for any other font. BTW, if the symlink were elsewhere, it would not be merged with the others. It would be considered a distinct family. It would then get silently discarded based on a scoring system that prefers font families with more styles. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] text tool
On Mon, 2005-01-03 at 18:10, Bill Kendrick wrote: > On Mon, Jan 03, 2005 at 12:44:30PM +0900, TOYAMA Shin-ichi wrote: > > I think "tp-all48.jpg" is good. > > I think tp-all48.jpg is good, as well. However, tp-32x40.jpg might be > better, as it leaves a little more room for text under the colors. What should happen when the screen height is not a multiple of 48? What gets the spare vertical space on the right side? > > One matter for concern is that it may be a little difficult for > > three-year-old children to push 24x24 or 32x32 icon in some other > > examples, especially on high resolution display. > > Agreed. Having 'mini' buttons also looks a little weird, too... For a 3-year-old, you disable the stamp/font controls anyway. I think it's safe to assume that a kid able to use the controls is able to handle small buttons. I think that avoiding weirdness is mostly about lining thing up. When possible, the lower corners of the canvas should be on 4-way corners. (like where Arizona meets Colorado). It's hard to satisfy this for odd screen resolutions. Ideally, there should not be small gaps. Large gaps aren't so bad always, but small ones are always disturbing. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Mon, 2005-01-03 at 18:30, Bill Kendrick wrote:
> Tux Paint in CVS (as of Jan 3, 23:30 UTC) is segfaulting on startup,
> right as (or after) it's loading the fonts:
I had this problem until a made a blacklist. Perhaps you
have a font that needs to be on the blacklist. I suspect
that the font library is buggy. Try eliminating groups of
fonts to see if you can identify a troublemaker.
The X11 "Cursor" font is deadly.
Here, use this:
/
// gcc -O2 -W -Wall -lSDL -lpthread -lSDL_ttf
// ./a.out `find /usr | egrep '[.](ttf|pfa|pfb)$'`
#include
#include
#include
#include
#include
#include
#include
static void hidespace(char *s){
while(*s){
if(*s==' ') *s='.';
s++;
}
}
static void testfont(char * const filename){
char *type = strrchr(filename,'.') + 1;
TTF_Font *font = TTF_OpenFont(filename,100);
if(!font){
fprintf(stderr, "FAIL: %s\n", filename);
return;
}
int total_height = TTF_FontHeight(font);
int ascent = TTF_FontAscent(font);
int descent = TTF_FontDescent(font);
int lineskip = TTF_FontLineSkip(font);
int numfaces = TTF_FontFaces(font);
int fixed = TTF_FontFaceIsFixedWidth(font);
char *familyname = TTF_FontFaceFamilyName(font);
char *stylename = TTF_FontFaceStyleName(font);
//int minx, maxx, miny, maxy, advance;
//int rc = TTF_GlyphMetrics(font, (Uint16)'A', &minx, &maxx, &miny, &maxy,
&advance);
hidespace(familyname);
hidespace(stylename);
hidespace(filename);
printf("family=\"%s\" type:%s style=\"%s\" %s\n", familyname, type,
stylename, filename);
TTF_CloseFont(font);
}
int main(int argc, char *argv[]){
if(TTF_Init()) return 5;
while(--argc) testfont(argv[argc]);
return 0;
}
///
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
On Tue, 2005-01-04 at 02:20, Bill Kendrick wrote: > I've added a "--nosysfonts" option to Tux Paint > (and corresponding control in Tux Paint Config) which disables any attempts > to load fonts from 'outside' Tux Paint. > > This allows _me_ to keep running the app, until we can figure out what > the problem is with the font grouping code in the latest CVS. ;^) > It may also prove a useful feature in the 'real world' (for both preventing > possible crashes, as well as culling down the number of available fonts > for people who(se kids) don't need them.) That's probably good for those people who were crazy enough to buy and install a 5000-font CD-ROM. Of course, every other app on their system will be horribly slow. Would you like a memory checker in CVS? I have one, only about 150 lines, that prints a nice report when the app exits. For each alocation, you get a line with: 1. the size 2. the line number, or -1 if allocated from another file 3. the allocation number (1,2,3,4...) Possible enhancements: a. printing the report when a signal is sent b. printing the nearest line-numbered allocations for an unnumbered one c. tracking high-water marks Right now, Tux Paint leaks just under half a megabyte. I've yet to determine if this is a one-time leak or an on-going leak. > Also, I've replaced the 640x480 and 800x600 radio buttons with a pulldown > that lists the window dimensions listed in tuxpaint --help. > (Tux Paint Config also now, obviously, supports the "windowsize=..." syntax.) I think all sizes work now. I haven't really checked the file open dialog. I just recently fixed the low-quality color selector to not overwrite the tux area. I've been testing with heights that are not a multiple of 48, and things have been looking good. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
On Tue, 2005-01-04 at 02:20, Bill Kendrick wrote: > I've added a "--nosysfonts" option to Tux Paint > (and corresponding control in Tux Paint Config) which disables any attempts > to load fonts from 'outside' Tux Paint. > > This allows _me_ to keep running the app, until we can figure out what > the problem is with the font grouping code in the latest CVS. ;^) Try now, without that option. Tux Paint now tries to render both 'A' and 'a' for each font. It then compares them to see if they are the same or not. I commented out the blacklist for now. The X11 "Cursor" font won't render. This seems to be a serious undocumented bug in the library. In fact, no error return is even documented. I had to guess that a NULL might be returned. The library should be supplying an image of a box to represent the failure, as it does with other bad fonts, or it should have a documented error code. Several other fonts return generic box images. I have Tux Paint discard any font that has 'a' match 'A'. Probably I should also discard the font if 'a' matches 'z' or if 'A' matches 'Z'. So, what is your bad font? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Thu, 2005-01-06 at 08:32, Karl Ove Hufthammer wrote: > Bill Kendrick <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > Tux Paint in CVS (as of Jan 3, 23:30 UTC) is segfaulting on > > startup, right as (or after) it's loading the fonts: > > For me too: > > Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular > Bad font, 'a' and 'A' match: s05l.pfb, Standard Symbols L, Regular > Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular > Bad font, 'a' and 'A' match: s05l.pfb, Standard Symbols L, Regular > free(): invalid pointer 0x821ce08! > free(): invalid pointer 0x81a2fd8! > Segmentation fault Perhaps on x86, SDL_FreeSurface and free are different. I just checked in a change that uses SDL_FreeSurface for two surfaces. Maybe that'll do the job. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: TuxPaint Bug Report (tux4kids)
On Thu, 2005-01-06 at 15:24, Bill Kendrick wrote: > cat IMAGE.PNG | pngtopnm | pnmtops | lpr That seems like a funny way to do things, since generating a PPM is so dead simple. Going direcct to PostScript can't be all that bad (being inocent perhaps). Is there some reason you'd want the PNG? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Fri, 2005-01-07 at 05:02, Karl Ove Hufthammer wrote: > Albert Cahalan <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > >> Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular > >> Bad font, 'a' and 'A' match: s05l.pfb, Standard Symbols L, Regular > >> Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular > >> Bad font, 'a' and 'A' match: s05l.pfb, Standard Symbols L, Regular > >> free(): invalid pointer 0x821ce08! > >> free(): invalid pointer 0x81a2fd8! > >> Segmentation fault > > > > Perhaps on x86, SDL_FreeSurface and free are different. > > I just checked in a change that uses SDL_FreeSurface > > for two surfaces. Maybe that'll do the job. > > I now get the same error message, with exception of the two 'free()' > lines, which have disappeared. You mean the segfault, or just the noise about rejecting a few crummy fonts? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
