If you set t not linearly like I suggested:

Code Select Expand

      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.

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?

[EDIT:]

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/8a3d612ef7f36580ab97

EDIT: 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.cpp

EDIT 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.

[EDIT:]

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/b882e87a7eb210ae7b86
What I'm trying to achieve is draw a line of length 24 along the path, I cannot think of another way of doing it.

me again

Unfortunately I've encountered an issue with the path_get_x/y functionality. I'm using this value:

Code Select Expand

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

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.

Harri, can you add in the functions surface_destroy (which is missing) and path_get_position?

i did try the K2 demo you guys have and the game loaded (it uses 3d3 which is why i bring it up) but it cannot display the map (map.3d3) and i ran it in GM:8 Pro and it worked.

You mean the project k file I posted I presume? You need to put the map file in the main enigma directory for it to work. d3d is actually one of the most functional things in enigma at the moment, a lot of d3d games have been working for me after a little bit of editing. And I think you'll be very happy with the speed increase from GM to ENIGMA.

Does your game contain MP3s?

To add to that: does your game contain large backgrounds/sprites or in game settings constants or include files?

Those errors you stated do not affect anything. Try running the game in debug mode to see if it shows the problem.

[$]

Also, you declare "int FBO;" twice

oops. although I don't know why it doesn't error either...

I doubt its working right now because you don't execute path_update() anywhere yet

I execute it in the step event, like GM does. It has a check for whether the path extension is used before executing it so it's fine to work with extensions.

However you're right, it doesn't work right now because josh hasn't added support for local variables set in extensions to be modified in functions, at the moment it just completely corrupts the structure. With the actual path_update function you just need to use the path local variables (after they work) like path_speed, path_position, path_scale etc. you're probably more suited to that than me though since you wrote the paths.

$
oh and something else, can you tell me what happens when you enable windows widgets please harri?

[far]

It's fine I've sorted it. This is getting far too over-discussed it's beyond trivial 

Meh, the speed is nothing just gonna add an if inside screen redraw.

I definitely think it is a lot better to have control over it than have it hard-coded. I want control over what API's and extensions are set as well as those.

Theoretically using surface_is_supported() shouldn't be that big of an impact, but I am not sure. Does surface_is_supported() return 0 on your PC Poly?

Yes, it returns 0. I suggest maybe defining a variable stating whether fbos are functional, then ifdef'ing it. I don't really want the screen_redraw being slower either when I'm not using FBOs at all.

]pbuffers are old (out of date), a lot slower (on newer hardware) and more limited.

I know they're obviously going to be worse, but can offer them as an alternative to fbos for those that can't use fbos. I don't know anything about them though, so I'm unsure how well they could match what GM surfaces do.