UPDATE:
After having got the edit mode working pretty OK, I began to make some major changes to how the edit mode functions and the result was a tragedy that led me to literally go a fraction from insanity. The entire thing screwed up big time and I seriously didn't know where the problem was, so in the end I was trying to solve the problem in the wrong way and places that only made things worst. I spent the entire Friday night until 6 in the morning battling this nightmare and then again Saturday night until I cannot even remember, my brain is fried. All in all, I knew I had to leave the problem and let my head cool down before reattempting to solve it and as was a case before where I would spend all night battling a relatively simple logic, I could not solve it, went to sleep, the next morning woke up and solved in less than half an hour. Same happened with this little nightmare, where in the end the problem was one little line of code in the wrong place, and I spend hours editting and amending tens of lines of code trying to solve the problem. I reason these experiences make a person grow in programming, though in the midst of it, it is even for the most patient, a difficult battle.
Now, that the problem is figured out I was able to focus on the actual new system for the edit feature. This new system, at first I reasoned was the problem for the major problem, but it was that one line of code. Now the new system works pretty well with both polygon and box shapes and the AddSpriteShapeBox works fine as well, though the box shape can only be modified with the 2 points that create it and in the edit mode when one goes over with the cursor on either of these two points the circle becomes filled with green to indicate it is controllable, the other points are interactive just visually in the edit mode and can be used as points for new shapes in drawing mode.
Also, the new array system for the edit mode, I had problems with it trying to modify several points of different shapes that share the same points led to breed some strange effects. This is where the Print() command for debugging purposes proved to address where the problem was and it was in the fact that each time a point was modified the data for the point was collected and passed unto the array of the edit mode, but upon several points being collected the data for the other points was still present and intefered with the editing, so I had to create a separate function to deal with the resetting of the edit mode array system to zero everything before collecting new data for the next point to be modified. Works really nice now, no problems so far.
Still need to implement the chain shapes to export, but as I was busy with this little nightmare, I had no time to deal with it. Also the delete feature is pretty screwed up at the moment also, so that will need to be fixed, probably using arrays again. It seems I have nearly changed the entire system to use the array system, so the old system is nearly nonexistent. This array system proves to be much more efficient and better way to handle the data overall, as an example:
Former functions for handling the edit mode for collecting the data for the points being edited, note that it uses a dp=dp+1 to keep track of the different points being collected as one point could be shared by 4 shapes or more, so the dp=dp+1 updates for each point:
function collectPoints(px#,py#)
dp = 0
for s=1 to shapes
for i=1 to shp[s].points
dx# = getShapeX(s,i) - px#
dy# = getShapeY(s,i) - py#
d# = sqrt(dx#*dx#+dy#*dy#)
if d#<10
dp=dp+1
dim drag[dp] as dragType
drag[0].point=dp
drag[dp].shape = s
drag[dp].point = i
endif
next
next
setTextString(txt3,"Dragging ["+str(dp)+"] points")
endfunction
function dropPoints(px#,py#)
num = drag[0].point
for i=1 to num
s = drag[i].shape
p = drag[i].point
setShapeX(s,p,px#)
setShapeY(s,p,py#)
next
endfunction
Present array system:
function collectPoints(px#,py#)
dp=0
for j=1 to spriteID
for s=1 to database[j].shapes
for i=1 to shapespointar[j,s]
dx# = getShapeX(j,s,i) - px#
dy# = getShapeY(j,s,i) - py#
d# = sqrt(dx#*dx#+dy#*dy#)
if d#<rad#
rem keeps track of total# of points being modified
dp=dp+1
rem store point# for sprite j and shape s into array
dragpointar[j,s,1] = i
endif
next
next
next
setTextString(txt3,"Dragging ["+str(dp)+"] points")
endfunction
function dropPoints(px#,py#)
for j=1 to spriteID
for s=1 to database[j].shapes
for k=1 to shapespointar[j,s]
rem check whether the array of point# 1 (you can only edit one point per shape, hence I chose point ID# 1 to store that data) of sprite j and shape s has data for point k
if k = dragpointar[j,s,1]
setShapeX(j,s,k,px#)
setShapeY(j,s,k,py#)
endif
next
next
next
endfunction
I kept the dp=dp+1 for it was also used to keep track of the total number of points being editted, not that it serves any purpose any longer in the logic of collecting the point data for each shape.
This above code plays the role of making the shapes be modified dynamically with dropping the points constantly to where the cursor is followed by the redrawshapes() function to update the shape geometry in real time. It looks really nice.
There is one fundamental problem with the edit feature, it allows to modify polygon shapes even when the rules for creating them are borken. This lead to shapes being created that should not be and hence the GetSpriteHitTest() function doesn't work properly anymore with such incorrect polygon shapes. Not sure whether I will go into updating this to obey the polygon shape laws, Baxslash never included such logic for the edit mode, so I guess might be wise to avoid such potential nightmare of trying to implement that. In the case it will not be updated to that extent, one will need to be mindful when editing points of polygon shapes to keep the shapes concave.
Have a good night/day.
????????
