hex-line calculating routine?
Hi everyone,
I''m new at this stuff, and I''d like to code a hex engine - specifically to write a game based on the BattleTech universe. Now, what I need is a routine that tells me which hex fields are touched when I draw a line from the center of a hex to the center of another. Important is that the hexes are drawn with a horizontal line being the top line, and I must be telled by this routine, too, whether the line drawn touches two hexes at the same time at the same position, i.e. wanders directly over the side of a hex so that one cannot tell which of both has been touched.
there are a number of ways for you to get the effect that you desire. (its funny how this is an easy thing to do with a straight rule on a piece of hex paper, but with a computer, its very computation intensive)
here''s one possibility. it would not be suitable if your game is realtime, but it would be OK if you''re doing a turn-based thing.
you may want to look up some of the HRGN functions in MSDN, especially CreatePolygonRegion.
using that function, you can make a number of regions that comprise a single tile in the map.
now, when firing, you first determine the angle you are firing at, then you create a new polygon region, and to do so, you make the firing path slightly wider than a single line. (you can make the path 5 pixels or something, so that you''d have a polygon that you can make a region from)
now, you need a recursive function to calculate what areas are hit by the firing path.
the first part of the function checks to see if that hex has already been check. if it has, it exits the function
next, it marks the hex as checked
now, it determines if the firing area intersects with the region that makes up the tile, and marks it true or false
the way it checks to see if the firing region intersects with the tile is by using IntersectRegion
next, for each adjacent tile, it sends the data for that tile to the same function.
with a function like this,
(A) each tile is only checked once
(B) checks for tiles that do not have an intersection with the firing area are minimized
(C) the "hitting two tiles at once" problem is solved, because our firing area is wider than a single line.
(D) there isnt a whole lot of math involved
(E) it''s not the fastest
(F) about 3 times the number of tiles are checked than are actually hit
(G) its the first idea that came to me
tonight, i''m going to do a small demo of this method, to check its viability. (its the kind of thing that should be in my book, so i should probably include it if its a good algorithm)
here''s one possibility. it would not be suitable if your game is realtime, but it would be OK if you''re doing a turn-based thing.
you may want to look up some of the HRGN functions in MSDN, especially CreatePolygonRegion.
using that function, you can make a number of regions that comprise a single tile in the map.
now, when firing, you first determine the angle you are firing at, then you create a new polygon region, and to do so, you make the firing path slightly wider than a single line. (you can make the path 5 pixels or something, so that you''d have a polygon that you can make a region from)
now, you need a recursive function to calculate what areas are hit by the firing path.
the first part of the function checks to see if that hex has already been check. if it has, it exits the function
next, it marks the hex as checked
now, it determines if the firing area intersects with the region that makes up the tile, and marks it true or false
the way it checks to see if the firing region intersects with the tile is by using IntersectRegion
next, for each adjacent tile, it sends the data for that tile to the same function.
with a function like this,
(A) each tile is only checked once
(B) checks for tiles that do not have an intersection with the firing area are minimized
(C) the "hitting two tiles at once" problem is solved, because our firing area is wider than a single line.
(D) there isnt a whole lot of math involved
(E) it''s not the fastest
(F) about 3 times the number of tiles are checked than are actually hit
(G) its the first idea that came to me
tonight, i''m going to do a small demo of this method, to check its viability. (its the kind of thing that should be in my book, so i should probably include it if its a good algorithm)
Sorry that I didn''t reply for quite a long time, but univesity kept me from continuing my current project.
The code you sent me looks quite promising, TANSTAAFL, but it is not exactly what I had in mind because of what you see as an advantage of your code, the "two hexex hit at once" problem.
The prob is that I want to write an "as exactly as possible" adaption of the battleTech rules. And that requires the whenever the line of sight calculated for a shot passes to adjacent hexes exactly on the border, the defender (the target) can choose which of these hexes belongs to the los (with the effect that the terrain on that hex counts to the malus of the attacker''s hit probability). You see, I am going to make compromise to the BattleTech rules in any case as I will automize the process of the opponent choosing the hex as I will always count the hex with the higher shot probability modificator. I cannot simplfy this too much because the difference between open area or wood can make a player''s day...
The code you sent me looks quite promising, TANSTAAFL, but it is not exactly what I had in mind because of what you see as an advantage of your code, the "two hexex hit at once" problem.
The prob is that I want to write an "as exactly as possible" adaption of the battleTech rules. And that requires the whenever the line of sight calculated for a shot passes to adjacent hexes exactly on the border, the defender (the target) can choose which of these hexes belongs to the los (with the effect that the terrain on that hex counts to the malus of the attacker''s hit probability). You see, I am going to make compromise to the BattleTech rules in any case as I will automize the process of the opponent choosing the hex as I will always count the hex with the higher shot probability modificator. I cannot simplfy this too much because the difference between open area or wood can make a player''s day...
This problem got posted to his IsoHex book mailing list. I made a modification of his demo to handle the situations in a manner more true to the LOS rules. The algorithm is a extremely hacked version of Bresenham''s Line algorithm.
Follows is a link to the attachment on the mailing list.
http://pix.egroups.com/attach/506292/44/gs-50=62=506292/10-1-10-88/application=zip/HEXSIGHT.ZIP
Follows is a link to the attachment on the mailing list.
http://pix.egroups.com/attach/506292/44/gs-50=62=506292/10-1-10-88/application=zip/HEXSIGHT.ZIP
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement