Funny errors you've made or run into?

[StormWingDelta]

Those little oops error that take longer than they should to find kind of errors.  The ones you spend a while hunting down and just laugh about later.

Just curious what some of those are.

In my case I was linking to a DLL file instead of a LIB file earlier and it didn't register on my brain until I checked what I had linked before. >_>

[Hapax]

I updated the linking to SFML2.3 but forgot to update the DLLs. When run (using 2.2 DLLs), it worked fine apart from pressing the middle mouse button triggered a left mouse button pressed event.

[Brax]

When SFML 2.3 came out, I updated my project to that version, and everything worked well (or was it? ).

A week or so has passed after I updated my game and I decided to test the release version of it. The mouse button pressed event didn't work, and I didn't have a clue why.

The very first thing I checked was the include\libraries path in the properties section of my project, following the SFML tutorials for Visual Studio. Everything seemed to be in order. After that I again copied-pasted the 2.3 DLLs, but they were not a problem.

After messing around with std::cout (because breakpoints and assertions does not work in release mode), and on another dummy project updated from 2.2 to 2.3 version (in which I made the same mistake!),  I figured that each time I press a button, a mouse button released event is generated! I then preformed a couple of checks and found out that SFML Debug and Release modes are not compatible.

And in typical C++ noob programmer manner, I convinced myself that I found a bug in SFML!!! I already made the complete and minimal example (in the same project), and was ready to post it on forums.

But then I decided to take one last check on project properties before I do post on forums, and guess what? The Release mod paths still pointed to the 2.2 includes and libraries. So you could say that last check saved me from embarrassing myself on the forums.

After fixing that, everything worked as intended.

[kitteh-warrior]

The other day, I was working on a VertexArray management class, so that other objects would "request" a quad to be created, and it would get a pointer of the 4 verticies created. Though, after requesting the next set of verticies, it invalidated the previous pointers. After a quite a few hours of wondering what is going on, I thought "What if the sf::VertexArray is just a std::vector of verticies?" Resizing a vector could cause references to the current data to be invalid, due to moving all of the data to another place in memory.

That was indeed the problem, because sf::VertexArray contains a std::vector<sf::Vertex>.

To verify that the code then worked properly after isolating that issue, I proceeded to create a version of sf::VertexArray that uses std::deque<sf::Vertex>, and it worked as expected.

[FRex]

    const sf::Time delta = sf::seconds(1.f / 60.f);
    sf::Time stock;
    sf::Clock clock;
    while(!m_quit)
    {
        stock += clock.restart();
        while(stock >= delta)
        {
            update();
            stock -= delta;
        }//while stock >= delta
        render();
    }//while not m quit

I wrote clock.getElapsedTime() in the first line of the while loop, which made the game go at a rate that is cubic in respect to time, instead of linear.

[Hapax]

I wrote clock.getElapsedTime() [instead of clock.restart()] which made the game go at a rate that is cubic in respect to time, instead of linear.

I'm sure we've all done this one 

[shadowmouse]

I did the opposite in that I had several things which need the time since last loop and instead of storing the time I put clock.restart() as a parameter for all the functions and everything basically stopped moving. Then again I've also done getElapsedTime instead of restart as well, so, I guess I'm incapable of using a clock correctly.