Virtual Nomad, thank you for the explanation.
As for presenting the creation in the present state, it is still not ready. I am the sort of person that builds the house first and finishes it before inviting guests to use it. Originally, I did not intend to do so much changes to the tool, however on this wonderful Baxslash code adventure, I have learnt so much from him and was inspired personally and others as yourself and blink0k to expand this tool beyond what I originally intended it to do and as I am progressing with upgrading, I keep coming up with more ideas to implement. To tell you honestly, I have no idea when these ideas will come to an end, however I do plan to get it to the state that:
1) Start screen will be full interactive with scrolling in the case required.
2) An option to browse for a file that might be else where on the system.
3) Fully functional Edit feature, that as of now is fully functional.
4) Fully functional delete feature, that previously was a right mess that would cause the program to crash. I have managed to fix that issue, so that now you can delete whatever shape of whatever sprite or whatever image the user is working on, all is updated to the database and array system and exported to the relative file for the image concerned. However, at present the delete feature can crew up the box shapes, meaning in the case one wants to delete a polygon shape that will get replaced with a box shape, then the result box shape will be screwed, because I need to update the array responsible for the tool that created the shape, otherwise the box shape will export as a standard polygon shape, which doesn't calculate nor creates a box shape, but a strange polygon shape. To fix that will be simple.
5) Fully functional export feature that at present is fully functional for polygon and box shapes, but does not export chain shapes. To implement the export of chain shapes will be a simple task also in comparison to exporting box shapes that require two different methods of exporting depending on whether the user edits a box shape with points 1 or 4 OR 2 or 3. Originally the box shapes export was according to points 1 and 4, meaning the x1,y1 and x2,y2. In order to adjust the size of the box shapes with any of the 4 points that make up the box, such implementation in the export had to be made.
6) The scale and offset thing. That is an important one. Basically, in the original ShapeUp tool Baxslash implemented the offset and scale to all exported shapes code to the file. For the purpose to better know what is going on whilst working on the upgrading of this tool, it was better to get rid of the offset and scale and set the offset to 0,0 always and scale was not part of the equation at all. This 0,0 offset and no scale factor works perfect for big images like the map of Japan, however for the tiny sprites that many people might be working on for their games, for 2D RPG tiles and features in such games or platformers, the images are as small as 32x32 and to try to create specific polygon shapes for such small images and then try to use the edit feature on them, doesn't work well in my epxerience and I was editing points and adding points to that bird image that is about 120x120 and it created problems as the ranges were so small for all sides that it was difficult to place a precise point on some of the sides without the adjacent or opposite side intefering with the process. The scale factor and altered offset will play a crucial role for images smaller than a certain size that would make difficult such polygon shapes creation and especially editing of such shapes. At present I am working on the logic for the scale factor to be applied to images that are smaller than a specified limit and especially on adding this factor to the export feature that basically divides the export into two separate modes, one for sprites of small images and one for spirtes of large images.
7) I want to add to the edit feature the delete point capability, which ought to be much easier than the add point implementation, just a reverse of the process without all the calculations for the new point location and that.
Until now, that is the bare minimum I want this tool to be able to deliver. On the journey towards that, I know not of what other ideas I might be enlightened with to further improve the tool, however I do not intend this to be a never ending story. Other than the above mentioned points to be realized, the remaining works would just be more of a more cosmetic nature and overall graphical look to the entire tool, rather than any further improvements. It is good to leave room for another person to further improve this to another level altogether in the case one would require more of such a tool.
As for the name for the upgraded ShapeUp tool, I agree with you to give it a new name with reference to the original in the actual code and a README.txt file to explain the history of the tool and it's original author and name with a folder added to the actual project folder contatining all the files and code of the original ShapeUp tool by Baxslash, so as to give the opportunity for others to compare and learn from both and even recreate the entire thing in a different way, in the case one would want to address the problems in a different fassion for the purpose of a learning experience and perhaps for the purpose of creating something even better. I would reason to call this upgraded version not from an artist's approach, but more from an engineer's approach in practical terms of it's functionality, , something of the sort "Sprite Shapes Creation Tool For AGK" or "AGK Sprite Shapes Creation Tool", in order for anyone searching for such a tool, the problem being Sprite Shapes for AppGameKit, that would be an obvious result to one's search.
As for the time to complete all this, I dare not to announce it as it would probably stress me out and lead to prolong the progress instead to meet the deadline. I am the sort of person, that if I would tell you, I will get it done in a month's time, I would probably stress about the deadline to the extent to make mistakes and lead to finish it in two months, and on the other hand without giving a deadline, I could potentially finish it in half of the time. To complete the basic functionallity this will not take much long to accomplish. The final touches to the overall visual appearance and cleaning of the code and adding rem statements, that would be the longer part to finishing this off.
blink0k, thank you. I will study this when I will get to the point to implement that browser part. Actually to implement that might be problematic for me at first, cause this will be the first time I would use a plugin in AppGameKit, so please be patient my friends.
Have a good night.
????????