Help with hex map logic

Hi All,
Sorry if there is already a thread on this I have tried the search engine but couldn't find anything relevant.

My (noob) question concerns using a hexmap that is bigger than the form I'm using to display it and how to scroll through it.

The map itself is of fixed size (19/61); because I want the individual hexes to be quite large the whole map is much bigger than the form I can display on my laptop. I have code to draw the hexmap as graphics objects (using draw polygon and fillpolygon) and it works well for the visible area. In order to force the scroll bars to appear I've placed a button at an x,y position just further away than the farthest bottom corner of the final hex. My issue is that the only part of the map that displays is the section that would be visible on the unscrolled part of the form.

I think my problem is more to do with the logic of how I implement the map. Should I be creating graphics objects and somehow redrawing correct hexes as the scroll bars move or should I be creating a bitmap and updating it every time I make a change? Or is there a more elegant solution?

The hexes themselves will change colour to show who owns them plus display which forces are currently in the hex.

Any help would be appreciated.

Welchbloke

Well imo it depends upon the map. If the map is non-cylindrical in nature, the simplest would probably be to just use a panel with autoscroll. A cylindrical map (going out of the map in a specific direction lets you enter the map in the farthest opposite direction) would be simplest implemented by just drawing the required portion of the map to a fixed size control (which would require {roughly} an equal amount of time for any size map).
I'm assuming that what you call a hex map is what I would call a honeycomb (ie. haxagons without spacing). I have an old implementation of a multi-textured hexagon map with spacing implemented in XNA (c#) lying around somewhere, and I could easily convert some of it to VB graphics code, should you wish for an example. Eventually though, I think you will abandon the VB graphics implementation, since it will be too slow for anything besides very simple and small maps (ie. adding resources, cities, units etc. on a map with something like 200+ map-cells visible will begin to lag when scrolling it with the mouse).

I think you need to elaborate a bit more on what you're looking for. Is it an example of more in the line of advice?
Do you need by-pixel scrolling of the map or is by-cell sufficient?

Tom

Tom, Thanks for the response.
I've implemented a bitmap solution at present. I've created a picturebox that I draw the map to at runtime. Your map definition is correct it is a honeycombe design. I relaise I should have mentioned a bit more about what the map is for. I'm creating a playaid for myself for a board and counter game called Federation and Empire (mainly so that I can learn OO coding; the last time I did any coding it was in Turbo Pascal and FORTRAN 77 :) ). The map shows all the things you'd expect like who owns it(using colour), any units on the map(represented as fleets or inidividual units). The total number of cells is 1159 and the information on them is held in an Access DB along with all of the other game data. I've encountered some slowdown already; however, I believe it is down to the time taken to open and read from the DB rather than drawing the map.
I'm not sure that I require anything other than using the scroll bars at present. Who knows in a couple of weeks I might have realised I've been a complete idiot and need to scroll by cell or pixel.

What I'm working on at present is an efficient method of drawing additional lines to mark out province and race borders. The province borders are all fixed, what I need to do is work out how to calculate the various points for the line drawings without having to enter them all by hand in the code. The problem is that they are not regular sizes. I'd forgotten how much fun coding could be :)

Welchbloke

Welchbloke

Well the easiest (though potentially rather memory-heavy) solution in this case imo is:
1) Copy all information from the DB to some kind of memory data-structure and use the DB only when loading/saving a game.
2) Instead of drawing to a limited size bitmap that fits the current view, draw the entire map to a image and store it in a picturebox (let's call it PB1) with SizeMode=AutoSize (this ofc only applicable if your map has a size that dosen't require many MBs of image data).
3) Place PB1 in the top-left corner of a Panel with AutoScroll=True.

and voila you can scroll around the map (NOTE: 1) is ofc not required, but will increase the speed of updating the map considerably).

This might not be exactly what you need though, but adding a couple of scrollbars on the side of the picturebox and writing code for generating a limited portion of the map, will probably require a bit more info (or a tad of code) on how you actually draw the map to bitmap or about the game.

Btw. in my implementation, I used a byte to denote borders of a hexel (which is what I called a single hexagon map cell) where each of the lowest 6 bits represented an edge. But a sort of rubber-band implementation (convex hull or similar) on the centers might be more applicable in your case.