Version 1.1.7 has been approved by the Asset Store team. I fixed a small typo that prevented the menu item for adding the GFGridRenderCamera component from working and I added two more examples, video tutorials will follow soon. I also redid the screenshots because the Asset Store ate my old ones somehow.
I've written two new examples, one that takes a plain text file and parses it to create a breakout-style level based on a grid without changing the scene, the other is a continuation of my grid-based movement example where I can place obstacles on the grid and the sphere will not step on those squares (without using any physics like collision and raycasts). Sadly I can't update Grid Framework because I can't log into my account via Package Manager. My account still works, I can log into the forums and my Publisher Administration, so the problem must lie within the editor. I've submitted a bug report, but until then I cannot publish updates. If you are interested in one of those two examples please contact me over the Unity forums and I'll send you the examples, provided that you already own Grid Framework. On a related note, it appears that Grid Framework's product page in the Asset Store doesn't have any screenshots. I did submit screenshots, but they don't appear for me, I don't know if other people can't see them either.
Important Note: The classes Grid and RectGrid have been renamed to GFGrid and GFRectGrid, you will need to change your source code accordingly.
As per request the custom rendering range now affects drawing as well, not just rendering. If you are wondering why this wasn't the case before, it was a leftover from before the custom rendering range got implemented. Originally the custom range was only meant for rendering because that would be what the layer sees in the final game, not the drawing, whether they are the same or not. Also, the drawing is only a drawing, the grid keeps working beyond what's visible, being infinite. That's why the drawing had low priority and I worked on other parts instead.
Version 1.1.4 has been approved. It doesn't add anything new for a change, instead it fixes a bug where lines with a width larger than 1 were drawn on top of things they were supposed to be under.
Here's a quick status update:
I have finished the drawing part for hex grids. As I mentioned before, there are many ways to draw hex grids and I want to cover as many of them as possible. Let's count all the possibilities that work now.
I've decided to go with one HexGrid class and provide enough options. To do this I will need to swap around variables so I can use the same formulae for different cases. I could write the swapping part where it is needed, but then I'd be writing the same thing several times (which is a bad thing to do). Wouldn't it be better if there was some sort of swapping function? Could that function work for any type of variable? Could it work without needing to reassign variables again? Yes to all of that:
It has been over a week since my last post, so I might as well explain what's going on. As I finished rendering I had tightened up all loose ends that were left, I consider Grid Framework to be complete for rectangular grids. You can perform all the common calculations, debug things and visualize the grid properly, either using simple lines or even Vectrosity. This is just the first step though. Hex grids are very popular for games for various reasons, so it makes perfect sense to do them next, right? Well, here is where the problem starts.
You know, sometimes I look at something and wonder "what kind of idiot designed this!?", only this time I was the idiot. Let's say you wanted to render a simple 3x3 grid and you wanted the origin to be in the lower left corner. Well, you simply couldn't do that, not until now: