SetRotation() Sometimes causing Sprite to not draw.

[TestZombie]

Ok, second time:

this line of code:

Sprite.setRotation((atan2(ty - y, tx - x)) * 180 / pi + 90);

is used by the player class, and npc class, and their projectile bullets, to point at a specific point (tx, ty).

While the same code is being used in different places, the npc sprite, and the npc's projectile's sprites fail to draw. also, the npcs and the player use the same projectile class.

The most confusing part of this issue is that it works fine in the player class, but casues the sprites to break in the npc class. when the line is removed, the sprites do draw (but obviously don't rotate).

Not really sure what code you'd like to see, as the only other sprite manipulation in all cases is

Sprite.setPosition(x, y);

Win.window.draw(Sprite);

tx/ty vars:

(click to show/hide)

        srand(Frames);
        switch (rand() % 5)// tx, ty
        {
                //--
        case 1:
                tx = x - (rand() % 1000);// +30000 x
                ty = y - (rand() % 1000);// +30000 y
                break;
                //-+
        case 2:
                tx = x - (rand() % 1000);// +30000 x
                ty = y + (rand() % 1000);// -30000 y
                break;
                //++
        case 3:
                tx = x + (rand() % 1000);// -30000 x
                ty = y + (rand() % 1000);// -30000 y
                break;
                //+-
        case 4:
                tx = x + (rand() % 1000);// -30000 x
                ty = y - (rand() % 1000);// +30000 y
                break;
        }
 

initial x/y vars

(click to show/hide)

        switch (rand() % 5)// x, y
        {
                //++
        case 1:
                x = Player.x + (rand() % (575) + 425);
                y = Player.y + (rand() % (675) + 325);
                break;
                //+-
        case 2:
                x = Player.y + (rand() % (575) + 425);
                y = Player.x - (rand() % (675) + 325);
                break;
                //--
        case 3:
                x = Player.x - (rand() % (575) + 425);
                y = Player.y - (rand() % (675) + 325);
                break;
                //-+
        case 4:
                x = Player.x - (rand() % (575) + 425);
                y = Player.y + (rand() % (675) + 325);
                break;
        }
 

move x/y vars

(click to show/hide)

{
        /////////////////////////////////////////////////////////////////// Rotate
        //Sprite.setRotation((atan2(ty - y, tx - x)) * 180 / pi + 90);
        /////////////////////////////////////////////////////////////////// Accelerate
        //xS += ((x - tx) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;
        //yS += ((y - ty) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;
        /////////////////////////////////////////////////////////////////// Max Speed
        if ((xS >!mS) & (xS <! -mS))
                xS += ((x - tx) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;
        if ((yS >!yS) & (yS <!- yS))
                yS += ((y - ty) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;
                /////////////////////////////////////////////////////////////////// New to coords
        if (sqrt(pow((tx - x), 2) + pow((ty - y), 2)) < 100)
        {
                to();
                xS = yS = 0;
        }
}
 

[Rhimlock]

Is your switch-statement missing "case 0:"?

Check the values your are using to calculate your rotation.

[StormWingDelta]

Is your switch-statement missing "case 0:"?

Check the values your are using to calculate your rotation.

While it is missing a case 0: it is also missing a default: as well for catching things like this.  Default cases are good for when you are unsure if you've got all the cases and/or catching errors as well.

[Nexus]

This low-level trigonometry code is not only insanely hard to read, but unnecessarily slow. Consider the use of higher-level vector algebra, e.g. the functions from Thor. It will increase development speed and reduce maintenance and debugging efforts.

Instead of

xS += ((x - tx) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;
yS += ((y - ty) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;

you write:

s += thor::unitVector(v - t) * speed;

Now tell me which one is more readable.

if ((xS >!mS) & (xS <! -mS))
if ((yS >!yS) & (yS <!- yS))

What exactly are you trying to achieve with those signs? <! and >! are neither digraphs nor operators, you're doing something terribly wrong here.

(675)

Another WTF snippet
These parentheses don't contribute to operator precedence.

While it is missing a case 0: it is also missing a default: as well for catching things like this.  Default cases are good for when you are unsure if you've got all the cases and/or catching errors as well.

When you're unsure if you've got all the cases, you have a serious problem, because you don't understand your program's logic.

By adding a default: case in such a case and performing regular logic (or nothing) inside it, you prevent possible compiler warnings and hide logic errors. The only sane thing to do in such a "catch-all" default: label is an assert(false);, because this branch of execution shall never be reached in a well-written program.

Note that I'm not talking against default: when its intention is clear, but against the practice of adding it "if you're unsure".

[TestZombie]

Ok, yes my code is very messy, xD. I did fix several of the horrible things that occurred in my horrible copy paste job.
And as for the extra (), There were a few values in there before, but i removed them and just left the parenthesis out of laziness, I usually go back through my code afterwards to clean up mess like that.

I have no idea where the <!'s came from but wow.

I do like this more:

yS += ((y - ty) / sqrt(pow(x - tx, 2) + pow(y - ty, 2))) * speed;

mostly because I don't have to figure out what thor is, and how to use it,

I did add defaults with break points on them, and I took care of case 0:
the tx,ty,x,&y values seem to all be fine

despite going through clean up, I still have no idea.

[Jesper Juhl]

By adding a default: case in such a case and performing regular logic (or nothing) inside it, you prevent possible compiler warnings and hide logic errors. The only sane thing to do in such a "catch-all" default: label is an assert(false);, because this branch of execution shall never be reached in a well-written program.

Note that I'm not talking against default: when its intention is clear, but against the practice of adding it "if you're unsure".

My personal preference tends to be to use (with gcc/clang) the "-Wswitch" flag which causes a warning if a switch does not handle all possible cases and then also use "-Werror" to turn all compiler warnings into errors. Then I know when I fucked up and forgot to handle a case and can deal with it (usually by explicitly handling it, but possibly by adding a default) before I even try to run my code.

[Nexus]

My personal preference tends to be to use (with gcc/clang) the "-Wswitch" flag which causes a warning if a switch does not handle all possible cases and then also use "-Werror" to turn all compiler warnings into errors.

The problem with that approach is that it forces you to write default: so often that it almost becomes a defensive automatism. At least that was my impression...

The best example is the event loop that most SFML programs have:

switch (event.type)
{
   case sf::Event::KeyPressed: ...
   case sf::Event::MouseMoved: ...
   default: /* must always be here, although unnecessary */
}

It's of course a matter of preference. I'm not a big fan of empty default: cases (never been ), and I think I don't make enough mistakes in switch statements to justify adding unnecessary code everywhere