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, eeeew! 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
