Yes, i have been hunting a bug for two weeks. Ok, i admit i procrastinated with side stuff like just to confirm that i am still able to write programs with syntactical meaning.

I am trying to stream in terrain tiles from my LOD algorithm (CDLOD after Strugar, height map extrusion), placing each tile where it belongs to in world coordinates. All went well, the selection algorithm put the bounding boxes of the selected nodes where they should be, the grid mesh used for rendering marched in correct order over the height map, and every other tile's heights were rendered correctly. Every other. Every not so other tile was just a huge flat (but correctly LOD'ed) grid. I spare you the pictures of a sad flat (but LOD'ed) landscape:-)

The error was that i had once switched texture lookups, like .zx instead of .xz for debug and to understand how lookups worked. I looked over that part at least 10 times, until it met my eye and waved to me.

Ok, ready to proceed to the next bug hunting :-)

Well, the best thing to avoid such time-consuming problems is test driven development. Write a test for every function/class you create. In your case, a good test would have failed and told you, that you have broken your algorithm the moment you swapped .xz for .zx.

However, writing good tests is not easy. Every time you encounter a bug, that is not covered by your test, you should add a specific test case. It requires a lot of discipline.

Another very useful tool is codecov (https://codecov.io/), which checks how many lines of your code are actually used. Combine that with your tests and try to keep the coverage at 100%. If your coverage is reduced after a modification, it usually tells you, that something is not tested for some reason. Most of the time this is related to branch statements that do not behave as expected.

I don't know how many hours of debugging it saved me, but before I started test-driven development, I spend hours and days hunting bugs like the one you mentioned. Now I can't remember the last time it took me more than an hour to find a bug.

A nice bonus feature of test driven development is, that you will usually start writing functions to avoid code duplications instead of using copy&paste. At least if you are a lazy person like me, you don't want to write a test more than once for identical code.

Greetings

12 minutes ago, DerTroll said:

... a lot of discipline.

There is exactly my problem.

I started out with a simple render framework, added blinn/phong shading, added buffer management, added texturing, a skybox, ellipsoid projections, UI overlay, then the heightmaps, afterwards LOD, now the streaming ...

I will have to do something, look into test driven development. Unit tests are on the plan. I promise. And after i've finished the streaming part i will spent 2 weeks solely on documentation.

Cheers ?

1 hour ago, Green_Baron said:

I will have to do something, look into test driven development. Unit tests are on the plan. I promise. And after i've finished the streaming part i will spent 2 weeks solely on documentation.

Hrhr... we'll see. For me, it was a long way until I discovered the value of test-driven development. There were so many more interesting things than writing tests. If I wouldn't have been forced to use it at work, I probably wouldn't have discovered its value and started using it in my private projects.

Luckily, I restarted with my engine anyways, so I could use it from the beginning. It is a lot harder if you didn't follow that principle from the start. Writing tests for all the code you have already finished is extremely boring. Same goes for documentation Get used to placing Doxygen tags over your function declarations when you write them.

Greetings

Am chatty today:

Who has never done an off-by-one error may std::throw the first stone :-)