Video Game Blog
February 13, 2019
I was building in some test data to ensure things were laying out the way they're suppose to be - as the Play Map needs to be centered within the rectangle of its window. So in creating an automated fill of data where the "middle" Tiles should have a different color came up with a strange bit of fact, showing that there was a bug else where in my code. I worked out those bugs and returned to making my test data. And these appeared...
The original bug made my square map align one tile off both top-to-bottom and
left-to-right. When I cleared up that bug, it aligned the way it should have (as
it appears in this screen shot). I colored the middle Tile to show what I want
to be the center of the Play Window. In the case of games where an Avatar is the
center of the game, this is where it would be painted and the map would move
under it. But as for the other maps...
On the Square-Iso map, you can see that left-to-right is aligned properly, but
the top-to-bottom is WAY off! What the hell.., right? Before I go hunting for
this part of the bug, I have a sneaking suspicion already that because the height
of Isometric tiling takes up half of the width of the screen, that this is just
a formality of doubling the top-to-bottom value to get it to slide down the
screen. And because this error is present, I would think that this would hold
true for my Rhombus Isometric map, but...
wait for it...
What the hell is THIS..!!??
At least the left-to-right is lined up. But why would I have two horizontal lines
appearing from my test data? We'll tackle the previous bug(s) to see if one will
clear up the other. Hopefully so...
And to look at the Hexagon version of these...
This pattern is very strange in itself, but logical. I say this because with the
odd shape that Hexagons represent in a "square system", the calculation for the
"center" takes a little more work to achieve. Granted, the offset of the columns
and rows both go off into a direction that makes me think that is why things are
not aligned.
So as you can see...I've got a little work to get done before I can progress.
Okay, so I verified that my data going in was accurate. And there in laid most
of the problem. I was checking data from the Square Map to draw the other three
maps. Now...you can see that they are for the most part lined up (red spot in
marks the center Tiles). But, look at the Rhombus map. What is that? Everything
else lined up...Why would I get an offset of data like that?
This bug is absolutely repeating - meaning, no matter how many times that I run the program, the output is exactly the same. So, we've established a pattern. We just have to trace the data through the iterations to find out why the data being assigned is shifted one Tile to the right...but accurate for the rest of the time.
Well, the bug was found - as you can see. The root of it was the source data
memory allocated size. The Play Screen has a dedicated memory allocation that
later will get filled with data from data taken from files on the hard drive. The
number of Columns and Rows in this memory was a little too small to fit the
variable size of the Play Window that adjusts itself at game startup. While the
screen can be modified at start up, the memory has to be hard-coded in C++. Yea,
this could be a potential problem for people with really large monitors. I'll
code in maximum sizes later just to protect against any memory over-run. But for
now, I re-sized my memory allocation to handle the largest potential size on my
laptop. Yea...definitely have to write in some protections to keep you
big-monitor people from crashing my game! GRRR!
As a final note about the first screen shots showing this "double" bug on the Rhombus-Iso map...as you can see I solved the bugs in sequence from easiest to hardest. By taking out the easy ones first I was able to act with confidence on the hardest one. All in all, these fixes took me two hours to track down and fix.
More later!
