Create account / Log in

Oblique Hex-grid Numbering uploaded

Discussion area for the development team.

Moderators: Tim M, uckelman

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » December 20th, 2010, 12:05 pm

1)in progress.

2) no need to insist - I was merely stating a preference rather than a refusal to cooperate. I may continue to use the convention for work in progress, while I refine naming choices, but will comply with team standards for all ready-for-prime-time code.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: [messages] [Developers] Re: Oblique Hex-grid Numbering u

Postby uckelman » December 20th, 2010, 12:09 pm

Thus spake pgeerkens:
> 1)in progress.
>
> 2) no need to insist - I was merely stating a preference rather than a
> refusal to cooperate. I may continue to use the convention for work in
> progress, while I refine naming choices, but will comply with team
> standards for all ready-for-prime-time code.
>

Great. Much appreciated.

I'm a bit concerned by how monolithic the classes you're writing are---
that's going to make it very hard to write unit tests.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8138
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » December 20th, 2010, 2:20 pm

The big, clunky and monolithic is more a function of where I started from, than on where I will end up. As I am in new territory here on a few counts, I am progressing slowly and carefully to avoif losing my way.

Any and all comments, particularly on the philosophy of using inclosed and sub-classes is appreciated.

Another interim check-in coming shortly.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: [messages] [Developers] Re: Oblique Hex-grid Numbering u

Postby uckelman » December 20th, 2010, 2:49 pm

Thus spake pgeerkens:
> The big, clunky and monolithic is more a function of where I started
> from, than on where I will end up. As I am in new territory here on a
> few counts, I am progressing slowly and carefully to avoif losing my
> way.
>
> Any and all comments, particularly on the philosophy of using inclosed
> and sub-classes is appreciated.

I'm a bit time-constrained at the moment, which is unfortunate, because
I'd like to be more involved in the design process than I'm able to be.

There are three important things which I see here:

1. Inversion of control will help with writing smaller classes, and make
what you write more testable.

2. Unit tests. I'll try to show you an example of what I'm looking for
here soon.

3. I've referred many times to things which this code will need to
accomodate or interact with, but haven't shown you what those things
look like. In particular, the whole properties system is slated to
change in 3.3, for which some of the utility code is written but I
haven't had time to document it yet, and at the same time the model-
view separation project will take all of the GUI code out of these
classes and put it behind some view interfaces in its own hiearchy.
This is frustrating for me, because it means that I can't provide
more precise guidance without stopping the tiling work for 3.2, but
I also don't want to cause you to waste your time writing a lot of
code which will need to be changed not far down the line; I'm finding
it hard to strike a balance between the two.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8138
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » December 20th, 2010, 3:55 pm

1) I will google search "inversion of control" to be sure that I understand what you mean. First impression is use of callback functions, but I will verify.

2) No rush. I have some background here, and have some thoughts myself once I get my classes down a bit in size.

3) My take for the moment is to break classs down in to a pair: an abstract super-class with the GUI and properties handling, extended by a concrete class with the real guts. This is most likely not your ultimate mechanism, but it will separate functionality and make the port easier.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: [messages] [Developers] Re: Oblique Hex-grid Numbering u

Postby uckelman » December 20th, 2010, 4:47 pm

Thus spake pgeerkens:
> 1) I will google search "inversion of control" to be sure that I
> understand what you mean. First impression is use of callback functions,
> but I will verify.

No, that's not quite what I mean.

Basically you have these small classes which conform to interfaces, and you
pass instances of them in to the larger classes at construction time. This
kind of design lets you build things in layers. You can verify that the
classes in the innermost layer work independently of anything else, and then
test subsequent layers using stubs and mocks.

An example of this is the code in VASSAL.tools.signals on my
uckleman-working branch, both under src and test.

> 2) No rush. I have some background here, and have some thoughts myself
> once I get my classes down a bit in size.

Once you've defined an API, writing tests before you write the application
code can be quite helpful.

> 3) My take for the moment is to break classs down in to a pair: an
> abstract super-class with the GUI and properties handling, extended by a
> concrete class with the real guts. This is most likely not your ultimate
> mechanism, but it will separate functionality and make the port easier.
>

Ok. I can guarantee you that the GUI code and properties handling will
ultimately not reside in the same class, as that's the goal of the
model-view project, but what you're doing shouldn't make it any harder to
pull apart later.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8138
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » December 21st, 2010, 8:32 pm

Not done yet, but looking much cleaner. Still thinking about how to best apply IoC.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » December 24th, 2010, 1:05 am

First try at using IoC seems to work reasonalby, and decouples code nicely IMHO. Any comments or naming suggestions you might have are welcome. I broke the calculation of MaxOblique et al somehow adding the PropertyCHangeListeners, so I am tracking that down now.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » December 28th, 2010, 6:15 pm

Joel,

This is ready for review. I would really appreciate your comments on the design as well as the implementation.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: Oblique Hex-grid Numbering uploaded

Postby Brent Easton » July 18th, 2011, 2:22 am

Hi Pieter,
Are you still working on HexGridNumberingX. I have checked out your latest code and have been trying to apply it to a map for a new module I am working on that has an Oblique grid combination I have not seen before. It's essentially a sideways hex grid with a regular grid numbering (offset hexes) that has been rotated 60 degrees anticlockwise.

I have managed to build a single-case version of HexGridNumbering for it, but I was interested to see if I could get HexGridNumberingX to do the job. I am having trouble getting the settings right for this map. Would you like to have a look? The map is available from

http://home.exetel.com.au/swampwallaby/ ... scen-2.jpg

I know the printed grid itself is twisted (painful!).

Thanks,
Brent.
User avatar
Brent Easton
 
Posts: 2757
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » July 18th, 2011, 7:57 pm

That's the wierdest numbering I can imagine. Let me see what I can do.

Pieter
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » July 18th, 2011, 8:50 pm

I have figured out why the grid looks so weird, and what I need to do to implement it. Now I just have to figure out why Eclipse cannot oopen my Java VM.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » July 25th, 2011, 5:27 am

Hi Brent,

Whatever Eclipse's problem was, upgrading to the latest release solved it.

This numbering scheme has the two co-ordinat axes at 30 degrees, which previous UI's had not considered. I believe the best solution is to define a UI class which allow direct input of the affine-transformation, thus allowing any numbering scheme to be handled (in extremis). I have this in progress now.

Pieter
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: Oblique Hex-grid Numbering uploaded

Postby pgeerkens » August 2nd, 2011, 8:05 pm

I have added a new class HexGridNumberingIrregular which takes as parameters direct input of the m00, m01, m10, m11 indices of the AffineTransform from grid-canonical hex indices to world hex indices. (The m20 and m21 matrix indices are already visible as the starting horizontal and vertical indices.) To obtain the grid numbering printed on the map the required parameter settings are thus:
M00 = -1.0 m01 = 1.0
M10 = 0.5 m11 = 0.5
Starting horizontal = 72
Starting vertical = 145

Once I generalized the underlying algorithm, and then tidied up the code, this new class is almost identical to HexGridNumberingX - I will ponder on abstracting this commonality into a separate class, but in the meantime I have checked in the code.

Joel:

If you read this, I am still unsure how I go about merging this code into the trunk. Can you point me at some guidelines for this?

Thank you.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Re: [messages] [Developers] Re: Oblique Hex-grid Numbering u

Postby uckelman » August 2nd, 2011, 8:23 pm

Thus spake pgeerkens:
> I have added a new class HexGridNumberingIrregular which takes as
> parameters direct input of the m00, m01, m10, m11 indices of the
> AffineTransform from grid-canonical hex indices to world hex indices.
> (The m20 and m21 matrix indices are already visible as the starting
> horizontal and vertical indices.) To obtain the grid numbering printed
> on the map the required parameter settings are thus:
> M00 = -1.0 m01 = 1.0
> M10 = 0.5 m11 = 0.5
> Starting horizontal = 72
> Starting vertical = 145
>
> Once I generalized the underlying algorithm, and then tidied up the
> code, this new class is almost identical to HexGridNumberingX - I will
> ponder on abstracting this commonality into a separate class, but in the
> meantime I have checked in the code.
>
> Joel:
>
> If you read this, I am still unsure how I go about merging this code
> into the trunk. Can you point me at some guidelines for this?

I've been doing the merging to trunk myself, as a way of doing code
review. Can you give me a list of commits I need to merge?

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8138
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest

cron