Might need to increase checks per move.

Collision on moving objects is not so simple. Most time you divide the distance by n increments. If too jittery,

If multiple moving objects then you need to take each object and increment based on each object's velocity / n. If still too jittery, then increase n.

@DanielH Good idea. I've implemented it and moving works perfectly now. When I increase the speed of the move, it always arrives to its destination.

However, the jitter it still there. For example, if I take the same circle and let it react to key press to move on x or y axis, it moves but it's jittery. When it starts, it travels lets say 20% of the distance, slows down and then passes other 80% consistently, all while I'm holding one arrow key and not doing anything else. Random example but you get the idea, inconsistent.

I'm assuming it could be something related to framerate (I'm using 60 fps rn). For example, I'm thinking I could iterate [0-fps] and move by (axis offset/fps) distance.

@Indeterminatus Nothing special there but sure, here it is, before the adjustments that implement steps.

bool Vec3::translate(double a, double b, double c){
    this->x += a;
    this->y += b;
    this->z += c;
    return true;
}

Sure.

Main loop is standard event handling.

Circle.cpp handles instantiation, clipping to screen and rendering.

Yeah, well, I guess this isn't really for me. I'll probably go back and do embedded in C.

Thank you for your help though. All the best.

Hello Edgar, 

I'm not giving up because I can't solve some issue, be it a graphics problem or not. I have solved many complex issues before. The thing is, I got fed up with C++ and with OOP in general. This is something I wanted to ask either on Reddit or StackOverflow. Ask for some advice, and I'll probably do it at some point.

I really like C's simplicity. C++ has much more functionality, but I dislike it. I don't like its complexity; it's gotchas and 300 different ways of doing things. 

I like simple functions and simple structures, i.e., C. The only things I used in C++ that are not in C are private struct/class members and class member functions. 

I genuinely wanted to learn C++ and OOP. I devoted 1–1.5 years to learning it every day. Yet, when I was learning templates, STL, and (god forbid) design patterns, I had the urge to vomit because of their convoluted nature and attitude of "do this, is good" and, after a year or two, don't do that, it's bad; do this instead (e.g., malloc -> new -> smart pointers).

I then lost a job because of this. I did 80% of the project myself in the OOP language, using light abstractions and mostly simple functions. Simple, straightforward, and easy to test and change. It works. Yet, a person comes to the project after 2 months and wants to rewrite everything so it fits into that nice, round OOP bullshit. When I objected, they kicked me out.

That's the reason I want to call it a day. I'm just fed up with all that OOP crap. At least, if I go and do development in C, I won't have to deal with it. That Linus quote about C++ is always hovering above my head. And I don't think I can find a job with C in game development; it is mostly C++ and, to some degree, C#.

Sorry for the long post.

Well, to be honest, it looks like you're reading my mind. I did learn C++ from Bjarne's books.

Me losing a job was a bit rough, but the way I see it, it might be a blessing in disguise.

I understand the rationale behind STL, design patterns, and similar, but I don't think it's a good language (or not for me, at least). It's a cacophony of different techniques and approaches; it's gargantuan, and it will probably be replaced by some other language since it refuses to break compatibility. I try not to reinvent the wheel, but if I'm learning some algorithm, I want to focus on its functionality and not be anxious about something exploding into my face.

At this point, I'm more interested in learning assembly and (maybe) Rust. At least, when I'm working in assembly (or C), my mind is at peace.

Damn, that sounds interesting. I'd love to hear more about that. 

The first time I got in contact with assembly was when I saw a guy writing a game using a Motorola 68K on Computerphile. I found some kind of sandbox for it (easy 68k) and wrote a couple of programs for it. 

After that, I left it and focused more on C/C++. As the time passed, I wondered how certain C/C++ constructs translated to assembly. I started disassembling code at first, and after that, I dived in fully to learn it.

Architecture is x86-64; first I did it in nasm, but I didn't like the syntax of it and switched to GAS.