polygone
|
|
Posted on: May 20, 2012, 08:56:59 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Harri, can you add in the functions surface_destroy (which is missing) and path_get_position?
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
TheExDeus
|
|
Reply #1 Posted on: May 21, 2012, 08:36:03 am |
|
|
Joined: Apr 2008
Posts: 1860
|
surface_destroy (which is missing) Its called surface_free in both GM and ENIGMA. It was briefly called surface_destroy() in ENIGMA (until I found this mistake). If you want, then you can create a macro or a wrapper so you can use surface_destroy() as well, but I think we should standardize and use one whenever possible (this case _free, for compatibility with GM). We could also add both functions, but document only _destroy() and leave _free() undocumented for GM compatibility. path_get_position And what would it return? The 0-1 position on the path? But path_position is part of the object struct you created, so you might as well create the function. I don't use or save any variables between frames, so I don't have any "position" I could return.
|
|
|
Logged
|
|
|
|
polygone
|
|
Reply #2 Posted on: May 21, 2012, 10:23:02 am |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
surface_destroy (which is missing) Its called surface_free in both GM and ENIGMA. It was briefly called surface_destroy() in ENIGMA (until I found this mistake). If you want, then you can create a macro or a wrapper so you can use surface_destroy() as well, but I think we should standardize and use one whenever possible (this case _free, for compatibility with GM). We could also add both functions, but document only _destroy() and leave _free() undocumented for GM compatibility.
Oh I didn't realise, it was with testing a game that you previously made so that will explain it as I presume you used the wrong name with it (note you might want to update some of your edc game files). But yeah there should probably still be a wrapper for surface_destroy to surface_free. path_get_position And what would it return? The 0-1 position on the path? But path_position is part of the object struct you created, so you might as well create the function. I don't use or save any variables between frames, so I don't have any "position" I could return.
It was thinking of path_get_point_position(ind,n) much like the other path_get_point_* functions. But when actually looking at it, I see this wouldn't be nice to do.
|
|
« Last Edit: May 21, 2012, 11:46:09 am by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
polygone
|
|
Reply #3 Posted on: May 21, 2012, 05:32:20 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
me again
Unfortunately I've encountered an issue with the path_get_x/y functionality. I'm using this value:
v = path_get_x(pth, 24/path_get_length(pth)) - path_get_x(pth, 0) //to note the path length is around 13500, which is roughly the same in GM and ENIGMA The place it's checking is completely flat (y values are same) so it should be returning 24 and it does in GM, but in ENIGMA it is returning completely wrong like 2.322
|
|
« Last Edit: May 21, 2012, 05:58:17 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|
polygone
|
|
Reply #5 Posted on: May 21, 2012, 07:01:08 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Not sure what you mean. Position argument in get_x function should be from 0 to 1, so I am not sure why you do 24/get_length. Maybe make an example? I know that there are some problems with get_x and get_y functions (they don't match GM's exactly), but the difference shouldn't be that big.
24/get_length is between 0 and 1, it's 24/13500 which is 0.001846 I'm using that as it should be get the x position 24 pixels from the start, but it's returning 2.322 pixels from the start. I'll make an example though. EDIT: Here is example https://www.box.com/s/b882e87a7eb210ae7b86What I'm trying to achieve is draw a line of length 24 along the path, I cannot think of another way of doing it.
|
|
« Last Edit: May 22, 2012, 09:40:53 am by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
TheExDeus
|
|
Reply #6 Posted on: May 23, 2012, 02:53:23 am |
|
|
Joined: Apr 2008
Posts: 1860
|
Looking at the example I must say that it is normal. I didn't think you have a path that is so long. On very long paths this difference is a lot bigger. If you make it go around the path at constant speed, then you will see that it will slow down at times and go faster at other times, that is what creates this error. Me and Josh were not able to fix that problem, as theoretically (mathematically and code wise) everything should be fine. Maybe I will look at it again at some point. Basically, the problem arises (I think) from wrong length calculation. I need to calculate the length of each segment and then divide by total to get the position on where one segment ends and another begins, and while I tried 3 different algorithms for that (which returned almost the same values) I still was not able to fix that problem... maybe the problem is somewhere else then. I won't have time to look into this for a few weeks now (need to do my thesis).
edit: Poly, the "precision" thing I used and you as well in functions like path_get_direction should probably be like 1/path_get_length, because now if the path is very long then it could return wrong number. Although 0.0005 seems reasonably small.
|
|
« Last Edit: May 23, 2012, 06:34:01 am by HaRRiKiRi »
|
Logged
|
|
|
|
polygone
|
|
Reply #7 Posted on: May 23, 2012, 08:28:26 am |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Yes, I can see it works out when you go all around the entire path. But this error produces a big problem when trying to achieve what I am; to draw a line of a certain length along the path. The fact that this isn't returning correct at a point which is completely straight shows that part of the algorithm must be fundamentally wrong, GM manages to return precisely the correct length. And it's nothing to do with the total path length, you're multiplying back by that in the t value so it doesn't matter. Using a path with 3 points in a straight line produces the same problem: https://www.box.com/s/8a3d612ef7f36580ab97EDIT: OK I just checked with a straight path instead of smooth and everything is perfect when using a straight path. But like I said, I don't see how it could be wrong going between two points on a horizontal straight line. The smoothing doesn't affect the path between these points at all. For anyone else interested, it's the path_getXY function: https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Universal_System/pathstruct.cppEDIT 2: OK, after looking at it for a bit, firstly I think the method should be changed to a fourth-order equation so it takes points behind it into account but that's a completely different story. But back to the problem, I presume now that you're right about the length being the issue and the problem with this is the t length calculation needs to be set non-linearly when using a smooth path.
|
|
« Last Edit: May 23, 2012, 12:01:22 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
TheExDeus
|
|
Reply #8 Posted on: May 23, 2012, 12:04:37 pm |
|
|
Joined: Apr 2008
Posts: 1860
|
And it's nothing to do with the total path length, you're multiplying back by that in the t value so it doesn't matter. Not the total path length, but the length of each segment. The smoothing doesn't affect the path between these points at all. The short answer is that it does affect it. fourth-order equation Then it will not look like interpolation used in GM. The length itself is actually correct (that is why total length is correct as well), but the "distribution" is wrong, in that point 0 has length non-zero while in linear paths its correct (zero). The problem is that the quadratic bezier spline does not start or end at the points, but between them. Here is a picture I made in last august for Josh: https://www.dropbox.com/s/cth3rda3lh0q8na/path_interp.pngI will look into some methods on how to fix that.
|
|
|
Logged
|
|
|
|
polygone
|
|
Reply #9 Posted on: May 23, 2012, 01:30:55 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
hmm, I've just been looking over things I see that when you're calling pth->pointarray[ppi->second].length it's half the value when the path is set smooth. Why is that?
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|
polygone
|
|
Reply #11 Posted on: May 23, 2012, 02:15:48 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
If you set t not linearly like I suggested:
if (pth->smooth) t = sqrt((position - ppi->first) * pth->total_length/double(pth->pointarray[ppi->second].length)); else t = (position - ppi->first) * pth->total_length / double(pth->pointarray[ppi->second].length); This then sets the 24 correctly and the total length of the path is still correct. However it then becomes not smooth at later points in the path.
|
|
« Last Edit: May 23, 2012, 02:25:42 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
TheExDeus
|
|
Reply #12 Posted on: May 23, 2012, 02:46:44 pm |
|
|
Joined: Apr 2008
Posts: 1860
|
And using this code:
static inline double blen(const path_point* p0, const path_point* p1, const path_point* p2) { double x1=p0->x, y1=p0->y, x2=p1->x, y2=p1->y, x3=p2->x, y3=p2->y, length=0,/*lx=0.5*(x1+x2), ly=0.5*(y1+y2)*/lx,ly,x,y;
double t=0.5; lx = 0.5 * (((x1 - 2 * x2 + x3) * t + 2 * x2 - 2 * x1) * t + x1 + x2); ly = 0.5 * (((y1 - 2 * y2 + y3) * t + 2 * y2 - 2 * y1) * t + y1 + y2); t+=0.05; for (int i=0; i<=19; i++){ x = 0.5 * (((x1 - 2 * x2 + x3) * t + 2 * x2 - 2 * x1) * t + x1 + x2); y = 0.5 * (((y1 - 2 * y2 + y3) * t + 2 * y2 - 2 * y1) * t + y1 + y2); length += hypot(x-lx,y-ly); lx = x, ly = y; //std::cout << "i: " << i << " t: " << t << "length: " << length << " x: " << x << " y: " << x << " dx: " << dx << " dy: " << dy << std::endl; t += 0.05; } return length; }; You can get correct lengths for points when in straight line, but this is still not correct, because lengths for curved path is still wrong (by as much as 200 pixel difference between GM and ENIGMA for a simple path). I still don't have time to do this right now, so I will have to postpone it. Maybe you will be able to figure this out.
|
|
|
Logged
|
|
|
|
polygone
|
|
Reply #13 Posted on: May 23, 2012, 05:22:33 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Meh, I'm still looking at it. Not got anywhere though.
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
polygone
|
|
Reply #14 Posted on: May 23, 2012, 09:50:32 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
I give up, don't think I'm gonna work it out.
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|