I don't see why there would be differences between GL and DX other than the visual representation (even that should be the same though). Both systems use the same type (double) for direction and speed in the instance system (as the instance system is actually not connected to the graphics system). But floating point types cannot actually represent very small numbers. That is why you should never do hspeed == 0, but instead hspeed <= 0.00012 or something similar. That is true in every programming language. GM just seems to round some of its internal variables, like direction and speed.
I checked and we have direction as double, but only allow it to have integer values. So the calculation that sets direction from vspeed is this:
*dir = int(180.0+180.0*(1.0-atan2(rval.d,*hspd)/M_PI))%360;
*spd = hypot(rval.d,*hspd);
Where rval.d is the set vspeed and hspd is the hspeed. This basically means that we evaluate "180.0+180.0*(1.0-atan2(5,0)/M_PI)" to something very close to 270, but not quite (269.9999999) and when we cast to int it truncates the decimal part, so we get left with 269.0. What I can do is just add a rounding there. This will fix this issue.
Also, you should probably use either GL1 or GL3, as DX systems are not as thoroughly tested and developed.
I'm not sure I will try to fix the speed not equaling zero, as that shouldn't be an issue even in compatibility with GM. You just should check ranges, not total equality.
Will have to investigate that weird DX bug, where it actually goes into reverse. Doesn't make much sense in my mind right now.
edit: Direction is rounded in this branch:
https://github.com/enigma-dev/enigma-dev/pull/929 and in this commit:
https://github.com/enigma-dev/enigma-dev/commit/0e358861fba53e7b6898df3696e94fc4fb2a3948At some point it will be merged into master.
edit2: I honestly cannot tell why in DX mode the precision is different then in GL. Maybe some compiler options are changed which causes this. In GL is goes to E-12, while in DX only to E-06. So in GL the vspeed == 0 holds true, while in DX it does not, so the speed is decremented more. The proper fix for this is to actually test vspeed < 0.001 or we could just provide a special function for that (we do use one internally) or an epsilon value (precision) that can be checked against. So you could write vspeed < double_epsilon or something. Either way, I don't know if we want this for GM compatibility. As hspeed and vspeed are special variables, we can internally maybe do these checks and set them to 0. But I don't think we will do this for custom variables. So if you decrement your own variable, then you should check it yourself.