Menu
▾
▴
rails-devel — List for discussion of Rails development
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-11-16 22:50:30
|
I've committed a couple UI updates: 1. Closing windows now correctly updates the checkbox menu items in the StatusWindow. 2. You can "preview" tile lays now at any point in the game, but the UpgradesPanel will only display the Done button during an Operating Round, to disallow tile placement at any other time. I'd like to add checking whether the currently operating company has yet laid a tile to this, but that infrastructure doesn't appear to have been built yet. This looks like it's starting to interfere with the current ORWindow. Erik - Do you already have an idea on how you'd like to approach this? ---Brett. |
|
From: Brett L. <wak...@ea...> - 2005-11-15 09:10:37
|
For the most part, I agree.
---Brett.
-----Original Message-----
From: "John A. Tamplin" <ja...@ja...>
Sent: Nov 14, 2005 8:25 AM
To: rai...@li...
Subject: RE: [Rails-devel] Tile laying.
On Mon, 14 Nov 2005, Brett Lentz wrote:
> Really, the ideal long-term solution is that, depending on scale and
> user preference, the code makes the determination if rendering
> information on the tile itself is easily readable, or if moving the
> information to the tooltip is a better choice.
Having done extensive work with tile layout for print-ready output, I can
say that you will never get automated layout working for all the tiles.
The approach I have taken is to have the database contain all the layout
information (position and orientation) for the objects, and have them
defaulted if they are null based on automated layout algorithms. That
works for the simple tiles (60-70%), but crowded or unusual tiles will
have to be manually laid out to get a good result.
Regarding tooltips, I think any essential information about the tile needs
to be readily visible. Perhaps the actual amount can be moved, but the
notation saying there is a build cost needs to be accessible without
moving the mouse over it.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Erik V. <eri...@hc...> - 2005-11-14 22:53:11
|
Committed some minor improvements, one of which is that, if a new-laid tile can be rotated, the tooltip changes into "Click to rotate". Erik. |
|
From: John A. T. <ja...@ja...> - 2005-11-14 16:25:21
|
On Mon, 14 Nov 2005, Brett Lentz wrote:
> Really, the ideal long-term solution is that, depending on scale and
> user preference, the code makes the determination if rendering
> information on the tile itself is easily readable, or if moving the
> information to the tooltip is a better choice.
Having done extensive work with tile layout for print-ready output, I can
say that you will never get automated layout working for all the tiles.
The approach I have taken is to have the database contain all the layout
information (position and orientation) for the objects, and have them
defaulted if they are null based on automated layout algorithms. That
works for the simple tiles (60-70%), but crowded or unusual tiles will
have to be manually laid out to get a good result.
Regarding tooltips, I think any essential information about the tile needs
to be readily visible. Perhaps the actual amount can be moved, but the
notation saying there is a build cost needs to be accessible without
moving the mouse over it.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Brett L. <wak...@ea...> - 2005-11-14 16:01:44
|
>> Problem is, that such symbols, if drawn on a fixed position in the tile, >> may overlap preprinted track or cities, but I guess we could live with that. >The tile definition has to include where to draw such annotations. Really, the ideal long-term solution is that, depending on scale and user preference, the code makes the determination if rendering information on the tile itself is easily readable, or if moving the information to the tooltip is a better choice. We should at least allow the option for the information to be displayed both ways. ---Brett. |
|
From: John A. T. <ja...@ja...> - 2005-11-14 03:44:12
|
On Sun, 13 Nov 2005, Erik Vos wrote:
> My real preference would be to leave this until someone
> manages to create a full map, which can act as a background
> (on top of which we would NOT draw the preprinted tiles).
>
> But I realise that that may be ahead of us for a long time.
>
> Marco's Tile Designer does not yet allow for creating tiles
> with such special symbols (and we don't have the source code).
> So your second option is the only one we can realise on short term.
My tile rendering code supports arbitrary annotations, although currently
defined only using PS code so would need some work to draw on the screen.
> Problem is, that such symbols, if drawn on a fixed position in the tile,
> may overlap preprinted track or cities, but I guess we could live with that.
The tile definition has to include where to draw such annotations.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Brett L. <wak...@ea...> - 2005-11-14 02:15:44
|
I've also added Company starting locations to the map, and Company destinations to the tooltips. Upgrade costs are only displayed until the first upgrade is played. Company starting locations are only displayed until the company has started and floated. I haven't yet added any of this to the game engine yet, just the map UI. ---Brett. -----Original Message----- From: Brett Lentz <wak...@ea...> Sent: Nov 13, 2005 7:45 PM To: rai...@li... Subject: RE: [Rails-devel] Tile laying. > Problem is, that such symbols, if drawn on a fixed position in the tile, > may overlap preprinted track or cities, but I guess we could live with that. I agree. I want to do something that looks at least half-way decent. Though, that'll be kind of tough while we're still using .gif -based graphics. ;-) For now, I've added the tile costs as a string drawn on top of the tiles. I think that's probably sufficient for now, and we can worry about improving on that in the future. ---Brett |
|
From: Brett L. <wak...@ea...> - 2005-11-14 00:45:52
|
> Problem is, that such symbols, if drawn on a fixed position in the tile, > may overlap preprinted track or cities, but I guess we could live with that. I agree. I want to do something that looks at least half-way decent. Though, that'll be kind of tough while we're still using .gif -based graphics. ;-) For now, I've added the tile costs as a string drawn on top of the tiles. I think that's probably sufficient for now, and we can worry about improving on that in the future. ---Brett |
|
From: Erik V. <eri...@hc...> - 2005-11-13 21:45:42
|
> Great! > > One thing left to add to the map is mountains and river/water hexes. > > There are two approaches that I can see for this. > > 1. Creating custom hex tile graphics, allocating a bunch of > ID numbers (probably negative numbers so as to not overlap > the existing scheme), and updating the map XML. > 2. Dynamically draw them on top of the hexes using > Graphics/Graphics2D drawing. > > Is there any preference to which we should pursue? My real preference would be to leave this until someone manages to create a full map, which can act as a background (on top of which we would NOT draw the preprinted tiles). But I realise that that may be ahead of us for a long time. Marco's Tile Designer does not yet allow for creating tiles with such special symbols (and we don't have the source code). So your second option is the only one we can realise on short term. Problem is, that such symbols, if drawn on a fixed position in the tile, may overlap preprinted track or cities, but I guess we could live with that. Erik. |
|
From: Brett L. <wak...@ea...> - 2005-11-13 21:03:51
|
Great! One thing left to add to the map is mountains and river/water hexes. There are two approaches that I can see for this. 1. Creating custom hex tile graphics, allocating a bunch of ID numbers (probably negative numbers so as to not overlap the existing scheme), and updating the map XML. 2. Dynamically draw them on top of the hexes using Graphics/Graphics2D drawing. Is there any preference to which we should pursue? ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 13, 2005 3:10 PM To: rai...@li... Subject: RE: [Rails-devel] Tile laying. I've done some final cleanups in the hexmap code. The differences between GUINSHex and GUIEWHex had become so small that I have removed these classes and merged its remaining contents into GUIHex. I have also fixed the tooltip. That's it for today! Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Brett Lentz > Sent: 13 November 2005 19:39 > To: rai...@li... > Subject: Re: [Rails-devel] Tile laying. > > Excellent! > > I agree, it's VERY pretty. > > ---Brett. > > > > -----Original Message----- > From: Erik Vos <eri...@hc...> > Sent: Nov 13, 2005 5:35 AM > To: rai...@li... > Subject: [Rails-devel] Tile laying. > > I have changed tile rotation such that they now rotate > around the tile center, so that adjustments are no longer needed. > > Scaling is now also consistent. > It looks rather pretty now, if I may say so. > > I have also added Cancel and Done buttons to the upgrades panel. > I think tile laying is now ready to be integrated into > the Operating Round process, which I will take on next. > > 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-11-13 20:11:04
|
I've done some final cleanups in the hexmap code. The differences between GUINSHex and GUIEWHex had become so small that I have removed these classes and merged its remaining contents into GUIHex. I have also fixed the tooltip. That's it for today! Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Brett Lentz > Sent: 13 November 2005 19:39 > To: rai...@li... > Subject: Re: [Rails-devel] Tile laying. > > Excellent! > > I agree, it's VERY pretty. > > ---Brett. > > > > -----Original Message----- > From: Erik Vos <eri...@hc...> > Sent: Nov 13, 2005 5:35 AM > To: rai...@li... > Subject: [Rails-devel] Tile laying. > > I have changed tile rotation such that they now rotate > around the tile center, so that adjustments are no longer needed. > > Scaling is now also consistent. > It looks rather pretty now, if I may say so. > > I have also added Cancel and Done buttons to the upgrades panel. > I think tile laying is now ready to be integrated into > the Operating Round process, which I will take on next. > > 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-11-13 18:39:23
|
Excellent! I agree, it's VERY pretty. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 13, 2005 5:35 AM To: rai...@li... Subject: [Rails-devel] Tile laying. I have changed tile rotation such that they now rotate around the tile center, so that adjustments are no longer needed. Scaling is now also consistent. It looks rather pretty now, if I may say so. I have also added Cancel and Done buttons to the upgrades panel. I think tile laying is now ready to be integrated into the Operating Round process, which I will take on next. 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-11-13 13:35:20
|
I have changed tile rotation such that they now rotate around the tile center, so that adjustments are no longer needed. Scaling is now also consistent. It looks rather pretty now, if I may say so. I have also added Cancel and Done buttons to the upgrades panel. I think tile laying is now ready to be integrated into the Operating Round process, which I will take on next. Erik. |
|
From: Erik V. <eri...@hc...> - 2005-11-12 22:56:54
|
> >One major gripe I have is that so many mouse clicks are > ignored by the UI. > >Sometimes I have to click 4 or 5 times to get the desired effect. > >How is that with you, Brett? > > Yeah, I'm seeing the same behavior. > > I think it's a product of how we're handling rotation. The > first couple of clicks are either being handled by the > selection code, or hitting the first parts of the rotation > array, which rotate the hex to the same position it's currently in. It seems to me that those clicks are not even picked up. In the past week I have tried if removing the MouseMotionListener (which is known to be a slow-down) would have any effect, but not so (this interface is used for setting the tooltip). > I think that area needs a lot of clean-up as well. > > Right now, the values in the rotation arrays are fairly > specific coordinate values, and will break if we try to > rescale the map. You might have noticed that I have put all that in a new class GUITile. One reason for that is that it might be easier to fix such things. Perhaps I can do something about that pretty soon. Erik. |
|
From: Brett L. <wak...@ea...> - 2005-11-12 19:27:30
|
>One major gripe I have is that so many mouse clicks are ignored by the UI. >Sometimes I have to click 4 or 5 times to get the desired effect. >How is that with you, Brett? Yeah, I'm seeing the same behavior. I think it's a product of how we're handling rotation. The first couple of clicks are either being handled by the selection code, or hitting the first parts of the rotation array, which rotate the hex to the same position it's currently in. I think that area needs a lot of clean-up as well. Right now, the values in the rotation arrays are fairly specific coordinate values, and will break if we try to rescale the map. As soon as we have 1830 fully working, I'd like this to be one of the first things we fix. ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-11-12 16:20:44
|
> Looks good to me. OK, 1-4 now work. Only the "Done" button is still missing. Only upgradeable tiles can now be selected, only the "provisional" tiles can be rotated, and only valid orientations can be taken. The game phase vs. tile colour is currently ignored, but that can be added later fairly easily. > I think we're going to need some visual cue to tell the user > that once the provisional hex is placed, clicking on it some > more rotates it. A tooltip? BTW, tooltips seem to have ceased working, I will look into that later. One major gripe I have is that so many mouse clicks are ignored by the UI. Sometimes I have to click 4 or 5 times to get the desired effect. How is that with you, Brett? Erik. > ---Brett. > > -----Original Message----- > From: Erik Vos <eri...@hc...> > Sent: Nov 10, 2005 6:00 PM > To: rai...@li... > Subject: RE: [Rails-devel] UpgradesPanel updates > > > > > Yes, I can do that. But I think that should be done only after > > a final confirmation button is pressed. Until that happens, > > the user should IMO be able to correct moves, > > e.g. by selecting another field. > > I'm considering the following procedure: > > 1. By clicking an upgrade tile, that tile > will be *temporarily* assigned to the selected hex. > E.g. via a method of GUIHex like dropTile (int tileId). > > 2. Only such provisional tiles can be rotated. > > 3. If another upgrade tile is clicked, that tile replaces > the previous provisional tile (already in place). > > 4. If another hex is clicked, the previously selected hex > is reset (e.g. removeTile()) before the new hex gets selected. > > 5. When a "Done" button is clicked, the provisional tile > becomes permanent (e.g. fixTile()), and the model is updated. > > I think GUIHex must be reworked a bit to make this all possible. > > Not sure when I can spend significant time on these matters, > perhaps in the weekend. > > Erik. > |
|
From: Brett L. <wak...@ea...> - 2005-11-10 23:14:25
|
Looks good to me. I think we're going to need some visual cue to tell the user that once the provisional hex is placed, clicking on it some more rotates it. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 10, 2005 6:00 PM To: rai...@li... Subject: RE: [Rails-devel] UpgradesPanel updates > > Yes, I can do that. But I think that should be done only after > a final confirmation button is pressed. Until that happens, > the user should IMO be able to correct moves, > e.g. by selecting another field. I'm considering the following procedure: 1. By clicking an upgrade tile, that tile will be *temporarily* assigned to the selected hex. E.g. via a method of GUIHex like dropTile (int tileId). 2. Only such provisional tiles can be rotated. 3. If another upgrade tile is clicked, that tile replaces the previous provisional tile (already in place). 4. If another hex is clicked, the previously selected hex is reset (e.g. removeTile()) before the new hex gets selected. 5. When a "Done" button is clicked, the provisional tile becomes permanent (e.g. fixTile()), and the model is updated. I think GUIHex must be reworked a bit to make this all possible. Not sure when I can spend significant time on these matters, perhaps in the weekend. 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-11-10 23:00:16
|
> > Yes, I can do that. But I think that should be done only after > a final confirmation button is pressed. Until that happens, > the user should IMO be able to correct moves, > e.g. by selecting another field. I'm considering the following procedure: 1. By clicking an upgrade tile, that tile will be *temporarily* assigned to the selected hex. E.g. via a method of GUIHex like dropTile (int tileId). 2. Only such provisional tiles can be rotated. 3. If another upgrade tile is clicked, that tile replaces the previous provisional tile (already in place). 4. If another hex is clicked, the previously selected hex is reset (e.g. removeTile()) before the new hex gets selected. 5. When a "Done" button is clicked, the provisional tile becomes permanent (e.g. fixTile()), and the model is updated. I think GUIHex must be reworked a bit to make this all possible. Not sure when I can spend significant time on these matters, perhaps in the weekend. Erik. |
|
From: Erik V. <eri...@hc...> - 2005-11-10 21:51:26
|
> I've fixed the UpgradesPanel and now have it displaying the > hex tile images along with the upgrade numbers. > > I've also pushed forward and have taught UpgradesPanel how to > update the tileImage, which effectively allows playing an > inital round of tiles. Very good. > So, currently in CVS is the basic working UI for laying tiles. > > Now, we need to have the changes propagate back from the UI > into the Model and then recalculate the upgrades list and > repopulate the model properties. > > Erik - should I leave this part to you? Yes, I can do that. But I think that should be done only after a final confirmation button is pressed. Until that happens, the user should IMO be able to correct moves, e.g. by selecting another field. Another thing is to restrict rotations to valid ones (regardless routes for now, but taking into account impassable hex sides). I think I'll do that first. Erik. |
|
From: Brett L. <wak...@ea...> - 2005-11-10 21:34:38
|
Heh... see my latest e-mail. I've fixed that. ;-) ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 10, 2005 4:23 PM To: rai...@li... Subject: RE: [Rails-devel] Map Painting Bugs FIXED Great to see real tiles in the side panel, though somewhat distorted. I think a 30 deg rotation is missing. > Now I can move on to fixing the repaint bug in the > UpgradesPanel. I don't expect this one to take nearly as long. ;-) I had already done that with revalidate() but your update with invalidate() crossed mine. Both calls seem to have the same effect. Next thing is to decouple mouse events in both panels (clicking in UpgradesPanel now makes the tiles disappear). 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-11-10 21:33:58
|
I've fixed the UpgradesPanel and now have it displaying the hex tile images along with the upgrade numbers. I've also pushed forward and have taught UpgradesPanel how to update the tileImage, which effectively allows playing an inital round of tiles. So, currently in CVS is the basic working UI for laying tiles. Now, we need to have the changes propagate back from the UI into the Model and then recalculate the upgrades list and repopulate the model properties. Erik - should I leave this part to you? ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-11-10 21:23:21
|
Great to see real tiles in the side panel, though somewhat distorted. I think a 30 deg rotation is missing. > Now I can move on to fixing the repaint bug in the > UpgradesPanel. I don't expect this one to take nearly as long. ;-) I had already done that with revalidate() but your update with invalidate() crossed mine. Both calls seem to have the same effect. Next thing is to decouple mouse events in both panels (clicking in UpgradesPanel now makes the tiles disappear). Erik. |
|
From: Brett L. <wak...@ea...> - 2005-11-10 02:09:18
|
Oy. The relief! I found the malignant line in paintOverlay() that was causing the problem. I'm happy to have this bug squashed, and feel a bit ashamed that it was one line that has caused so many problems. I've also commented out drawing the underlying hex because it's completely obstructed by the tiles, so it seems pointless to waste time rendering it. However, for debugging future maps, I'll leave the comments in there. Perhaps it'll be useful if we ever provide an option in the GUI to enable/disable graphical tiles. Anyhow... Now I can move on to fixing the repaint bug in the UpgradesPanel. I don't expect this one to take nearly as long. ;-) ---Brett. |
|
From: Brett L. <wak...@ea...> - 2005-11-09 23:26:22
|
No worries... I'm working on fixing the painting issues for the tile overlays. Don't let that stop you from committing changes as well. I was actually looking at the sizing problem yesterday as well, and thinking that we needed to set the size based on number of hexes. I'm glad you've done that. :-) The only real change I've made so far is disabling overlay painting until I get the painting code to adjust for the changes to the clipping area that happens while scrolling. Also, I reworked the upgrades panel a bit. Now it repaints when you click the outer window frame rather than needing you to resize the window. I suspect there's some place we're not calling repaint() that we need to. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 9, 2005 5:26 PM To: rai...@li... Subject: [Rails-devel] Map size & position I have committed some minor changes that better size and position the map. The size is now dependent on the number of hexes, and the map is positioned closer to the left and upper edges. To achieve this, some setting have been moved from HexMap to its subclasses. I see that Brett is also working on the map, so I'll leave it now. Erik. |
|
From: Erik V. <eri...@hc...> - 2005-11-09 22:26:42
|
I have committed some minor changes that better size and position the map. The size is now dependent on the number of hexes, and the map is positioned closer to the left and upper edges. To achieve this, some setting have been moved from HexMap to its subclasses. I see that Brett is also working on the map, so I'll leave it now. Erik. |
99 messages has been excluded from this view by a project administrator.
