You can subscribe to this list here.
2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brett L. <wak...@ea...> - 2005-09-23 22:14:48
|
I got NS hexes working just a few hours ago. If you're having trouble merging changes, go ahead and send me the files and I can merge 'em by hand. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 23, 2005 5:52 PM To: rai...@li... Subject: RE: [Rails-devel] Map status > > 2. We need a few more hex images to represent these things: > > all water, coastline with some water, rivers. The 1870 map > > just doesn't look quite right otherwise. ;-) Glad you didn't notice that the even rows were shifted with respect to the odd rows! That was a bug in game.MapHex. 1870 is OK now. 1856 and 18AL I can do if the NS map hexes are done, which you apparently are working on. I was also trying to make the rotation values mathematically correct, but your updates crossed mine. If you declare public final double static DEG60 = Math.PI/3, (60 degrees = pi/3 radians) then the rotation is simply - for NS hexes: tileOrientation * DEG60 - for EW hexes: (0.5+tileOrientation) * DEG60 so you don't need an array anymore. Erik. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Brett L. <wak...@ea...> - 2005-09-23 22:12:20
|
>> Things that need fixing: >> >> 1. The rotation values are HIGHLY scale-dependant. There's >> still quite a bit of work left to do here. To help with this, I've brought over the Scale class from Colossus. It's now located at ui/Scale. So, as we find them, we should replace any static values with (some_multiplier * Scale.get()). >> 2. We need a few more hex images to represent these things: >> all water, coastline with some water, rivers. The 1870 map >> just doesn't look quite right otherwise. ;-) > We could create full water hexes to spice things up a bit. > But to create nice coastlines I think we should follow my earlier > suggestion to create a single image that represents the whole map > with all details, including the preprinted tiles. > We would still have the preprinted tiles as separate objects > (the current situation), but not display them on top of the map. > These objects would then only exist to define the possible upgrades. That might be viable for the long-term. For now, I think I'll cook up some tiles in the Gimp or TileDesigner. Do we have any preference on what they should be numbered? >> 3. Hex orientation needs to be added to all other game's map.xml > I'll do that first thing now. Great. I was about to, but I'll work on something else so I don't dupilicate the effort. :-) >> 1. Building lists of tiles: allYellow, allGreen, allBrown, >> validUpgradesFrom(tileNumber), validUpgradesTo(tileNumber) > Not sure if we need "all" arrays per colour. For building lists of remaining tiles it would be handy. I suppose this will sort itself out as the UI evolves. >> 2. (re)Placing new tiles over existing map tiles. > I would like a menu of valid upgrade tiles becoming available > along one of the map borders when an upgradeable tile is clicked. > Clicking (or dragging) one of these tiles would move it to the > "active" hex. Clicking on that hex then then rotate the tile through > its valid orientations. > Also a "cancel" button is needed. Hmmm... I think you're on the right track. Default behavior for clicking a hex should be selecting/deselecting the hex, with appropriate highlighting. It looks like we agree there. However, I do like the way Simtex's 1830 handled laying track: clicking the hex rotates through all possible upgrades and all legal rotations of each tile upgrade. To do this requires monitoring the track on each hex and information about each neighboring hex. There's a lot of hex code left over from Colossus that deals with neighboring hexes, perhaps that's the place to start looking for ideas that would allow us to do this relatively easily. > 3. Anything related to track, such as checking track > placement validity. > 4. A tag or attribute to define impassable hexsides where upgradeable hexes > border each other (e.g. C11/D12 in 1830) should be added to Map.xml. > Perhaps a tag like > <Hex name="C11" ....> > <NoGo name="D12"/> > </Hex> The thing we need to be careful with here is that most hexes only have one or two sides that are impassable. Other hexes, like water, are completely impassable from all sides. I think we should see if we can leverage the code related to checking neighbor hexes that still exists from importing the Colossus hex code. It'll be much easier to do this if we can easily check the neighbors of each hex and examine the shared hexside for properties that mark it as impassable. I think that it'll be easier to write code to check hexside 3 of hex A1 with hexside 5 of hex C3 for impassable=true on either hexside. Does that make sense? ---Brett. |
From: Erik V. <eri...@hc...> - 2005-09-23 21:52:15
|
> > 2. We need a few more hex images to represent these things: > > all water, coastline with some water, rivers. The 1870 map > > just doesn't look quite right otherwise. ;-) Glad you didn't notice that the even rows were shifted with respect to the odd rows! That was a bug in game.MapHex. 1870 is OK now. 1856 and 18AL I can do if the NS map hexes are done, which you apparently are working on. I was also trying to make the rotation values mathematically correct, but your updates crossed mine. If you declare public final double static DEG60 = Math.PI/3, (60 degrees = pi/3 radians) then the rotation is simply - for NS hexes: tileOrientation * DEG60 - for EW hexes: (0.5+tileOrientation) * DEG60 so you don't need an array anymore. Erik. |
From: Erik V. <eri...@hc...> - 2005-09-23 21:19:21
|
> Ok... with the latest batch of commits... here's a rough > overview of the map's status: > > Things that work: > > 1. 1830 map lays out completely correctly. > 2. Clicking a hex rotates it... sorta. There's an array > count bug here so the first click doesn't hit the next array > value, but the beginning of the array. Nevertheless this is quite an achievement! > Things that need fixing: > > 1. The rotation values are HIGHLY scale-dependant. There's > still quite a bit of work left to do here. > 2. We need a few more hex images to represent these things: > all water, coastline with some water, rivers. The 1870 map > just doesn't look quite right otherwise. ;-) We could create full water hexes to spice things up a bit. But to create nice coastlines I think we should follow my earlier suggestion to create a single image that represents the whole map with all details, including the preprinted tiles. We would still have the preprinted tiles as separate objects (the current situation), but not display them on top of the map. These objects would then only exist to define the possible upgrades. > 3. Hex orientation needs to be added to all other game's map.xml I'll do that first thing now. > Things not yet implemented: > > 1. Building lists of tiles: allYellow, allGreen, allBrown, > validUpgradesFrom(tileNumber), validUpgradesTo(tileNumber) Not sure if we need "all" arrays per colour. The upgrade rules define what tiles are in play, regardless (but of course honouring) the tile colours, with the restriction that certain colours only become valid upgrades from certain phases (Phase is not implemented either). The upgrades are already defined, but not yet read. > 2. (re)Placing new tiles over existing map tiles. I would like a menu of valid upgrade tiles becoming available along one of the map borders when an upgradeable tile is clicked. Clicking (or dragging) one of these tiles would move it to the "active" hex. Clicking on that hex then then rotate the tile through its valid orientations. Also a "cancel" button is needed. > 3. Anything related to track, such as checking track > placement validity. 4. A tag or attribute to define impassable hexsides where upgradeable hexes border each other (e.g. C11/D12 in 1830) should be added to Map.xml. Perhaps a tag like <Hex name="C11" ....> <NoGo name="D12"/> </Hex> Erik. |
From: Brett L. <wak...@ea...> - 2005-09-22 23:43:32
|
Ok... with the latest batch of commits... here's a rough overview of the map's status: Things that work: 1. 1830 map lays out completely correctly. 2. Clicking a hex rotates it... sorta. There's an array count bug here so the first click doesn't hit the next array value, but the beginning of the array. Things that need fixing: 1. The rotation values are HIGHLY scale-dependant. There's still quite a bit of work left to do here. 2. We need a few more hex images to represent these things: all water, coastline with some water, rivers. The 1870 map just doesn't look quite right otherwise. ;-) 3. Hex orientation needs to be added to all other game's map.xml Things not yet implemented: 1. Building lists of tiles: allYellow, allGreen, allBrown, validUpgradesFrom(tileNumber), validUpgradesTo(tileNumber) 2. (re)Placing new tiles over existing map tiles. 3. Anything related to track, such as checking track placement validity. Just a reminder for those that lurk on the list here: New contributions are always welcome. There's plenty of work left to do. Check out the code from cvs, and e-mail me your changes (preferably as unified diffs). ---Brett. -----Original Message----- From: Brett Lentz <wak...@ea...> Sent: Sep 22, 2005 3:15 PM To: rai...@li... Subject: RE: [Rails-devel] Tiles are working... sorta. Sure, I'll massage it a bit and see if I can get it working better. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 22, 2005 3:02 PM To: rai...@li... Subject: RE: [Rails-devel] Tiles are working... sorta. I have added 3 lines to GUIEWHex to use the orientation codes that I have just added: x_adjust = x_adjust_arr[tileOrientation]; y_adjust = y_adjust_arr[tileOrientation]; rotation = rotation_arr[tileOrientation]; af.rotate(rotation); This does not do the job, but you can see in the map that something is happening. I've probably not done the right thing, or maybe the array values are not yet good. Can you sort it out from here? It's bed time for me... Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of Erik Vos > Sent: 22 September 2005 22:54 > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > I've done it a little bit different: a new method > setTileOrientation() in GUIHex. > > Please update as well because I fixed two minor compilation errors > on my side (the BICUBIC problem and a missing getContentPane(). in > MapWindow. > Guess it's my Java version.... > > Erik. > > > -----Original Message----- > > From: rai...@li... > > [mailto:rai...@li...] On Behalf > Of Erik Vos > > Sent: 22 September 2005 22:24 > > To: rai...@li... > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > One little problem: > > My version of java (1.4.2) does not have > > AffineTransformOp.TYPE_BICUBIC, > > I have replaced it for now by AffineTransformOp.TYPE_BILINEAR. > > > > Another problem is that the map does not repaint correctly > > when the window regains focus. > > > > How are we going to specify rotation? > > I suggest to add an extra int argument to the GUIEWHex constructor, > > which can range from 0-5 which indicates the number of 60 degrees > > clockwise turns to get at the actual orientation. > > > > I suppose af.rotate() does the turning? Why is it 0.5 now? > > Not clear to me how to tweak it to get our 60/120/180 deg rotations. > > > > I'm now going add the rotations to the 1830 hex map based > > on the current output. > > > > Erik. > > > > > -----Original Message----- > > > From: rai...@li... > > > [mailto:rai...@li...] On Behalf Of > > > Brett Lentz > > > Sent: 22 September 2005 00:24 > > > To: rai...@li... > > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > > Sounds fine by me. I hope seeing the fully drawn game maps > > > is at least a little inspiring. ;-) > > > > > > I've added an ImageLoader class so that we only load tile > > > images once rather than reread every file for every repaint. > > > Currently it's instantiated in HexMap, but I'm not > > > completely certain it will be able to stay there. It might > > > need to move to MapManager or some other place. > > > > > > I've added a BufferedImage and AffineTransform to GUIHex. > > > This is where we'll control the image's rotation and scaling. > > > > > > I've mentioned previously that I've added a Paint() method to > > > GUIEWHex that extends the Paint() method in GUIHex. This > > > will contain the hard-coded numbers for rotation and scaling. > > > > > > > > > > > > ---Brett. > > > > > > > > > > > > -----Original Message----- > > > From: Erik Vos <eri...@hc...> > > > Sent: Sep 21, 2005 3:08 PM > > > To: rai...@li... > > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > > > Things that aren't working yet: > > > > > > > > 1. We haven't defined the hex orientation in map.xml, so some > > > > of the map tiles aren't rotated properly. > > > > > > That I had planned to do when tiles would be displayable: > > > trying out the right rotation codes by trial and error (!). > > > So now is the time to start working on that. > > > > > > > 2. There's a few different things causing huge performance > > > > hits for drawing all tiles. > > > > > > > > 3. There's currently no interactivity with the map. > > > > > > > > Soon we'll need to build the logic for rotating through legal > > > > tiles. Is there already a method defined for obtaining arrays > > > > of tiles, such as an array of all yellow tile IDs? > > > > > > No, Tiles.xml is not read yet. But I think this file has > > the necessary > > > ingredients to create an internal representation of each tile's > > > nodes and tracks in terms of objects and relations between objects > > > (although I have some vague ideas on how it could be done). > > > > > > I'll look at what you have now tomorrow, maybe it inspires me to > > > something.... > > > > > > Erik. > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App > > > Server. Download > > > it for free - -and be entered to win a 42" plasma tv or > > your very own > > > Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App > > > Server. Download > > > it for free - -and be entered to win a 42" plasma tv or > > your very own > > > Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App > > Server. Download > > it for free - -and be entered to win a 42" plasma tv or > your very own > > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Brett L. <wak...@ea...> - 2005-09-22 22:15:47
|
Sure, I'll massage it a bit and see if I can get it working better. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 22, 2005 3:02 PM To: rai...@li... Subject: RE: [Rails-devel] Tiles are working... sorta. I have added 3 lines to GUIEWHex to use the orientation codes that I have just added: x_adjust = x_adjust_arr[tileOrientation]; y_adjust = y_adjust_arr[tileOrientation]; rotation = rotation_arr[tileOrientation]; af.rotate(rotation); This does not do the job, but you can see in the map that something is happening. I've probably not done the right thing, or maybe the array values are not yet good. Can you sort it out from here? It's bed time for me... Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of Erik Vos > Sent: 22 September 2005 22:54 > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > I've done it a little bit different: a new method > setTileOrientation() in GUIHex. > > Please update as well because I fixed two minor compilation errors > on my side (the BICUBIC problem and a missing getContentPane(). in > MapWindow. > Guess it's my Java version.... > > Erik. > > > -----Original Message----- > > From: rai...@li... > > [mailto:rai...@li...] On Behalf > Of Erik Vos > > Sent: 22 September 2005 22:24 > > To: rai...@li... > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > One little problem: > > My version of java (1.4.2) does not have > > AffineTransformOp.TYPE_BICUBIC, > > I have replaced it for now by AffineTransformOp.TYPE_BILINEAR. > > > > Another problem is that the map does not repaint correctly > > when the window regains focus. > > > > How are we going to specify rotation? > > I suggest to add an extra int argument to the GUIEWHex constructor, > > which can range from 0-5 which indicates the number of 60 degrees > > clockwise turns to get at the actual orientation. > > > > I suppose af.rotate() does the turning? Why is it 0.5 now? > > Not clear to me how to tweak it to get our 60/120/180 deg rotations. > > > > I'm now going add the rotations to the 1830 hex map based > > on the current output. > > > > Erik. > > > > > -----Original Message----- > > > From: rai...@li... > > > [mailto:rai...@li...] On Behalf Of > > > Brett Lentz > > > Sent: 22 September 2005 00:24 > > > To: rai...@li... > > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > > Sounds fine by me. I hope seeing the fully drawn game maps > > > is at least a little inspiring. ;-) > > > > > > I've added an ImageLoader class so that we only load tile > > > images once rather than reread every file for every repaint. > > > Currently it's instantiated in HexMap, but I'm not > > > completely certain it will be able to stay there. It might > > > need to move to MapManager or some other place. > > > > > > I've added a BufferedImage and AffineTransform to GUIHex. > > > This is where we'll control the image's rotation and scaling. > > > > > > I've mentioned previously that I've added a Paint() method to > > > GUIEWHex that extends the Paint() method in GUIHex. This > > > will contain the hard-coded numbers for rotation and scaling. > > > > > > > > > > > > ---Brett. > > > > > > > > > > > > -----Original Message----- > > > From: Erik Vos <eri...@hc...> > > > Sent: Sep 21, 2005 3:08 PM > > > To: rai...@li... > > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > > > Things that aren't working yet: > > > > > > > > 1. We haven't defined the hex orientation in map.xml, so some > > > > of the map tiles aren't rotated properly. > > > > > > That I had planned to do when tiles would be displayable: > > > trying out the right rotation codes by trial and error (!). > > > So now is the time to start working on that. > > > > > > > 2. There's a few different things causing huge performance > > > > hits for drawing all tiles. > > > > > > > > 3. There's currently no interactivity with the map. > > > > > > > > Soon we'll need to build the logic for rotating through legal > > > > tiles. Is there already a method defined for obtaining arrays > > > > of tiles, such as an array of all yellow tile IDs? > > > > > > No, Tiles.xml is not read yet. But I think this file has > > the necessary > > > ingredients to create an internal representation of each tile's > > > nodes and tracks in terms of objects and relations between objects > > > (although I have some vague ideas on how it could be done). > > > > > > I'll look at what you have now tomorrow, maybe it inspires me to > > > something.... > > > > > > Erik. > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App > > > Server. Download > > > it for free - -and be entered to win a 42" plasma tv or > > your very own > > > Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App > > > Server. Download > > > it for free - -and be entered to win a 42" plasma tv or > > your very own > > > Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App > > Server. Download > > it for free - -and be entered to win a 42" plasma tv or > your very own > > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@hc...> - 2005-09-22 22:02:46
|
I have added 3 lines to GUIEWHex to use the orientation codes that I have just added: x_adjust = x_adjust_arr[tileOrientation]; y_adjust = y_adjust_arr[tileOrientation]; rotation = rotation_arr[tileOrientation]; af.rotate(rotation); This does not do the job, but you can see in the map that something is happening. I've probably not done the right thing, or maybe the array values are not yet good. Can you sort it out from here? It's bed time for me... Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of Erik Vos > Sent: 22 September 2005 22:54 > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > I've done it a little bit different: a new method > setTileOrientation() in GUIHex. > > Please update as well because I fixed two minor compilation errors > on my side (the BICUBIC problem and a missing getContentPane(). in > MapWindow. > Guess it's my Java version.... > > Erik. > > > -----Original Message----- > > From: rai...@li... > > [mailto:rai...@li...] On Behalf > Of Erik Vos > > Sent: 22 September 2005 22:24 > > To: rai...@li... > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > One little problem: > > My version of java (1.4.2) does not have > > AffineTransformOp.TYPE_BICUBIC, > > I have replaced it for now by AffineTransformOp.TYPE_BILINEAR. > > > > Another problem is that the map does not repaint correctly > > when the window regains focus. > > > > How are we going to specify rotation? > > I suggest to add an extra int argument to the GUIEWHex constructor, > > which can range from 0-5 which indicates the number of 60 degrees > > clockwise turns to get at the actual orientation. > > > > I suppose af.rotate() does the turning? Why is it 0.5 now? > > Not clear to me how to tweak it to get our 60/120/180 deg rotations. > > > > I'm now going add the rotations to the 1830 hex map based > > on the current output. > > > > Erik. > > > > > -----Original Message----- > > > From: rai...@li... > > > [mailto:rai...@li...] On Behalf Of > > > Brett Lentz > > > Sent: 22 September 2005 00:24 > > > To: rai...@li... > > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > > Sounds fine by me. I hope seeing the fully drawn game maps > > > is at least a little inspiring. ;-) > > > > > > I've added an ImageLoader class so that we only load tile > > > images once rather than reread every file for every repaint. > > > Currently it's instantiated in HexMap, but I'm not > > > completely certain it will be able to stay there. It might > > > need to move to MapManager or some other place. > > > > > > I've added a BufferedImage and AffineTransform to GUIHex. > > > This is where we'll control the image's rotation and scaling. > > > > > > I've mentioned previously that I've added a Paint() method to > > > GUIEWHex that extends the Paint() method in GUIHex. This > > > will contain the hard-coded numbers for rotation and scaling. > > > > > > > > > > > > ---Brett. > > > > > > > > > > > > -----Original Message----- > > > From: Erik Vos <eri...@hc...> > > > Sent: Sep 21, 2005 3:08 PM > > > To: rai...@li... > > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > > > Things that aren't working yet: > > > > > > > > 1. We haven't defined the hex orientation in map.xml, so some > > > > of the map tiles aren't rotated properly. > > > > > > That I had planned to do when tiles would be displayable: > > > trying out the right rotation codes by trial and error (!). > > > So now is the time to start working on that. > > > > > > > 2. There's a few different things causing huge performance > > > > hits for drawing all tiles. > > > > > > > > 3. There's currently no interactivity with the map. > > > > > > > > Soon we'll need to build the logic for rotating through legal > > > > tiles. Is there already a method defined for obtaining arrays > > > > of tiles, such as an array of all yellow tile IDs? > > > > > > No, Tiles.xml is not read yet. But I think this file has > > the necessary > > > ingredients to create an internal representation of each tile's > > > nodes and tracks in terms of objects and relations between objects > > > (although I have some vague ideas on how it could be done). > > > > > > I'll look at what you have now tomorrow, maybe it inspires me to > > > something.... > > > > > > Erik. > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App > > > Server. Download > > > it for free - -and be entered to win a 42" plasma tv or > > your very own > > > Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App > > > Server. Download > > > it for free - -and be entered to win a 42" plasma tv or > > your very own > > > Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App > > Server. Download > > it for free - -and be entered to win a 42" plasma tv or > your very own > > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Erik V. <eri...@hc...> - 2005-09-22 21:53:45
|
I've done it a little bit different: a new method setTileOrientation() in GUIHex. Please update as well because I fixed two minor compilation errors on my side (the BICUBIC problem and a missing getContentPane(). in MapWindow. Guess it's my Java version.... Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of Erik Vos > Sent: 22 September 2005 22:24 > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > One little problem: > My version of java (1.4.2) does not have > AffineTransformOp.TYPE_BICUBIC, > I have replaced it for now by AffineTransformOp.TYPE_BILINEAR. > > Another problem is that the map does not repaint correctly > when the window regains focus. > > How are we going to specify rotation? > I suggest to add an extra int argument to the GUIEWHex constructor, > which can range from 0-5 which indicates the number of 60 degrees > clockwise turns to get at the actual orientation. > > I suppose af.rotate() does the turning? Why is it 0.5 now? > Not clear to me how to tweak it to get our 60/120/180 deg rotations. > > I'm now going add the rotations to the 1830 hex map based > on the current output. > > Erik. > > > -----Original Message----- > > From: rai...@li... > > [mailto:rai...@li...] On Behalf Of > > Brett Lentz > > Sent: 22 September 2005 00:24 > > To: rai...@li... > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > Sounds fine by me. I hope seeing the fully drawn game maps > > is at least a little inspiring. ;-) > > > > I've added an ImageLoader class so that we only load tile > > images once rather than reread every file for every repaint. > > Currently it's instantiated in HexMap, but I'm not > > completely certain it will be able to stay there. It might > > need to move to MapManager or some other place. > > > > I've added a BufferedImage and AffineTransform to GUIHex. > > This is where we'll control the image's rotation and scaling. > > > > I've mentioned previously that I've added a Paint() method to > > GUIEWHex that extends the Paint() method in GUIHex. This > > will contain the hard-coded numbers for rotation and scaling. > > > > > > > > ---Brett. > > > > > > > > -----Original Message----- > > From: Erik Vos <eri...@hc...> > > Sent: Sep 21, 2005 3:08 PM > > To: rai...@li... > > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > > > Things that aren't working yet: > > > > > > 1. We haven't defined the hex orientation in map.xml, so some > > > of the map tiles aren't rotated properly. > > > > That I had planned to do when tiles would be displayable: > > trying out the right rotation codes by trial and error (!). > > So now is the time to start working on that. > > > > > 2. There's a few different things causing huge performance > > > hits for drawing all tiles. > > > > > > 3. There's currently no interactivity with the map. > > > > > > Soon we'll need to build the logic for rotating through legal > > > tiles. Is there already a method defined for obtaining arrays > > > of tiles, such as an array of all yellow tile IDs? > > > > No, Tiles.xml is not read yet. But I think this file has > the necessary > > ingredients to create an internal representation of each tile's > > nodes and tracks in terms of objects and relations between objects > > (although I have some vague ideas on how it could be done). > > > > I'll look at what you have now tomorrow, maybe it inspires me to > > something.... > > > > Erik. > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App > > Server. Download > > it for free - -and be entered to win a 42" plasma tv or > your very own > > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App > > Server. Download > > it for free - -and be entered to win a 42" plasma tv or > your very own > > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Brett L. <wak...@ea...> - 2005-09-22 21:48:04
|
Before you get started, do one more checkout from CVS. I've just committed some extra code that does *very* rudimentary rotations based on values I observed. I'm working out the math to improve the calculations, but this works for now. I've moved around which class is implementing MouseListener a bit. This has cleared up a lot of confusion (for me). And now, clicking a hex will rotate it. There's a ton of bugs with the rotation still, but the basic mechanism works. I've been squashing repaint bugs as I find them. Some of them won't go away until we have tile rotation locked down a bit better. You're correct that af.rotate does the rotation, but you'll want to investigate the AffineTransform class documentation to see exactly how it's being rotated. The reason being, we're actually rotating a square image of a hexagon, which causes a little weirdness and is mathematically different than just rotating a hexagon. You'll see the reason af.rotate starts at 0.5 if you open any of the tile image files in any graphics program. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 22, 2005 2:23 PM To: rai...@li... Subject: RE: [Rails-devel] Tiles are working... sorta. One little problem: My version of java (1.4.2) does not have AffineTransformOp.TYPE_BICUBIC, I have replaced it for now by AffineTransformOp.TYPE_BILINEAR. Another problem is that the map does not repaint correctly when the window regains focus. How are we going to specify rotation? I suggest to add an extra int argument to the GUIEWHex constructor, which can range from 0-5 which indicates the number of 60 degrees clockwise turns to get at the actual orientation. I suppose af.rotate() does the turning? Why is it 0.5 now? Not clear to me how to tweak it to get our 60/120/180 deg rotations. I'm now going add the rotations to the 1830 hex map based on the current output. Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Brett Lentz > Sent: 22 September 2005 00:24 > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > Sounds fine by me. I hope seeing the fully drawn game maps > is at least a little inspiring. ;-) > > I've added an ImageLoader class so that we only load tile > images once rather than reread every file for every repaint. > Currently it's instantiated in HexMap, but I'm not > completely certain it will be able to stay there. It might > need to move to MapManager or some other place. > > I've added a BufferedImage and AffineTransform to GUIHex. > This is where we'll control the image's rotation and scaling. > > I've mentioned previously that I've added a Paint() method to > GUIEWHex that extends the Paint() method in GUIHex. This > will contain the hard-coded numbers for rotation and scaling. > > > > ---Brett. > > > > -----Original Message----- > From: Erik Vos <eri...@hc...> > Sent: Sep 21, 2005 3:08 PM > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > Things that aren't working yet: > > > > 1. We haven't defined the hex orientation in map.xml, so some > > of the map tiles aren't rotated properly. > > That I had planned to do when tiles would be displayable: > trying out the right rotation codes by trial and error (!). > So now is the time to start working on that. > > > 2. There's a few different things causing huge performance > > hits for drawing all tiles. > > > > 3. There's currently no interactivity with the map. > > > > Soon we'll need to build the logic for rotating through legal > > tiles. Is there already a method defined for obtaining arrays > > of tiles, such as an array of all yellow tile IDs? > > No, Tiles.xml is not read yet. But I think this file has the necessary > ingredients to create an internal representation of each tile's > nodes and tracks in terms of objects and relations between objects > (although I have some vague ideas on how it could be done). > > I'll look at what you have now tomorrow, maybe it inspires me to > something.... > > Erik. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@hc...> - 2005-09-22 21:24:21
|
One little problem: My version of java (1.4.2) does not have AffineTransformOp.TYPE_BICUBIC, I have replaced it for now by AffineTransformOp.TYPE_BILINEAR. Another problem is that the map does not repaint correctly when the window regains focus. How are we going to specify rotation? I suggest to add an extra int argument to the GUIEWHex constructor, which can range from 0-5 which indicates the number of 60 degrees clockwise turns to get at the actual orientation. I suppose af.rotate() does the turning? Why is it 0.5 now? Not clear to me how to tweak it to get our 60/120/180 deg rotations. I'm now going add the rotations to the 1830 hex map based on the current output. Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Brett Lentz > Sent: 22 September 2005 00:24 > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > Sounds fine by me. I hope seeing the fully drawn game maps > is at least a little inspiring. ;-) > > I've added an ImageLoader class so that we only load tile > images once rather than reread every file for every repaint. > Currently it's instantiated in HexMap, but I'm not > completely certain it will be able to stay there. It might > need to move to MapManager or some other place. > > I've added a BufferedImage and AffineTransform to GUIHex. > This is where we'll control the image's rotation and scaling. > > I've mentioned previously that I've added a Paint() method to > GUIEWHex that extends the Paint() method in GUIHex. This > will contain the hard-coded numbers for rotation and scaling. > > > > ---Brett. > > > > -----Original Message----- > From: Erik Vos <eri...@hc...> > Sent: Sep 21, 2005 3:08 PM > To: rai...@li... > Subject: RE: [Rails-devel] Tiles are working... sorta. > > > Things that aren't working yet: > > > > 1. We haven't defined the hex orientation in map.xml, so some > > of the map tiles aren't rotated properly. > > That I had planned to do when tiles would be displayable: > trying out the right rotation codes by trial and error (!). > So now is the time to start working on that. > > > 2. There's a few different things causing huge performance > > hits for drawing all tiles. > > > > 3. There's currently no interactivity with the map. > > > > Soon we'll need to build the logic for rotating through legal > > tiles. Is there already a method defined for obtaining arrays > > of tiles, such as an array of all yellow tile IDs? > > No, Tiles.xml is not read yet. But I think this file has the necessary > ingredients to create an internal representation of each tile's > nodes and tracks in terms of objects and relations between objects > (although I have some vague ideas on how it could be done). > > I'll look at what you have now tomorrow, maybe it inspires me to > something.... > > Erik. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App > Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Brett L. <wak...@ea...> - 2005-09-21 23:24:10
|
Sounds fine by me. I hope seeing the fully drawn game maps is at least a little inspiring. ;-) I've added an ImageLoader class so that we only load tile images once rather than reread every file for every repaint. Currently it's instantiated in HexMap, but I'm not completely certain it will be able to stay there. It might need to move to MapManager or some other place. I've added a BufferedImage and AffineTransform to GUIHex. This is where we'll control the image's rotation and scaling. I've mentioned previously that I've added a Paint() method to GUIEWHex that extends the Paint() method in GUIHex. This will contain the hard-coded numbers for rotation and scaling. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 21, 2005 3:08 PM To: rai...@li... Subject: RE: [Rails-devel] Tiles are working... sorta. > Things that aren't working yet: > > 1. We haven't defined the hex orientation in map.xml, so some > of the map tiles aren't rotated properly. That I had planned to do when tiles would be displayable: trying out the right rotation codes by trial and error (!). So now is the time to start working on that. > 2. There's a few different things causing huge performance > hits for drawing all tiles. > > 3. There's currently no interactivity with the map. > > Soon we'll need to build the logic for rotating through legal > tiles. Is there already a method defined for obtaining arrays > of tiles, such as an array of all yellow tile IDs? No, Tiles.xml is not read yet. But I think this file has the necessary ingredients to create an internal representation of each tile's nodes and tracks in terms of objects and relations between objects (although I have some vague ideas on how it could be done). I'll look at what you have now tomorrow, maybe it inspires me to something.... Erik. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@hc...> - 2005-09-21 22:08:34
|
> Things that aren't working yet: > > 1. We haven't defined the hex orientation in map.xml, so some > of the map tiles aren't rotated properly. That I had planned to do when tiles would be displayable: trying out the right rotation codes by trial and error (!). So now is the time to start working on that. > 2. There's a few different things causing huge performance > hits for drawing all tiles. > > 3. There's currently no interactivity with the map. > > Soon we'll need to build the logic for rotating through legal > tiles. Is there already a method defined for obtaining arrays > of tiles, such as an array of all yellow tile IDs? No, Tiles.xml is not read yet. But I think this file has the necessary ingredients to create an internal representation of each tile's nodes and tracks in terms of objects and relations between objects (although I have some vague ideas on how it could be done). I'll look at what you have now tomorrow, maybe it inspires me to something.... Erik. |
From: Brett L. <wak...@ea...> - 2005-09-21 21:51:31
|
I've committed a mostly working version of drawing the map tiles, including all of the GIF image files. Things that aren't working yet: 1. We haven't defined the hex orientation in map.xml, so some of the map tiles aren't rotated properly. 2. There's a few different things causing huge performance hits for drawing all tiles. 3. There's currently no interactivity with the map. Soon we'll need to build the logic for rotating through legal tiles. Is there already a method defined for obtaining arrays of tiles, such as an array of all yellow tile IDs? ---Brett. |
From: Brett L. <wak...@ea...> - 2005-09-21 19:19:08
|
> I would go for a naming convention so that no extra tag would be needed. I think I'll go with that for now and perhaps if there's a need/desire for added flexibility later, we can add it in. > Tileset.xml should of course get extra attributes to indicate the > orientation of the preprinted tiles. > We need to agree which direction the standard orientation (0) is. That won't be necessary. I've been playing around with AffineTransform a bit, and it'll definitely handle all of our rotation needs. The only down side is that we'll really want to work on getting either SVG or PostScript image support working because rasterized image formats (GIF/PNG/JPEG) really don't allow the same image quality that vector images do. ---Brett. |
From: Erik V. <eri...@hc...> - 2005-09-21 19:11:53
|
> Tileset.xml should of course get extra attributes to indicate the > orientation > of the preprinted tiles. read: one extra attribute, for instance orientation="4" |
From: Erik V. <eri...@hc...> - 2005-09-21 19:04:53
|
> OK... I've taken my own advice and committed a version of > GUIEWHex that comments out the Paint() method. OK > Which brings me to the question I was JUST about to bring up.... > > I'd like to add a tag to the XML files to designate what tile > image to load. However, I'm not sure which file to use: > tiles.xml or tileset.xml > > I'm thinking just a basic <image>filename.png</image> tag > ought to be sufficient. > > What do you think? I would go for a naming convention so that no extra tag would be needed. For instance: tile0057_0.png would be a normally oriented tile 57 picture (the last number indicates the orientation). The preprinted tiles have negative numbers (or zero) in Marco's dictionary, so that would become tile-0901_0.png (tile0000_0.png). Tileset.xml should of course get extra attributes to indicate the orientation of the preprinted tiles. We need to agree which direction the standard orientation (0) is. For PBEM the standard seems to be the one with the preprinted tile number south. Perhaps it is easiest to follow Marco's tile directory again: the standard orientation would then get number 0. We have a maximum of 12 orientations, so the numbers could run 0-11 (or a-k, or whatever). We would not always need 12 orientations: 0057_6 would be identical to 0057_0 because of the symmetry. We could make it a rule that if an orientation >5 does not exist, we take the one 6 lower. Marco's tiles are NS-oriented, so NS-tiles get the even numbers. The EW-tiles would then have odd orientation numbers. Just my thoughts.... Erik. |
From: Brett L. <wak...@ea...> - 2005-09-20 23:06:14
|
OK... I've taken my own advice and committed a version of GUIEWHex that comments out the Paint() method. Which brings me to the question I was JUST about to bring up.... I'd like to add a tag to the XML files to designate what tile image to load. However, I'm not sure which file to use: tiles.xml or tileset.xml I'm thinking just a basic <image>filename.png</image> tag ought to be sufficient. What do you think? ---Brett. -----Original Message----- From: Brett Lentz <wak...@ea...> Sent: Sep 20, 2005 6:53 PM To: rai...@li... Subject: RE: [Rails-devel] Trains AH! Your updates are colliding with mine slightly. I'm working on getting tile images to display themselves. Get an updated copy of GUIEWHex and comment out the new Paint() method that i've put there. It's not quite "done" yet. I'll commit a less intrusive version here shortly. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 20, 2005 6:22 PM To: rai...@li... Subject: RE: [Rails-devel] Trains > > Sure we can, but I did not want to destroy your code before mine > > would prove to be better :-) > > That's the lovely thing about CVS. Once my code has been > committed as a specific file revision number, it's always > preserved. We can always checkout previous versions of > files even after you commit changes. > > So, please go ahead and just overwrite existing methods. > Yours clearly are working much better. After all, they're > correctly displaying the map layout. ;-) They did.... I fixed, committed and updated, and am now getting a compilation error in GUIEWHex.java: "The field AffineTransformOp.TYPE_BICUBIC is not visible" which prevents EW maps from being displayed. I suppose this is work in progress. Erik ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Brett L. <wak...@ea...> - 2005-09-20 22:53:36
|
AH! Your updates are colliding with mine slightly. I'm working on getting tile images to display themselves. Get an updated copy of GUIEWHex and comment out the new Paint() method that i've put there. It's not quite "done" yet. I'll commit a less intrusive version here shortly. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 20, 2005 6:22 PM To: rai...@li... Subject: RE: [Rails-devel] Trains > > Sure we can, but I did not want to destroy your code before mine > > would prove to be better :-) > > That's the lovely thing about CVS. Once my code has been > committed as a specific file revision number, it's always > preserved. We can always checkout previous versions of > files even after you commit changes. > > So, please go ahead and just overwrite existing methods. > Yours clearly are working much better. After all, they're > correctly displaying the map layout. ;-) They did.... I fixed, committed and updated, and am now getting a compilation error in GUIEWHex.java: "The field AffineTransformOp.TYPE_BICUBIC is not visible" which prevents EW maps from being displayed. I suppose this is work in progress. Erik ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@hc...> - 2005-09-20 22:23:06
|
> > Sure we can, but I did not want to destroy your code before mine > > would prove to be better :-) > > That's the lovely thing about CVS. Once my code has been > committed as a specific file revision number, it's always > preserved. We can always checkout previous versions of > files even after you commit changes. > > So, please go ahead and just overwrite existing methods. > Yours clearly are working much better. After all, they're > correctly displaying the map layout. ;-) They did.... I fixed, committed and updated, and am now getting a compilation error in GUIEWHex.java: "The field AffineTransformOp.TYPE_BICUBIC is not visible" which prevents EW maps from being displayed. I suppose this is work in progress. Erik |
From: Brett L. <wak...@ea...> - 2005-09-19 22:28:14
|
> Yes, but my question is if it would be beneficial to change that, > at least partially: to keep the StatusWindow up to date if > any action is performed in another window (StartRound, OR). > So far I have added quite a number of methods to GameStatus > to allow updates from other windows, and it's a bit of a mess now. > No real problem, but I was thinking if another way to update > GameStatus would be more elegant. I'm not really sure it's necessary at this point. Is there ever a point where the UI is out of sync with the model objects? I think this might be something that's good to revisit after our initial release. For now, if it's working sufficiently, there's no reason to reinvent the wheel. There's plenty of other tasks needing completion. :-) > Sure we can, but I did not want to destroy your code before mine > would prove to be better :-) That's the lovely thing about CVS. Once my code has been committed as a specific file revision number, it's always preserved. We can always checkout previous versions of files even after you commit changes. So, please go ahead and just overwrite existing methods. Yours clearly are working much better. After all, they're correctly displaying the map layout. ;-) ---Brett. |
From: Erik V. <eri...@hc...> - 2005-09-19 21:09:54
|
> We don't currently "tell" the UI about changes to companies. > > The Paint/Repaint methods are called to draw the UI whenever > the values in our Stock model change. The UI then calls the > appropriate get methods to obtain the current values of the model. Yes, but my question is if it would be beneficial to change that, at least partially: to keep the StatusWindow up to date if any action is performed in another window (StartRound, OR). So far I have added quite a number of methods to GameStatus to allow updates from other windows, and it's a bit of a mess now. No real problem, but I was thinking if another way to update GameStatus would be more elegant. > Also, I've noticed you've forked the API a bit for > implementing the map. Is there a reason we can't just > replace the old methods with the newer ones? Sure we can, but I did not want to destroy your code before mine would prove to be better :-) Erik. |
From: Brett L. <wak...@ea...> - 2005-09-19 16:37:21
|
We don't currently "tell" the UI about changes to companies. The Paint/Repaint methods are called to draw the UI whenever the values in our Stock model change. The UI then calls the appropriate get methods to obtain the current values of the model. Also, I've noticed you've forked the API a bit for implementing the map. Is there a reason we can't just replace the old methods with the newer ones? ---Brett -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 18, 2005 3:00 PM To: rai...@li... Subject: [Rails-devel] Trains I have added Trains. Most options related to buying trains have been implemented, except - buying "unlimited" trains, - cheap exchange for first Diesel, - train limits (will come when Phases are added), - dual trains, like 18VA 4/3G or 18Scan 4/3+3. I am thinking about ways to simplify keeping all data shown in the UI up to date. Sometimes "deep" changes occur (such as new trains becoming available), and now the UI must poll each time a train is bought if such a change has occurred. The same applies to share prices, cash amounts, and in fact all on-screen items. It could be easier to have the values "tell" the UI about any changes. Two ways to achieve that are 1. Create an Event each time a values changes, and let each and every UI field listen to changes of its underlying value. 2. An older and IMO simpler way is the Observer/Observable pattern. The main hurdle is that each such value must get the capability to register its own listener(s). I played a bit with Events and EventListeners but it looks rather heavy to me. The simplest solution might be to create Observable subclass types (ObservableInteger etc.) and embed values like cash amounts and share percentages in such types. The UI Field class should then implement Observer, and each Field instance should register as an Observer of its own Observable. Any thoughts about this idea? Erik. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@hc...> - 2005-09-18 22:00:44
|
I have added Trains. Most options related to buying trains have been implemented, except - buying "unlimited" trains, - cheap exchange for first Diesel, - train limits (will come when Phases are added), - dual trains, like 18VA 4/3G or 18Scan 4/3+3. I am thinking about ways to simplify keeping all data shown in the UI up to date. Sometimes "deep" changes occur (such as new trains becoming available), and now the UI must poll each time a train is bought if such a change has occurred. The same applies to share prices, cash amounts, and in fact all on-screen items. It could be easier to have the values "tell" the UI about any changes. Two ways to achieve that are 1. Create an Event each time a values changes, and let each and every UI field listen to changes of its underlying value. 2. An older and IMO simpler way is the Observer/Observable pattern. The main hurdle is that each such value must get the capability to register its own listener(s). I played a bit with Events and EventListeners but it looks rather heavy to me. The simplest solution might be to create Observable subclass types (ObservableInteger etc.) and embed values like cash amounts and share percentages in such types. The UI Field class should then implement Observer, and each Field instance should register as an Observer of its own Observable. Any thoughts about this idea? Erik. |
From: Erik V. <eri...@hc...> - 2005-09-07 22:00:28
|
> After beating on this for a while, and only receiving limited > help from Marco Rocci, I'm thinking that for the time being > we should use GIF or PNG tile graphics despite their obvious > limitations. Java already supports the formats, and as near > as I can tell AffineTransform should be able to handle > rotating the images as we need them. > > If we can't rotate them on the fly, the graphics are small, > and we only need 12 images to cover every rotation option for > each hex (and some tiles never appear in all possible > orientations). I don't really like the option of distributing > thousands of image sprites, but it's easy to do and solves > the problem for the short-term. > > What do you all think? Should we just punt on the SVG > support for now, or is someone close to getting it working? I'm not working on the graphics part, and anything that works is fine with me, at least on the short term. Erik. |
From: Brett L. <wak...@ea...> - 2005-09-06 23:15:37
|
After beating on this for a while, and only receiving limited help from Marco Rocci, I'm thinking that for the time being we should use GIF or PNG tile graphics despite their obvious limitations. Java already supports the formats, and as near as I can tell AffineTransform should be able to handle rotating the images as we need them. If we can't rotate them on the fly, the graphics are small, and we only need 12 images to cover every rotation option for each hex (and some tiles never appear in all possible orientations). I don't really like the option of distributing thousands of image sprites, but it's easy to do and solves the problem for the short-term. What do you all think? Should we just punt on the SVG support for now, or is someone close to getting it working? ---Brett. |