Why do I keep getting all the weird tool bugs?You're too deadly for normal bugs, so they went to plan B, and attack you indirectly by hiding in tools.
When you realize how dumb a bug is...
Spent 20 minutes figuring out why a C++ macro doesn't work as intended.
#define TIMER_SUM_END_NAMED (x,str) use_x_and_str_here
[spoiler]Space between define name and (x,str) must be removed: TIMER_SUM_END_NAMED(x,str)[/spoiler]
Spent 20 minutes figuring out why a C++ macro doesn't work as intended.
[spoiler]Space between define name and (x,str) must be removed: TIMER_SUM_END_NAMED(x,str)[/spoiler]#define TIMER_SUM_END_NAMED (x,str) use_x_and_str_here
One of many reasons why templates are a hundred times superior to define macros and their weirdness... :)
Why do I keep getting all the weird tool bugs?You're too deadly for normal bugs, so they went to plan B, and attack you indirectly by hiding in tools.
Considering how once I got a game to travel backwards in time by pausing it, I think you probably aren't too far off from the truth.
void Engine::startEngine()
{
init();
mainLoop();
testTexture.loadTexture("data/texture/sprite_000.png", mGraphicModule.getRenderer());
}
Copy and paste has got me to many times now <_< haha
// Collision player
if (AABB(m_Ball->GetQuad(), m_Paddle->GetQuad()))
{
m_BallState = RIGHT;
}
// Collision AI
if (AABB(m_Ball->GetQuad(), m_Paddle->GetQuad()))
{
m_BallState = LEFT;
}
I only realised it was not working when i added a camera frustrum freeze function in to test the asset occlusion. At that point I've started looking at the frustrum code. Nothing wrong. So i moved on to visually displaying the bounding box of each leaf. It's displaying bounding boxes but they are all long and thin. Now I'm thinking I've stuffed up rendering of bounding boxes. No. It's working.
Finally. After accepting that the boxes are indeed correct o go back to my quadtree generation. After 5 minutes i realise i had cleaned up a calculation and placed a + where a - should be. And it's been there for a month or so.
Few days ago I used 5 hours to write a long piece of code and there was a bug somewhere I couldn't find, I wasted like 3 hours searching for that bug but never found it. On the next day I deleted all that code and re-wrote it pretty much the same and it worked fine.. I'll never know what it was, probably used int instead of float or something like that and didn't see it...
Like an artist becomes "blind" to his work and can't see the mistake when others can. That happens sometimes to me, can't see the mistake in my own code when I've been working on it hours and hours straight.
Like an artist becomes "blind" to his work and can't see the mistake when others can. That happens sometimes to me, can't see the mistake in my own code when I've been working on it hours and hours straight.
An artist trick is to hang your painting on a wall somewhere where you'll see it by accident before you remember it's there, and it'll let you take in the whole picture for a moment before you get into "artist mode".
I wonder what an equivalent programmer trick might be? Maybe it'd help if there was a switch in the IDE that swapped to a different color-style and a different spacing/curly-bracket style, (and maybe randomize the variable names to animal names ("tiger = 27", "aardvark = (panda - dragon);"), so you temporarily feel like you're reading someone else's code. Hit the switch, go for a ten-minute jog, come back and read "Bob's function" which you have to learn fresh.
The problem in many cases is that you read what you think you wrote, not what you actually wrote. That tends to contribute to typos being so hard to find. Once you're tired of looking for an obvious mistake you'll just start rereading everything carefully again just to try to overcome that issue.
Of course there's also the complementary problem where you waste the whole day looking for a dumb typo, and then you realize the problem is that the algorithm is broken in the first place...