#21
Posted 20 October 2012 - 12:17 AM
Attempting to floodfill an area when the area is already the color you are trying to fill it with causes stack overflow on line 744.
Also, attempting to use clear tool (x) when there is no selection causes attempt to index nil on line 642.
#22
Posted 20 October 2012 - 01:17 AM
faubiguy, on 20 October 2012 - 12:17 AM, said:
Attempting to floodfill an area when the area is already the color you are trying to fill it with causes stack overflow on line 744.
Also, attempting to use clear tool (x) when there is no selection causes attempt to index nil on line 642.
The first bug has been fixed. Please report any other issues with the flood fill tool, as it is a little temperamental.
The second bug is a little confusing. X is now the "cut" tool, and only works with a visible selection rectangle, Z now clears the image, or the clipboard depending on whether or not the selection rectangle is visible. C, V and X are now disabled when no selection tool is visible, and can also be accessed by right-clicking when in selection mode. The help file has been updated to reflect this.
A few more bugs were cleaned up as well as one or two consistency changes (e.g. leftCtrl opens up a drop-down menu now). I believe the program can now almost be operated entirely with the mouse, which is really nice.
Edit: Another update, Flood Fill now uses an iterative algorithm rather than a recursive one, so now the algorithm won't crash when attempting to flood fill more than 50 or so pixels. Few more tiny fixes here and there. Program now seems pretty stable.
#23
Posted 20 October 2012 - 06:33 PM
Attempting to open help for file mode causes attempt to concatenate string and nil on line 601.
Attempt to floodfill the background when there is no pixel (possibly any transparent area) causes attempt to index nil on line 1119.
#24
Posted 21 October 2012 - 03:52 AM
faubiguy, on 20 October 2012 - 06:33 PM, said:
Attempting to open help for file mode causes attempt to concatenate string and nil on line 601.
Attempt to floodfill the background when there is no pixel (possibly any transparent area) causes attempt to index nil on line 1119.
Another update, both bugs reported now fixed. A few more changes to menu look and feel and interface in general.
#25
Posted 21 October 2012 - 05:41 AM
#27
Posted 21 October 2012 - 06:32 AM
#28
Posted 21 October 2012 - 06:57 AM
faubiguy, on 21 October 2012 - 06:32 AM, said:
Well caught! In fact all mouse-triggered selection tools were incompatible with scrolling. This has been resolved.
BigSHinyToys, on 21 October 2012 - 05:41 AM, said:
The tool itself is, well it's just a tool, barely merits a video. I'll likely be using this in tutorials on game design in the future however, once 1.45 is released. Glad you like it!
#29
Posted 21 October 2012 - 07:00 AM
#30
Posted 21 October 2012 - 08:02 AM
NF
#31
Posted 24 October 2012 - 01:59 AM
#32
Posted 24 October 2012 - 02:45 AM
#33
Posted 24 October 2012 - 06:01 AM
dcleondc, on 24 October 2012 - 01:59 AM, said:
I probably won't do this, because it makes the file format 3 times more complicated than I want it to be. I'm not sure creating motion pictures is the best application for NPaintPro (efficiency reasons, there are probably much faster methods), but if you wanted to I'd recommend making the animation without text in it, and then writing an application that loads in the animation and draws the text at the appropriate frame(s). At some point I'll be releasing an API that will make this process easier, and this way will give you significantly more control over how you play the animation.
Heracles421, on 24 October 2012 - 02:45 AM, said:
Uncertain what you mean by this. Do you mean detecting where a pixel is in any given image that has been saved before hand? If so the tool wouldn't belong (or be very useful at all) in NPaintPro.
The files are saved in such a way that the top, bottom, left and right most extreme pixels define the limits for the image, so you can use these restrictions when reading each line to find individual pixels by simply looping through each pair in the list of colours or strings that you make. NPaintPro performs equivalent operations when performing renders and many of its other operations rely on those limits so you can read through the code for examples.
#34
Posted 25 October 2012 - 02:39 AM
Heracles421, on 24 October 2012 - 02:45 AM, said:
I really liked the idea of using NPaintPro to create blueprints for turtles, and although there's not much the paint tool can do itself to make turtles understand the image format, I can make creating blueprints easier and cooler with a new display mode:
Though it was sort of designed for building housing blueprints, the gridlines in this mode make lining up distanced images, figuring out dimensions and drawing straighter in general much easier, so it has many uses. However the ability to change the alpha channel is turned off (to make the gridlines easily visible) so for pictures that require both I'd recommend drawing the outline/shape in blueprint mode and then colouring in alpha mode.
One or two bug fixes in this version too, and tester credits to faubiguy
#35
Posted 25 October 2012 - 02:57 AM
#36
Posted 25 October 2012 - 03:57 AM
nitrogenfingers, on 25 October 2012 - 02:39 AM, said:
#37
Posted 25 October 2012 - 04:24 AM
~Dragon, on 25 October 2012 - 02:57 AM, said:
At the moment there's the "flood fill" tool, which works the same as the bucket tool does typically in your standard paint application. Because there's no limit to the size of the canvas (unlike paint), it means you can't just fill empty space- you have to draw something first and flood fill that. At the moment there's no way to fill a selection with a given colour but that might appear in the future...
Heracles421, on 25 October 2012 - 03:57 AM, said:
I'm still not quite sure what you mean Heracles. Again NPaintPro creates image files- you ask to draw in a certain coord and store the location at the same time: that's what the image file is. Save it and then open it in an external program, and extract locational information from there. The tool has to output to a file (it can't simply feed into another program), so you'll have to read that file to know where the pixels are.
#38
Posted 25 October 2012 - 11:34 AM
nitrogenfingers, on 25 October 2012 - 04:24 AM, said:
#39
Posted 25 October 2012 - 05:22 PM
Heracles421, on 25 October 2012 - 11:34 AM, said:
make your program open the picture file read its continence and use those points as your coordinates.
if there is a 1 on line 2 three places in then use the (3,2)
if there is a 1 on line 6 in position 1 then use (1,6)
All the information you need is stored in the save file you don't need to get any coordinates from npaintpro just interpret its Image file witch is pretty simple btw.
example
making a program that printed out this file using wool would be very simple just a couple of for loops a turtle.forward turtle.place
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users