Function causes a crash
-
@Hector1945 Glad you solved it , the unrecognized type 4 error probably went from adding a value to a not properly initialized array (or reading from a such). (Because of wrong dimension, index). Is it technically a 'void' type? What means its just pointing to a place in memory, but its not clear yet, what the bytes mean there: number, string, array. If somebody knows for sure please comment on this. It would be nice to know for sure.
-
Oh no it isn't solved ! I now have a lead though, because apparently it does come from the trail[0] = [{ball.x,ball.y},moving] because if I replace that line by trail[0] = 5 or any random int, then it doesn't crash ! I just don't know how to solve it, because when I try I get an unrecognised type 4 error.
-
Ok, is
movinga global variable? To test if this is the problem, add a line before:
moving = false
Which will make sure it is declared implicitly as a boolean and defined as false. -
I tried, and it still crashes.
-
What is
trail[0] = [{ball.x,ball.y},moving]supposed to accomplish anyway?It looks like you are assigning an array containing a vector and something else to trail[0]?
And then you treat the result as an int?
-
No I treat the result as an array of a vector and a boolean. The vector is used to log the 50 most recent positions of the ball, in order to make a trail that follows the exact path of the ball, like in the reference video. The "moving" boolean is used to determine if a trail should actually be drawn to that point. There might be a better way of doing this, but I haven't figured it out.
-
Sorry, I didn’t read the code properly. Now I see how you do it.
Not sure if it would help, but maybe using a struct would be better and then having an array of structs instead?
-
Did you change the loop? Backwards loops in Fuze do not work as one would suspect.
I find it is always better to use a while loop instead and handling the counter yourself in those cases.
-
You mean making a for() loop as a while() ?
-
Yes, exactly.
-
Wait, I'll try the structure idea first.
-
Another thing I would try is to use a struct, and instead of line 70, do
trail[i + 1].location = trail[i].location trail[i + 1].isMoving = trail[i].isMoving...or similar.
-
Ok, so switching to a structure doesn't appear to change anything and I still get the crash, so now I try the while()
-
I hope something works. I’m not close to my Switch at the moment (not until next Monday actually 😢), so can’t really try out any ideas.
Maybe you can share your program, and I’m sure there is someone who can figure it out?
-
Yes I think that's what I'm going to do, because I'm really starting to run out of ideas of what could cause this...
-
The program is now live. Here is the code of you want to experience this yourself: NX29ZPFDDA. Please contact me if you have any idea of what is causing the crash.
-
When you run the program with fps meter showing your using a megabyte a second.
I put deleteshape(trailportion) after drawshape(trailportion)
And moved
Shpball = create etc
Shpground and shpnet out of the function drawsprshapes()
This slowed down the memory loss but it's still losing memory (Maybe?)
For fps go to settings then preferences and you'll see it towards the bottom
The problem your having is you are creating a new thing every time you call these functions.
This is a pretty neat program. Well done. -
Oh and it's possible for the ball can come to a complete stop.
-
@xevdev I put a timer to reset it if it doesn't move for 1 second
-
Anyway, thanks for saying it's a neat program, and thanks for the idea of deleting the shapes, because that apparently solved the issue. I don't really understand because wouldn't the old value be deleted anyway when you assign a new one to a handle ?
