this code was used in an example by Tottel, when we were going to test it, we found that there is another bug which might be for AMD cpus only, this failed to make the character move on two of my AMD computers .
but the character on my Intel CPU HTPC, and it ran on Tottel's computer and aceio76's computer all Intels.

I tried the standard movement code in Esenthel and it worked perfectly.
using the code above would result in allowing my AMD computer to only turn but not move.

all computers were using Windows 64bit.

movement is ok in EE1.0 C++ but not in EE2.0 EsenthelScript

input.move.z, is getting the correct value as to that it should move, but it doesn't, which makes me think there is an issue with the controller object.

Hi Zervox! I tried this code, I also have AMD (X2 4200+) and I've got the same result. And I also use Windows 7, but 32bit. So +1 for its AMD only bug.

maybe your code is wrong?
the result is stored as VecI (integer)

Did you try to debug and check what step gets wrong/different results?

(09-01-2013 10:40 PM)shadow Wrote:  

Code:

input.move.z=(Kb.b(KB_A)-Kb.b(KB_D)) * angle.x;

maybe your code is wrong?
the result is stored as VecI (integer)

I don't believe that code is wrong (it's always possible though). I simply multiply with the angle because I'm making a side-view game. My character goes left- and right, and the movement keys need to be inverted when the character turns. That is all that the angle does (positive or negative).
Even if you multiply the move.z with 100, it doesn't matter, since it's the player speed that defines the speed of the character, not this input.

You should try to make sure that move.z is -1, 0, or +1

Already did test that, it doesn't move even if move is -1,or 1 with the code above. The thing is this only happens on AMD processors on EE2.0 it seems.

Why are you doing this?

If the default game.chr movement code works ok, but yours doesn't, did you try debugging exactly which step goes wrong? (different results)

(09-03-2013 06:42 AM)Esenthel Wrote:  

Code:

Vec tempPos = Players[0].pos();
          Players[0].pos(tempPos);

Why are you doing this?

If the default game.chr movement code works ok, but yours doesn't, did you try debugging exactly which step goes wrong? (different results)

That's what it originally was. It's a side-view game, so I'm locking the character on the depth axis. I guess Zervox left it out for testing.

The question here isn't why something is done a certain way, the question is why the code behind this is getting different results while running on AMD or Intel, this is a runtime issue. the same compiled .exe using the movement code above will allow people to move on Intel but not on AMD(from the ones tested so far atleast), again this only happens when using EE2.0 code editor for compilation. Also note once again, it doesn't matter which computer cpu compiles it to a binary, it only matters which cpu is running it.

If this is an issue with Intel or AMD I really don't know, but in any case having this issue might potentially let a person do a ton of code only to find out later his project is completely broken on the other vendor brand. That is what worries me(the VERY different behavior, moving vs not moving).

This could be just rounding issue, for example what if values like 0.4999 or 0.5 could be rounded to 0 on one platform and to 1 on another, I'm not saying that this actually happens, but I guess different FPU's can have slightly different results.
You should do debugging, and see at which step you're getting different results

Yes, this is what is happening.

EE 2.0 uses PhysX 3 which has background processing of the physics simulation.
Perhaps you're having problem because Intel/Amd some of those cpu's finish simulating quicker than the other cpu, and the code is not compatible to work with background processing, for example the manual assignment of the player position each frame.

To the people who tested it:

Which CPU do you have AND what was your FPS?

I've noticed that if I have my FPS above 60, I can't move at all anymore. And this is on an Intel.

Hi Tottel, please check my previous post as I think it caught the issue.
Please focus on PhysX 3 being processed in background thread, and if you manually set the position each frame, then its velocities will be ignored, because they will get overridden by the position adjustment. Controller operates only on velocities. Please look into PhysX 3 documentation about background physics processing and manipulating positions/velocities in the meantime.
This problem is called "race condition" and it's not related to the type of the CPU intel/amd.
Solution is to not adjust the position each frame, but if you want to limit the movement in one plane, then just call Actor.freezePosZ or similar.

(09-06-2013 11:00 AM)Esenthel Wrote:  Solution is to not adjust the position each frame, but if you want to limit the movement in one plane, then just call Actor.freezePosZ or similar.

.. That solved it.

On my pc at least, I will send a build to Zervox as well to make sure.