[SOLVED] Anything that I can do to increase performance?


I was doing this to find the fastest player to go after, to remove time for turning. Probably a good idea to use the ball though.

    Vector3f leftDir = rot.mult(Vector3f.UNIT_X);
    Vector3f relativeLoc = heading.subtract(position).normalizeLocal();
    float dp = leftDir.dot(relativeLoc);
    if (dp > 0) {
    } else if (dp < 0){

rot can be replaced with the spatial equivalent, but position can’t without some extra changes.

public void moveFwd() {
    this.position = getNextLoc(1);
public Vector3f getNextLoc(int steps) {
    this.innerNode.setLocalTranslation(0.3F * steps, 0, 0);
    Vector3f newPosition = this.innerNode.getWorldTranslation();
    if (newPosition.x > GameLogic.boardSize) newPosition.x = GameLogic.boardSize;
    if (newPosition.x < -GameLogic.boardSize) newPosition.x = -GameLogic.boardSize;
    if (newPosition.z > GameLogic.boardSize) newPosition.z = GameLogic.boardSize;
    if (newPosition.z < -GameLogic.boardSize) newPosition.z = -GameLogic.boardSize;
    for (Crusher c : logic.crushers) {
        if (c.position.y < 1) {
            if (Main.colliding(body, c.shape)) return steps > 0 ? getNextLoc(steps - 1) : position;
    this.innerNode.setLocalTranslation(0, 0, 0);
    return newPosition;

A breakdown of my confusing spatials and nodes:

nonRotNode - Top level, dosen't rotate
    |- node - This one does rotate
        |- innerNode (I probably obsoleted this one, I haven't gone through everything yet, but it looks like i could just move this stuff to node.)
            |- body - varies by skin, the "ball"
            |- spear - varies by skin - the "pointy" thing
    |- name - Bitmap text of the username, I don't want this rotating

Whoah… you do some seriously odd things that make this harder. It looks like you rotate a parent and move a child? There is no good reason to do that and lots of bad ones.

It’s going to be impossible to factor tpf into your steps approach, also… so your game will speed up and slow down with frame rate.

You are better off just calculating a new position using forward direction and then clamping that to the board. You could do all of your positioning with speed and the orientation of the spatial.

Your ‘node’ structure should be:

node - rotates and moves
    |- body
    |- spear
    |- text with a BillboardControl

Move node, rotate node, find direction for node, etc… Your life will be 10000x simpler.

Vector3f fwd = node.getLocalRotation().mult(Vector3f.UNIT_Z);
node.move(fwd.mult(speed * tpf));

…where speed is ‘units per second’.

And to clamp position instead of move() you could do something like:
Vector3f pos = node.getLocalTranslation();
pos = pos.add(node.getLocalRotation().mult(Vector3f.UNIT_Z);
pos.x = FastMath.clamp(pos.x, -GameLogic.boardSize, GameLogic.boardSize);
pos.z = FastMath.clamp(pos.z, -GameLogic.boardSize, GameLogic.boardSize);

@pspeed (I keep forgetting to do this…(not hitting reply))

Remember that thread I used earlier? The update counter? It shouldn’t take me long to convert that to some subtraction and a variable…
Also, other aspects of the game call getNextLoc with values other than one, so it’s kinda vital.

I had the NPC place a box where it thought its target was, now I know it knows exactly where the target is. It appears to be having problems with the rotate code.

Well, you are moving a different node than you are rotating (by your description and code) so things are always going to be all kinds of bonkers.

getNextLoc(some random integer) is a super strange way to do things. You should be using tpf. Everything you do will be harder and unsupportable by this community with your current approach.

That’s the down side to doing everything in a totally unique and ultimately unnecessary way… we won’t be able to help you sort out your mess. There is no good reason to do this and certainly you haven’t provided one.

So at this point, I’m going to have to bow out until you explain why this is “required” (so I can convince you otherwise) or you rethink your approach. You have like 400 lines of code to do the job of 10.

Edit: just in case this is me bowing out… good luck with your game.

The reason for getNextLoc(updates) is because the other aspect of my game, the crushers, use it to calculate the position the player WILL be, that way they don’t just keep falling behind the player.

I’m going to go start working on tpf(Done) and those nodes now…
What is a BillboardControl though?

I Fixed it to work with tpf:

public float time = 0;
public static final float speed = 1f/30f;
public int updateCounter(float tpf) {
    time += tpf;
    int updates = (int) Math.floor(time / speed);
    time -= speed * updates;
    return updates;

Easier than I thought…

Pretty standard steering primitive type thing. In the roughly a dozen articles I’ve read on the subject, not a single one of them used an ‘int’ steps… instead, they use the speed of the target so that it scales properly with time.

there are javadocs on all of the classes:

If you don’t have this open all the time or one click away then go ahead and quit now.

Edit: and in case it’s the concept of “billboarding” that you don’t know… I googled that for you, too:


Are you getting satisfactory frames per second now?

Yes. The npc update loop was the killer.

1 Like