rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get free tile lays

[Stefan F. <ste...@we...>]

On the specific issue:
I am responding as I am the one to blame for 1889:
Indeed the method getSpecialTileLays in OperatingRound is the critical one.

This was a caused by a recent change by Erik, as he cleaned up the Special 
Tile Lay code at several places in the codebase. As he was (most likely) not 
aware of the D property of being able to lay any tile, he assumed that a tile 
id would always be specified.

I would add a check to your fix to capture this case and otherwise keep with 
the old flow, unless Erik has a better idea/other opinion?

In general:
There are two things we could improve to avoid such issues:
A) Better documentation of the XML methods (for example which attributes are 
mandatory or optional and would an omission implies).

B) This problem would have been captured in principle by my automated testing 
of existing game files. However it seems (to me) that those tests got a little 
sidetracked, since the time I got sidetracked by real world issues ;-)
I will update the test settings and include more docs on them in the wiki (by 
collecting my information sent out to the mailing list).

Stefan


On Monday, June 06, 2011 10:28:29 am Bill Rosgen wrote:
> In a game I am playing, we encountered a bug in 1.4.2 that is not in 1.4.1.
>  Specifically, there is a company with the D private, which allows free
> tiles to be laid in the mountains (in rails XML, these tile lays are
> free="yes" and extra="no").  The attached .rails file exhibits the
> problem: Brad's TR does not get offered a free tile lay in F5.
> 
> Tracking the problem down lead to the method getSpecialTileLays in
> OperatingRound: when testing to see if special tile lays with extra="no"
> are possible, this method checks to see if the tile specified in the
> SpecialTileLay can be laid.  Unfortunately in the 1889 Private D is not
> restricted to a specific tile, so the action wasn't being added to the
> list.  The attached patch changes this to a different (and I think
> equivalent?) method of testing if normal tile lays are still available --
> I check that the map tileLaysPerColour is not empty (as is done by the
> method areTileLaysPossible when it tests if normal tile lays are
> available).
> 
> It is not clear to me that this is the best solution.  Other solutions
> might be:
> 
> 1) Add three SpecialTileLays to Private D in 1889, one for each available
> tile (7,8,9, in this case) 2) Change SpecialTileLay to keep a list of
> available tiles, with corresponding changes to OperatingRound and LayTile
> 3) If the tile in SpecialTileLay is null, treat this as no restriction:
> get the lists of all available tiles in the restricted hexes and check to
> see if any of them are valid, adding LayTile actions as appropriate.
> 
> Bill Rosgen

Re: [Rails-devel] Background Maps

[Adam B. <ab...@o2...>]

    So could you provide the SVG background? My post manager shows an attachment mark at your post but it does not provide the attachment...

    Adam Badura

From: John A. Tamplin 
Sent: Tuesday, June 07, 2011 8:46 PM
To: Development list for Rails: an 18xx game 
Subject: Re: [Rails-devel] Background Maps

On Tue, Jun 7, 2011 at 1:26 PM, Erik Vos <eri...@xs...> wrote:

  I didn't say that you created it...
  For sure, DTG will be mentioned in the credits.


I don't care -- however, it would probably be easier next time to ask me for it in SVG form rather than reverse-engineering it from PDFs :). 

-- 
John A. Tamplin



--------------------------------------------------------------------------------
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev 


--------------------------------------------------------------------------------
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background Maps

[John A. T. <ja...@ja...>]

On Tue, Jun 7, 2011 at 1:26 PM, Erik Vos <eri...@xs...> wrote:

> I didn't say that you created it...
> For sure, DTG will be mentioned in the credits.
>

I don't care -- however, it would probably be easier next time to ask me for
it in SVG form rather than reverse-engineering it from PDFs :).

-- 
John A. Tamplin

Re: [Rails-devel] Background Maps

[Erik V. <eri...@xs...>]

I didn't say that you created it...
For sure, DTG will be mentioned in the credits.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Bill Rosgen [mailto:ro...@gm...]
> Verzonden: dinsdag 7 juni 2011 18:32
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
> 
> 
> On 2011-06-08, at 0:04 , Erik Vos wrote:
> 
> > OK, I have committed the current code, which includes  an SVG background
> map for 18EU (contributed by Bill Rosgen, IIRC).
> 
> To be fair: it's not my map.  I simply cut out some pieces of the map
released
> by Deep Thought.
> 
> Bill
> 
> 
> 
>
----------------------------------------------------------------------------
--
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background Maps

[Bill R. <ro...@gm...>]

On 2011-06-08, at 0:04 , Erik Vos wrote:

> OK, I have committed the current code, which includes  an SVG background map for 18EU (contributed by Bill Rosgen, IIRC).

To be fair: it's not my map.  I simply cut out some pieces of the map released by Deep Thought.

Bill

Re: [Rails-devel] Background Maps

[Erik V. <eri...@xs...>]

OK, I have committed the current code, which includes  an SVG background map for 18EU (contributed by Bill Rosgen, IIRC).

To enable seeing the map, one entry needs be added to your custom my.properties file (I haven't tried to update the configuration menu yet):
- map.image.display=yes  (default no, in which case everything works as before).

I have included Bill Rosgen's patch to highlight selected hexes somewhat differently.  Currently, it only affects display when the map is used.  The original highlighting looks ugly in this case.

Please don't Zoom in serious play when the map image is used: it does not yet work as it should.
When I try, the tiles rescale correctly, and so does the map image, but the latter soon gets out of sync.

It's not clear to me how JSVGCanvas rescaling+resizing should be programmed the right way.
A scaling affine transform works fine, which is what I used initially.  But it not change the canvas size, so part of the map becomes invisible on zooming in.
Only setting the canvas bounds (setBounds()) initially does the whole job, and this is what I'm currently using.  But on repeated zooming actions, it seems to rescale the map image only every other time. 
Doing both (scale and setBounds) upscales the map twice.

It may be a matter of timing, and perhaps some listener should be invoked, but I cannot find any pointer on what exactly would be needed.

Erik.


> -----Oorspronkelijk bericht-----
> Van: Erik Vos [mailto:eri...@xs...]
> Verzonden: dinsdag 7 juni 2011 13:57
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: Re: [Rails-devel] Background Maps
> 
> I fully agree that this is the way to go for the future.
> In the meantime, I will commit my and some of Bill's work on the map image
> integration (imperfect as it currently is), trusting that you will ultimately also
> be able to integrate SVG map images into your work.
> 
> Erik
> 
> > -----Oorspronkelijk bericht-----
> > Van: Adam Badura [mailto:ab...@o2...]
> > Verzonden: dinsdag 7 juni 2011 7:38
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Background Maps
> >
> > OK. Great. Then I shell continue this work. Yet I cannot promise when
> > it will be done. But I will try to report on progress every now and then.
> >
> >     Adam Badura
> >
> > -----Oryginalna wiadomość-----
> > From: brett lentz
> > Sent: Tuesday, June 07, 2011 6:31 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Background Maps
> >
> > I think this is an excellent direction to continue working on.
> >
> > The patch looks like it consolidates a bunch of code into a couple of
> > classes, which looks good on first glance.
> >
> > I'd definitely like to see the finished patch once you're ready for it
> > to be merged into the codebase.
> >
> > ---Brett.
> >
> >
> >
> > On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> > > Sorry for the delay but I decided to adapt the patch to current code
> > > revision and have a look whether it does what I recall it did. Also
> > > I removed some additional works on symbols which I was doing along
> > > (this was the reason to start this work) but would be only distracting now.
> > >
> > > The code is mostly not documented as it is a working patch. Its not
> > > also "clean". But it does show that SVG Document isn't that hard.
> > > (To scroll or zoom use standard Batik components ways: Shift/Ctrl +
> > > moves with mouse buttons pressed.)
> > >
> > > So what do you think? Should I continue my work in this area?
> > >
> > > Adam Badura
> > >
> > > -----Oryginalna wiadomość----- From: Erik Vos
> > > Sent: Monday, June 06, 2011 2:43 PM
> > > To: 'Development list for Rails: an 18xx game'
> > > Subject: Re: [Rails-devel] Background Maps
> > >
> > > Adam,
> > >
> > > Congratulations with your second child!
> > >
> > > I'm certainly interested to have a look at your code, to check if I
> > > can merge it with my map display code.
> > >
> > > Some more comments below.
> > >
> > >> -----Oorspronkelijk bericht-----
> > >> Van: Adam Badura [mailto:ab...@o2...]
> > >>
> > >>    I was working on moving entire drawing to SVG (and this was one
> > >> of the reasons I tried to push Batik 1.7). But recently my second
> > >> child was born and there is some little chaos in my life with not
> > >> much time for such tasks.
> > >> I still have SVN Patch yet it is already conflicting at some places
> > >> with new code.
> > >>
> > >>    What I managed to get was to create an SVG document containing
> > >> map (all the tiles, either from map or track tiles). It looked
> > >> significantly better than our previous drawing mechanism. While it
> > >> was much less and much simpler code.
> > >> Also it scaled nicely.
> > >>
> > >>    What the code was missing was:
> > >> (1) drawing station tokens,
> > >> (2) drawing train paths,
> > >> (3) handling scaling and scrolling well,
> > >> (4) support tile selection.
> > >>
> > >>    First two would likely require some "hacking" as there is no
> > >> easy way currently to do it in SVG Document as there is not
> > >> "specification" of tracks and stations on an SVG tile. But previous
> > >> code did it somehow and I guess that solution could be used with
> > >> SVG Document as well until (if ever) SVG tiles will receive better
> > >> description. (That is a topic interesting on its
> > >> own...)
> > >
> > > The tracks and the token spot locations are also (somewhat
> > > cryptically) defined in Tiles.xml, and these definitions are
> > > currently used to draw the train paths and tokens.
> > > For the time being (or perhaps forever) that can be left as is,
> > > drawing these objects in the top layer of the JLayeredPane that I'm
> > > currently using.
> > > However, that would still require achieving correct alignment of the
> > > two layers after zooming.
> > >
> > >>    I tries to handle third  by using JSVGSrolledPane (or something
> > >> called
> > >> similarly) but didn't achieve much. Then I had to interrupt my
> > >> investigations.
> > >
> > > I have also been thinking about JSVGScrolledPane, but I think using
> > > that will only become possible once we manage to do all drawing via
> JSVG.
> > >
> > >>    Fourth should be easy as Batik provides some events to detect
> > >> this. I expect this could be even easier then current mouse handling.
> > >> Borders around selected or marked tiles could likely be achieved
> > >> easily with CSS in the SVG Document.
> > >
> > > Sounds good.
> > >
> > > Erik.
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > -------- Simplify data backup and recovery for your virtual
> > > environment with vRanger.
> > > Installation's a snap, and flexible recovery options mean your data
> > > is safe, secure and there when you need it. Discover what all the
> > > cheering's about.
> > > Get your free trial download today.
> > > http://p.sf.net/sfu/quest-dev2dev2
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > --------------------------------------------------------------------
> > > --
> > > -------- EditLive Enterprise is the world's most technically
> > > advanced content authoring tool. Experience the power of Track
> > > Changes, Inline Image Editing and ensure content is compliant with
> > > Accessibility Checking.
> > > http://p.sf.net/sfu/ephox-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > >
> >
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background Maps

[Adam B. <ab...@o2...>]

    OK. So once you add that background I will add it to my code to and 
share the results.
    Note thou that if the background will be a raster image then scaling 
will no longer look that well. On the other hand I expect backgrounds to be 
rather simple so maybe the will not suffer as much due to scaling.

    Adam Badura

-----Oryginalna wiadomość----- 
From: Erik Vos
Sent: Tuesday, June 07, 2011 1:56 PM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Background Maps

I fully agree that this is the way to go for the future.
In the meantime, I will commit my and some of Bill's work on the map image 
integration (imperfect as it currently is), trusting that you will 
ultimately also be able to integrate SVG map images into your work.

Erik

> -----Oorspronkelijk bericht-----
> Van: Adam Badura [mailto:ab...@o2...]
> Verzonden: dinsdag 7 juni 2011 7:38
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
>
> OK. Great. Then I shell continue this work. Yet I cannot promise when it 
> will
> be done. But I will try to report on progress every now and then.
>
>     Adam Badura
>
> -----Oryginalna wiadomość-----
> From: brett lentz
> Sent: Tuesday, June 07, 2011 6:31 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Background Maps
>
> I think this is an excellent direction to continue working on.
>
> The patch looks like it consolidates a bunch of code into a couple of 
> classes,
> which looks good on first glance.
>
> I'd definitely like to see the finished patch once you're ready for it to 
> be
> merged into the codebase.
>
> ---Brett.
>
>
>
> On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> > Sorry for the delay but I decided to adapt the patch to current code
> > revision and have a look whether it does what I recall it did. Also I
> > removed some additional works on symbols which I was doing along (this
> > was the reason to start this work) but would be only distracting now.
> >
> > The code is mostly not documented as it is a working patch. Its not
> > also "clean". But it does show that SVG Document isn't that hard. (To
> > scroll or zoom use standard Batik components ways: Shift/Ctrl + moves
> > with mouse buttons pressed.)
> >
> > So what do you think? Should I continue my work in this area?
> >
> > Adam Badura
> >
> > -----Oryginalna wiadomość----- From: Erik Vos
> > Sent: Monday, June 06, 2011 2:43 PM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Background Maps
> >
> > Adam,
> >
> > Congratulations with your second child!
> >
> > I'm certainly interested to have a look at your code, to check if I
> > can merge it with my map display code.
> >
> > Some more comments below.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Adam Badura [mailto:ab...@o2...]
> >>
> >>    I was working on moving entire drawing to SVG (and this was one of
> >> the reasons I tried to push Batik 1.7). But recently my second child
> >> was born and there is some little chaos in my life with not much time
> >> for such tasks.
> >> I still have SVN Patch yet it is already conflicting at some places
> >> with new code.
> >>
> >>    What I managed to get was to create an SVG document containing map
> >> (all the tiles, either from map or track tiles). It looked
> >> significantly better than our previous drawing mechanism. While it
> >> was much less and much simpler code.
> >> Also it scaled nicely.
> >>
> >>    What the code was missing was:
> >> (1) drawing station tokens,
> >> (2) drawing train paths,
> >> (3) handling scaling and scrolling well,
> >> (4) support tile selection.
> >>
> >>    First two would likely require some "hacking" as there is no easy
> >> way currently to do it in SVG Document as there is not
> >> "specification" of tracks and stations on an SVG tile. But previous
> >> code did it somehow and I guess that solution could be used with SVG
> >> Document as well until (if ever) SVG tiles will receive better
> >> description. (That is a topic interesting on its
> >> own...)
> >
> > The tracks and the token spot locations are also (somewhat
> > cryptically) defined in Tiles.xml, and these definitions are currently
> > used to draw the train paths and tokens.
> > For the time being (or perhaps forever) that can be left as is,
> > drawing these objects in the top layer of the JLayeredPane that I'm
> > currently using.
> > However, that would still require achieving correct alignment of the
> > two layers after zooming.
> >
> >>    I tries to handle third  by using JSVGSrolledPane (or something
> >> called
> >> similarly) but didn't achieve much. Then I had to interrupt my
> >> investigations.
> >
> > I have also been thinking about JSVGScrolledPane, but I think using
> > that will only become possible once we manage to do all drawing via 
> > JSVG.
> >
> >>    Fourth should be easy as Batik provides some events to detect
> >> this. I expect this could be even easier then current mouse handling.
> >> Borders around selected or marked tiles could likely be achieved
> >> easily with CSS in the SVG Document.
> >
> > Sounds good.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the
> > cheering's about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image 
> Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image 
> Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] Background Maps

[Erik V. <eri...@xs...>]

I fully agree that this is the way to go for the future.
In the meantime, I will commit my and some of Bill's work on the map image integration (imperfect as it currently is), trusting that you will ultimately also be able to integrate SVG map images into your work.

Erik

> -----Oorspronkelijk bericht-----
> Van: Adam Badura [mailto:ab...@o2...]
> Verzonden: dinsdag 7 juni 2011 7:38
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
> 
> OK. Great. Then I shell continue this work. Yet I cannot promise when it will
> be done. But I will try to report on progress every now and then.
> 
>     Adam Badura
> 
> -----Oryginalna wiadomość-----
> From: brett lentz
> Sent: Tuesday, June 07, 2011 6:31 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Background Maps
> 
> I think this is an excellent direction to continue working on.
> 
> The patch looks like it consolidates a bunch of code into a couple of classes,
> which looks good on first glance.
> 
> I'd definitely like to see the finished patch once you're ready for it to be
> merged into the codebase.
> 
> ---Brett.
> 
> 
> 
> On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> > Sorry for the delay but I decided to adapt the patch to current code
> > revision and have a look whether it does what I recall it did. Also I
> > removed some additional works on symbols which I was doing along (this
> > was the reason to start this work) but would be only distracting now.
> >
> > The code is mostly not documented as it is a working patch. Its not
> > also "clean". But it does show that SVG Document isn't that hard. (To
> > scroll or zoom use standard Batik components ways: Shift/Ctrl + moves
> > with mouse buttons pressed.)
> >
> > So what do you think? Should I continue my work in this area?
> >
> > Adam Badura
> >
> > -----Oryginalna wiadomość----- From: Erik Vos
> > Sent: Monday, June 06, 2011 2:43 PM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Background Maps
> >
> > Adam,
> >
> > Congratulations with your second child!
> >
> > I'm certainly interested to have a look at your code, to check if I
> > can merge it with my map display code.
> >
> > Some more comments below.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Adam Badura [mailto:ab...@o2...]
> >>
> >>    I was working on moving entire drawing to SVG (and this was one of
> >> the reasons I tried to push Batik 1.7). But recently my second child
> >> was born and there is some little chaos in my life with not much time
> >> for such tasks.
> >> I still have SVN Patch yet it is already conflicting at some places
> >> with new code.
> >>
> >>    What I managed to get was to create an SVG document containing map
> >> (all the tiles, either from map or track tiles). It looked
> >> significantly better than our previous drawing mechanism. While it
> >> was much less and much simpler code.
> >> Also it scaled nicely.
> >>
> >>    What the code was missing was:
> >> (1) drawing station tokens,
> >> (2) drawing train paths,
> >> (3) handling scaling and scrolling well,
> >> (4) support tile selection.
> >>
> >>    First two would likely require some "hacking" as there is no easy
> >> way currently to do it in SVG Document as there is not
> >> "specification" of tracks and stations on an SVG tile. But previous
> >> code did it somehow and I guess that solution could be used with SVG
> >> Document as well until (if ever) SVG tiles will receive better
> >> description. (That is a topic interesting on its
> >> own...)
> >
> > The tracks and the token spot locations are also (somewhat
> > cryptically) defined in Tiles.xml, and these definitions are currently
> > used to draw the train paths and tokens.
> > For the time being (or perhaps forever) that can be left as is,
> > drawing these objects in the top layer of the JLayeredPane that I'm
> > currently using.
> > However, that would still require achieving correct alignment of the
> > two layers after zooming.
> >
> >>    I tries to handle third  by using JSVGSrolledPane (or something
> >> called
> >> similarly) but didn't achieve much. Then I had to interrupt my
> >> investigations.
> >
> > I have also been thinking about JSVGScrolledPane, but I think using
> > that will only become possible once we manage to do all drawing via JSVG.
> >
> >>    Fourth should be easy as Batik provides some events to detect
> >> this. I expect this could be even easier then current mouse handling.
> >> Borders around selected or marked tiles could likely be achieved
> >> easily with CSS in the SVG Document.
> >
> > Sounds good.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the
> > cheering's about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background Maps

[Adam B. <ab...@o2...>]

OK. Great. Then I shell continue this work. Yet I cannot promise when it 
will be done. But I will try to report on progress every now and then.

    Adam Badura

-----Oryginalna wiadomość----- 
From: brett lentz
Sent: Tuesday, June 07, 2011 6:31 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Background Maps

I think this is an excellent direction to continue working on.

The patch looks like it consolidates a bunch of code into a couple of
classes, which looks good on first glance.

I'd definitely like to see the finished patch once you're ready for it
to be merged into the codebase.

---Brett.



On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> Sorry for the delay but I decided to adapt the patch to current code
> revision and have a look whether it does what I recall it did. Also I
> removed some additional works on symbols which I was doing along (this was
> the reason to start this work) but would be only distracting now.
>
> The code is mostly not documented as it is a working patch. Its not also
> "clean". But it does show that SVG Document isn't that hard. (To scroll or
> zoom use standard Batik components ways: Shift/Ctrl + moves with mouse
> buttons pressed.)
>
> So what do you think? Should I continue my work in this area?
>
> Adam Badura
>
> -----Oryginalna wiadomość----- From: Erik Vos
> Sent: Monday, June 06, 2011 2:43 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Background Maps
>
> Adam,
>
> Congratulations with your second child!
>
> I'm certainly interested to have a look at your code, to check if I can
> merge it with my map display code.
>
> Some more comments below.
>
>> -----Oorspronkelijk bericht-----
>> Van: Adam Badura [mailto:ab...@o2...]
>>
>>    I was working on moving entire drawing to SVG (and this was one of the
>> reasons I tried to push Batik 1.7). But recently my second child was born
>> and
>> there is some little chaos in my life with not much time for such tasks.
>> I still have SVN Patch yet it is already conflicting at some places with
>> new
>> code.
>>
>>    What I managed to get was to create an SVG document containing map 
>> (all
>> the tiles, either from map or track tiles). It looked significantly 
>> better
>> than our
>> previous drawing mechanism. While it was much less and much simpler code.
>> Also it scaled nicely.
>>
>>    What the code was missing was:
>> (1) drawing station tokens,
>> (2) drawing train paths,
>> (3) handling scaling and scrolling well,
>> (4) support tile selection.
>>
>>    First two would likely require some "hacking" as there is no easy way
>> currently to do it in SVG Document as there is not "specification" of
>> tracks
>> and stations on an SVG tile. But previous code did it somehow and I guess
>> that solution could be used with SVG Document as well until (if ever) SVG
>> tiles will receive better description. (That is a topic interesting on 
>> its
>> own...)
>
> The tracks and the token spot locations are also (somewhat cryptically)
> defined in Tiles.xml, and these definitions are currently used to draw the
> train paths and tokens.
> For the time being (or perhaps forever) that can be left as is, drawing
> these objects in the top layer of the JLayeredPane that I'm currently 
> using.
> However, that would still require achieving correct alignment of the two
> layers after zooming.
>
>>    I tries to handle third  by using JSVGSrolledPane (or something called
>> similarly) but didn't achieve much. Then I had to interrupt my
>> investigations.
>
> I have also been thinking about JSVGScrolledPane, but I think using that
> will only become possible once we manage to do all drawing via JSVG.
>
>>    Fourth should be easy as Batik provides some events to detect this. I
>> expect this could be even easier then current mouse handling. Borders
>> around selected or marked tiles could likely be achieved easily with CSS
>> in the
>> SVG Document.
>
> Sounds good.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with 
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is 
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] Background Maps

[brett l. <bre...@gm...>]

I think this is an excellent direction to continue working on.

The patch looks like it consolidates a bunch of code into a couple of
classes, which looks good on first glance.

I'd definitely like to see the finished patch once you're ready for it
to be merged into the codebase.

---Brett.



On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> Sorry for the delay but I decided to adapt the patch to current code
> revision and have a look whether it does what I recall it did. Also I
> removed some additional works on symbols which I was doing along (this was
> the reason to start this work) but would be only distracting now.
>
> The code is mostly not documented as it is a working patch. Its not also
> "clean". But it does show that SVG Document isn't that hard. (To scroll or
> zoom use standard Batik components ways: Shift/Ctrl + moves with mouse
> buttons pressed.)
>
> So what do you think? Should I continue my work in this area?
>
> Adam Badura
>
> -----Oryginalna wiadomość----- From: Erik Vos
> Sent: Monday, June 06, 2011 2:43 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Background Maps
>
> Adam,
>
> Congratulations with your second child!
>
> I'm certainly interested to have a look at your code, to check if I can
> merge it with my map display code.
>
> Some more comments below.
>
>> -----Oorspronkelijk bericht-----
>> Van: Adam Badura [mailto:ab...@o2...]
>>
>>    I was working on moving entire drawing to SVG (and this was one of the
>> reasons I tried to push Batik 1.7). But recently my second child was born
>> and
>> there is some little chaos in my life with not much time for such tasks.
>> I still have SVN Patch yet it is already conflicting at some places with
>> new
>> code.
>>
>>    What I managed to get was to create an SVG document containing map (all
>> the tiles, either from map or track tiles). It looked significantly better
>> than our
>> previous drawing mechanism. While it was much less and much simpler code.
>> Also it scaled nicely.
>>
>>    What the code was missing was:
>> (1) drawing station tokens,
>> (2) drawing train paths,
>> (3) handling scaling and scrolling well,
>> (4) support tile selection.
>>
>>    First two would likely require some "hacking" as there is no easy way
>> currently to do it in SVG Document as there is not "specification" of
>> tracks
>> and stations on an SVG tile. But previous code did it somehow and I guess
>> that solution could be used with SVG Document as well until (if ever) SVG
>> tiles will receive better description. (That is a topic interesting on its
>> own...)
>
> The tracks and the token spot locations are also (somewhat cryptically)
> defined in Tiles.xml, and these definitions are currently used to draw the
> train paths and tokens.
> For the time being (or perhaps forever) that can be left as is, drawing
> these objects in the top layer of the JLayeredPane that I'm currently using.
> However, that would still require achieving correct alignment of the two
> layers after zooming.
>
>>    I tries to handle third  by using JSVGSrolledPane (or something called
>> similarly) but didn't achieve much. Then I had to interrupt my
>> investigations.
>
> I have also been thinking about JSVGScrolledPane, but I think using that
> will only become possible once we manage to do all drawing via JSVG.
>
>>    Fourth should be easy as Batik provides some events to detect this. I
>> expect this could be even easier then current mouse handling. Borders
>> around selected or marked tiles could likely be achieved easily with CSS
>> in the
>> SVG Document.
>
> Sounds good.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Background Maps

[Adam B. <ab...@o2...>]

Sorry for the delay but I decided to adapt the patch to current code 
revision and have a look whether it does what I recall it did. Also I 
removed some additional works on symbols which I was doing along (this was 
the reason to start this work) but would be only distracting now.

The code is mostly not documented as it is a working patch. Its not also 
"clean". But it does show that SVG Document isn't that hard. (To scroll or 
zoom use standard Batik components ways: Shift/Ctrl + moves with mouse 
buttons pressed.)

So what do you think? Should I continue my work in this area?

Adam Badura

-----Oryginalna wiadomość----- 
From: Erik Vos
Sent: Monday, June 06, 2011 2:43 PM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Background Maps

Adam,

Congratulations with your second child!

I'm certainly interested to have a look at your code, to check if I can 
merge it with my map display code.

Some more comments below.

> -----Oorspronkelijk bericht-----
> Van: Adam Badura [mailto:ab...@o2...]
>
>     I was working on moving entire drawing to SVG (and this was one of the
> reasons I tried to push Batik 1.7). But recently my second child was born 
> and
> there is some little chaos in my life with not much time for such tasks.
> I still have SVN Patch yet it is already conflicting at some places with 
> new
> code.
>
>     What I managed to get was to create an SVG document containing map 
> (all
> the tiles, either from map or track tiles). It looked significantly better 
> than our
> previous drawing mechanism. While it was much less and much simpler code.
> Also it scaled nicely.
>
>     What the code was missing was:
> (1) drawing station tokens,
> (2) drawing train paths,
> (3) handling scaling and scrolling well,
> (4) support tile selection.
>
>     First two would likely require some "hacking" as there is no easy way
> currently to do it in SVG Document as there is not "specification" of 
> tracks
> and stations on an SVG tile. But previous code did it somehow and I guess
> that solution could be used with SVG Document as well until (if ever) SVG
> tiles will receive better description. (That is a topic interesting on its
> own...)

The tracks and the token spot locations are also (somewhat cryptically) 
defined in Tiles.xml, and these definitions are currently used to draw the 
train paths and tokens.
For the time being (or perhaps forever) that can be left as is, drawing 
these objects in the top layer of the JLayeredPane that I'm currently using.
However, that would still require achieving correct alignment of the two 
layers after zooming.

>     I tries to handle third  by using JSVGSrolledPane (or something called
> similarly) but didn't achieve much. Then I had to interrupt my 
> investigations.

I have also been thinking about JSVGScrolledPane, but I think using that 
will only become possible once we manage to do all drawing via JSVG.

>     Fourth should be easy as Batik provides some events to detect this. I
> expect this could be even easier then current mouse handling. Borders
> around selected or marked tiles could likely be achieved easily with CSS 
> in the
> SVG Document.

Sounds good.

Erik.


------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] Background Maps

[Erik V. <eri...@xs...>]

Adam,

Congratulations with your second child!

I'm certainly interested to have a look at your code, to check if I can merge it with my map display code. 

Some more comments below.

> -----Oorspronkelijk bericht-----
> Van: Adam Badura [mailto:ab...@o2...]
> 
>     I was working on moving entire drawing to SVG (and this was one of the
> reasons I tried to push Batik 1.7). But recently my second child was born and
> there is some little chaos in my life with not much time for such tasks.
> I still have SVN Patch yet it is already conflicting at some places with new
> code.
> 
>     What I managed to get was to create an SVG document containing map (all
> the tiles, either from map or track tiles). It looked significantly better than our
> previous drawing mechanism. While it was much less and much simpler code.
> Also it scaled nicely.
> 
>     What the code was missing was:
> (1) drawing station tokens,
> (2) drawing train paths,
> (3) handling scaling and scrolling well,
> (4) support tile selection.
> 
>     First two would likely require some "hacking" as there is no easy way
> currently to do it in SVG Document as there is not "specification" of tracks
> and stations on an SVG tile. But previous code did it somehow and I guess
> that solution could be used with SVG Document as well until (if ever) SVG
> tiles will receive better description. (That is a topic interesting on its
> own...)

The tracks and the token spot locations are also (somewhat cryptically) defined in Tiles.xml, and these definitions are currently used to draw the train paths and tokens.
For the time being (or perhaps forever) that can be left as is, drawing these objects in the top layer of the JLayeredPane that I'm currently using.
However, that would still require achieving correct alignment of the two layers after zooming.

>     I tries to handle third  by using JSVGSrolledPane (or something called
> similarly) but didn't achieve much. Then I had to interrupt my investigations.

I have also been thinking about JSVGScrolledPane, but I think using that will only become possible once we manage to do all drawing via JSVG.

>     Fourth should be easy as Batik provides some events to detect this. I
> expect this could be even easier then current mouse handling. Borders
> around selected or marked tiles could likely be achieved easily with CSS in the
> SVG Document.

Sounds good.

Erik.

Re: [Rails-devel] Background Maps

[Adam B. <ab...@o2...>]

    I was working on moving entire drawing to SVG (and this was one of the 
reasons I tried to push Batik 1.7). But recently my second child was born 
and there is some little chaos in my life with not much time for such tasks. 
I still have SVN Patch yet it is already conflicting at some places with new 
code.

    What I managed to get was to create an SVG document containing map (all 
the tiles, either from map or track tiles). It looked significantly better 
than our previous drawing mechanism. While it was much less and much simpler 
code. Also it scaled nicely.

    What the code was missing was:
(1) drawing station tokens,
(2) drawing train paths,
(3) handling scaling and scrolling well,
(4) support tile selection.

    First two would likely require some "hacking" as there is no easy way 
currently to do it in SVG Document as there is not "specification" of tracks 
and stations on an SVG tile. But previous code did it somehow and I guess 
that solution could be used with SVG Document as well until (if ever) SVG 
tiles will receive better description. (That is a topic interesting on its 
own...)
    I tries to handle third  by using JSVGSrolledPane (or something called 
similarly) but didn't achieve much. Then I had to interrupt my 
investigations.
    Fourth should be easy as Batik provides some events to detect this. I 
expect this could be even easier then current mouse handling. Borders around 
selected or marked tiles could likely be achieved easily with CSS in the SVG 
Document.

    I can post that Patch if anyone is interested (but not until I'm at 
home) especially that I don't know whether I will find time to continue this 
work.

    Adam Badura

-----Oryginalna wiadomość----- 
From: Erik Vos
Sent: Monday, June 06, 2011 12:55 PM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Background Maps

I have found the Batik JSVGCanvas approach to be promising.  The main 
problem is the lack of any good documentation, tutorials or how-to's on the 
functionality that we need, and the Javadocs aren't very helpful either. 
After searching during the better part of yesterday, I found some pointers 
on high Google page numbers that finally put me in the right direction.

Some observations:
- The 18EU map loads faster, though not at lightning speed.  The map is big 
(~800K),  XML parsing is notoriously slow, and I suspect initial SVG 
rendering also is.
- The speed of tile drawing is about back to normal.
- Best of all: no more crashes.  That really tips the balance for me.
- Zooming works, but the zoomed map and tiles do not align yet. Tiles are 
still drawn the old way, in a different layer, and using separate 
coordinates.  Alignment currently is a trial-and-error exercise that 
apparently does not survive zooming.

The obvious follow-up is to see if tile drawing can also be moved to the 
JSVGCanvas.  I suppose this will amount to manipulating the underlying DOM. 
I'll probably postpone that until a later stage.

My intention is to commit the new code pretty soon (using the map will 
remain optional).  First I want to give post-zooming alignment a few more 
tries. I'll probably also include Bill Rosgen's suggestions to change hex 
highlighting.

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: vrijdag 3 juni 2011 20:59
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
>
> That sounds like a very possible option. If we can let Batik handle all of 
> the
> image processing internally, that sounds like a win to me.
>
> ---Brett.
>
>
>
> On Fri, Jun 3, 2011 at 11:56 AM, Erik Vos <eri...@xs...> wrote:
> > This stuff is mostly new to me, but on a first look into Batik, I wonder 
> > if we
> could use the Batik Swing interface.
> > Should we change the map into a JSVGCanvas?
> >
> > Or two?  Because, to achieve displaying the map *below* the tiles, I had 
> > to
> insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on
> layer 0 (top).  Without that layered pane, it turned out the other way 
> around
> (don't know why).
> >
> > Erik
> >
> > P.S.  I changed the subject of this thread.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: brett lentz [mailto:bre...@gm...]
> >> Verzonden: vrijdag 3 juni 2011 19:28
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> >> version)
> >>
> >> I have a feeling that old drawing code is just incredibly inefficient
> >> and adding the map might tip it over into unusability. I'll blame my
> >> limited understanding of AWT. It's probably time to refactor a bunch
> >> of that. ;-)
> >>
> >> Some possible places to look for improvements:
> >>
> >> 1.  It looks like we're still using AffineTransforms on the
> >> rasterized version of the hex. (A remnant from when we were still
> >> using GIF-based tiles. There is likely a way to get Batik to
> >> manipulate the vector-based format prior to rasterization in a more
> efficient way.
> >>
> >> Once we rasterize the image, we should avoid changing it.
> >>
> >> 2. There may be a better way to load the map than with
> >> BufferedImageTranscoder.
> >>
> >> 3. Profiling the code will likely help quickly locate the reason 
> >> drawing is
> slow.
> >> It looks like there's some profiling plugins available for Eclipse (
> >> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how
> >> well they work.
> >>
> >> Though, simply adding a few debugging statements starting at paint()
> >> or
> >> paintComponent() might be sufficient to see how often they're called
> >> in a single rendering. It might just be a simple issue of repainting
> >> the window more often than we really need to.
> >>
> >>
> >> ---Brett.
> >>
> >>
> >>
> >> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
> >> > OK, I have attached a patch file that includes all differences.
> >> > Hope it's not
> >> too big...
> >> > The main part is a trimmed version of the 18EU map, with all empty
> >> > borders
> >> removed (by Inkscape).
> >> > I did that in the hope that it would help fixing the crash problem,
> >> > but it
> >> didn't help at all.  But in any case I think it's better to avoid
> >> such empty borders.
> >> >
> >> > Erik.
> >> >
> >> >> -----Oorspronkelijk bericht-----
> >> >> Van: brett lentz [mailto:bre...@gm...]
> >> >> Verzonden: vrijdag 3 juni 2011 16:54
> >> >> Aan: Development list for Rails: an 18xx game
> >> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission
> >> >> (revised
> >> >> version)
> >> >>
> >> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
> >> >> > I would like to give other people a chance to play with this new
> >> >> > stuff, but I'm not sure if I should commit my changes to the SVN
> >> >> > trunk.  Perhaps we should create a  branch for this experimental
> >> >> > feature (but I have no clue how to do that - I've never done
> >> >> branching  before).
> >> >> > On the other hand, I have already added a configuration property
> >> >> > to completely suppress the use of SVG maps, so probably no harm
> >> >> > would be done by putting this code into the trunk anyway.
> >> >> >
> >> >> > Suggestions?
> >> >> >
> >> >>
> >> >> Post your implementation to the list as a set of diffs. Perhaps
> >> >> just a second set of eyes can help spot the issue.
> >> >>
> >> >> > Erik.
> >> >>
> >> >> ---Brett.
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> --------- Simplify data backup and recovery for your virtual
> >> >> environment with vRanger.
> >> >> Installation's a snap, and flexible recovery options mean your
> >> >> data is safe, secure and there when you need it. Discover what all
> >> >> the
> >> cheering's about.
> >> >> Get your free trial download today.
> >> >> http://p.sf.net/sfu/quest-dev2dev2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > -------- Simplify data backup and recovery for your virtual
> >> > environment with vRanger.
> >> > Installation's a snap, and flexible recovery options mean your data
> >> > is safe, secure and there when you need it. Discover what all the
> >> > cheering's
> >> about.
> >> > Get your free trial download today.
> >> > http://p.sf.net/sfu/quest-dev2dev2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> --------- Simplify data backup and recovery for your virtual
> >> environment with vRanger.
> >> Installation's a snap, and flexible recovery options mean your data
> >> is safe, secure and there when you need it. Discover what all the
> cheering's about.
> >> Get your free trial download today.
> >> http://p.sf.net/sfu/quest-dev2dev2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the 
> > cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is 
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] Background Maps

[Erik V. <eri...@xs...>]

I have found the Batik JSVGCanvas approach to be promising.  The main problem is the lack of any good documentation, tutorials or how-to's on the functionality that we need, and the Javadocs aren't very helpful either. After searching during the better part of yesterday, I found some pointers on high Google page numbers that finally put me in the right direction.

Some observations:
- The 18EU map loads faster, though not at lightning speed.  The map is big (~800K),  XML parsing is notoriously slow, and I suspect initial SVG rendering also is.
- The speed of tile drawing is about back to normal.
- Best of all: no more crashes.  That really tips the balance for me.
- Zooming works, but the zoomed map and tiles do not align yet. Tiles are still drawn the old way, in a different layer, and using separate coordinates.  Alignment currently is a trial-and-error exercise that apparently does not survive zooming. 

The obvious follow-up is to see if tile drawing can also be moved to the JSVGCanvas.  I suppose this will amount to manipulating the underlying DOM.  I'll probably postpone that until a later stage. 

My intention is to commit the new code pretty soon (using the map will remain optional).  First I want to give post-zooming alignment a few more tries. I'll probably also include Bill Rosgen's suggestions to change hex highlighting.

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: vrijdag 3 juni 2011 20:59
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
> 
> That sounds like a very possible option. If we can let Batik handle all of the
> image processing internally, that sounds like a win to me.
> 
> ---Brett.
> 
> 
> 
> On Fri, Jun 3, 2011 at 11:56 AM, Erik Vos <eri...@xs...> wrote:
> > This stuff is mostly new to me, but on a first look into Batik, I wonder if we
> could use the Batik Swing interface.
> > Should we change the map into a JSVGCanvas?
> >
> > Or two?  Because, to achieve displaying the map *below* the tiles, I had to
> insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on
> layer 0 (top).  Without that layered pane, it turned out the other way around
> (don't know why).
> >
> > Erik
> >
> > P.S.  I changed the subject of this thread.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: brett lentz [mailto:bre...@gm...]
> >> Verzonden: vrijdag 3 juni 2011 19:28
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> >> version)
> >>
> >> I have a feeling that old drawing code is just incredibly inefficient
> >> and adding the map might tip it over into unusability. I'll blame my
> >> limited understanding of AWT. It's probably time to refactor a bunch
> >> of that. ;-)
> >>
> >> Some possible places to look for improvements:
> >>
> >> 1.  It looks like we're still using AffineTransforms on the
> >> rasterized version of the hex. (A remnant from when we were still
> >> using GIF-based tiles. There is likely a way to get Batik to
> >> manipulate the vector-based format prior to rasterization in a more
> efficient way.
> >>
> >> Once we rasterize the image, we should avoid changing it.
> >>
> >> 2. There may be a better way to load the map than with
> >> BufferedImageTranscoder.
> >>
> >> 3. Profiling the code will likely help quickly locate the reason drawing is
> slow.
> >> It looks like there's some profiling plugins available for Eclipse (
> >> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how
> >> well they work.
> >>
> >> Though, simply adding a few debugging statements starting at paint()
> >> or
> >> paintComponent() might be sufficient to see how often they're called
> >> in a single rendering. It might just be a simple issue of repainting
> >> the window more often than we really need to.
> >>
> >>
> >> ---Brett.
> >>
> >>
> >>
> >> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
> >> > OK, I have attached a patch file that includes all differences.
> >> > Hope it's not
> >> too big...
> >> > The main part is a trimmed version of the 18EU map, with all empty
> >> > borders
> >> removed (by Inkscape).
> >> > I did that in the hope that it would help fixing the crash problem,
> >> > but it
> >> didn't help at all.  But in any case I think it's better to avoid
> >> such empty borders.
> >> >
> >> > Erik.
> >> >
> >> >> -----Oorspronkelijk bericht-----
> >> >> Van: brett lentz [mailto:bre...@gm...]
> >> >> Verzonden: vrijdag 3 juni 2011 16:54
> >> >> Aan: Development list for Rails: an 18xx game
> >> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission
> >> >> (revised
> >> >> version)
> >> >>
> >> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
> >> >> > I would like to give other people a chance to play with this new
> >> >> > stuff, but I'm not sure if I should commit my changes to the SVN
> >> >> > trunk.  Perhaps we should create a  branch for this experimental
> >> >> > feature (but I have no clue how to do that - I've never done
> >> >> branching  before).
> >> >> > On the other hand, I have already added a configuration property
> >> >> > to completely suppress the use of SVG maps, so probably no harm
> >> >> > would be done by putting this code into the trunk anyway.
> >> >> >
> >> >> > Suggestions?
> >> >> >
> >> >>
> >> >> Post your implementation to the list as a set of diffs. Perhaps
> >> >> just a second set of eyes can help spot the issue.
> >> >>
> >> >> > Erik.
> >> >>
> >> >> ---Brett.
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> --------- Simplify data backup and recovery for your virtual
> >> >> environment with vRanger.
> >> >> Installation's a snap, and flexible recovery options mean your
> >> >> data is safe, secure and there when you need it. Discover what all
> >> >> the
> >> cheering's about.
> >> >> Get your free trial download today.
> >> >> http://p.sf.net/sfu/quest-dev2dev2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > -------- Simplify data backup and recovery for your virtual
> >> > environment with vRanger.
> >> > Installation's a snap, and flexible recovery options mean your data
> >> > is safe, secure and there when you need it. Discover what all the
> >> > cheering's
> >> about.
> >> > Get your free trial download today.
> >> > http://p.sf.net/sfu/quest-dev2dev2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> --------- Simplify data backup and recovery for your virtual
> >> environment with vRanger.
> >> Installation's a snap, and flexible recovery options mean your data
> >> is safe, secure and there when you need it. Discover what all the
> cheering's about.
> >> Get your free trial download today.
> >> http://p.sf.net/sfu/quest-dev2dev2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[Phil D. <de...@gm...>]

The backgrounds are always going to be game specific so storing them
underneath the game directory makes sense I think

Phil

On 6 June 2011 11:10, Erik Vos <eri...@xs...> wrote:
> Bill,
>
> Thanks.  I tried it, and if it works, it works well.  But I'm getting
> frequent crashes, so it's again a mixed success.
>
> I like your approach to hex highlighting, and will keep it in mind.  As you
> will see in another mail, I'm already having good results with the Batik
> JSVGCanvas approach, and will certainly pursue that further.  I'm not sure
> if it will turn out to be easy to incorporate tile drawing into that canvas
> too; if not, I might just copy your red hexagon code for the time being.
>
> I'm doubting where to put such maps. I created a separate <svnroot>/maps
> tree, whereas you have put it into <svnroot>/data/18EU.  Perhaps the latter
> makes more sense.
>
> Erik.
>
>
>> -----Oorspronkelijk bericht-----
>> Van: Bill Rosgen [mailto:ro...@gm...]
>> Verzonden: maandag 6 juni 2011 8:30
>> Aan: Erik Vos
>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>> version)
>>
>> Erik,
>>
>> Here are the full text versions of the files I changed.  I didn't
> implement much
>> more than just drawing the map.  There is a little progress towards
> changing
>> the interface to make it work better with a SVG map, but it still needed
> some
>> work.  In particular, the goal was to avoid drawing a red and then white
>> hexagon to highlight a tile (and then cover this with a tile), since it
> seemed
>> both costly and annoying to try to redraw a hexagonal portion of the base
>> map.
>>
>> Essentially I just created a new class GUIMapImage that parrots the code
> in
>> GUITile used to draw tiles (and put a new class in ImageLoader to handle
>> loading the map file).  I also had to make some (minor) changes to HexMap
>> and the other classes to draw the map, but nothing really exciting.  This
> code
>> is also still full of magic numbers and hardcoded strings, as I hadn't
> gotten to
>> implementing any of this in the XML (i.e. path to the map file, the scale,
> and x
>> and y offsets for the map).
>>
>> I don't imagine that there is that much of interest in these files, but
> now you
>> have them.  I agree with the suggestion of handing off more of the image
>> processing to libraries, but haven't looked into it at all.
>>
>> The files included in this tarball are:
>>
>> rails/ui/swing/ImageLoader.java
>>
>> rails/ui/swing/hexmap/GUIHex.java
>> rails/ui/swing/hexmap/GUIMapImage.java
>> rails/ui/swing/hexmap/GUITile.java
>> rails/ui/swing/hexmap/HexMap.java
>>
>> data/18EU/MapImage.svg
>>
>> Bill
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[Erik V. <eri...@xs...>]

Bill,

Thanks.  I tried it, and if it works, it works well.  But I'm getting
frequent crashes, so it's again a mixed success.

I like your approach to hex highlighting, and will keep it in mind.  As you
will see in another mail, I'm already having good results with the Batik
JSVGCanvas approach, and will certainly pursue that further.  I'm not sure
if it will turn out to be easy to incorporate tile drawing into that canvas
too; if not, I might just copy your red hexagon code for the time being.

I'm doubting where to put such maps. I created a separate <svnroot>/maps
tree, whereas you have put it into <svnroot>/data/18EU.  Perhaps the latter
makes more sense.

Erik.


> -----Oorspronkelijk bericht-----
> Van: Bill Rosgen [mailto:ro...@gm...]
> Verzonden: maandag 6 juni 2011 8:30
> Aan: Erik Vos
> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> version)
> 
> Erik,
> 
> Here are the full text versions of the files I changed.  I didn't
implement much
> more than just drawing the map.  There is a little progress towards
changing
> the interface to make it work better with a SVG map, but it still needed
some
> work.  In particular, the goal was to avoid drawing a red and then white
> hexagon to highlight a tile (and then cover this with a tile), since it
seemed
> both costly and annoying to try to redraw a hexagonal portion of the base
> map.
> 
> Essentially I just created a new class GUIMapImage that parrots the code
in
> GUITile used to draw tiles (and put a new class in ImageLoader to handle
> loading the map file).  I also had to make some (minor) changes to HexMap
> and the other classes to draw the map, but nothing really exciting.  This
code
> is also still full of magic numbers and hardcoded strings, as I hadn't
gotten to
> implementing any of this in the XML (i.e. path to the map file, the scale,
and x
> and y offsets for the map).
> 
> I don't imagine that there is that much of interest in these files, but
now you
> have them.  I agree with the suggestion of handing off more of the image
> processing to libraries, but haven't looked into it at all.
> 
> The files included in this tarball are:
> 
> rails/ui/swing/ImageLoader.java
> 
> rails/ui/swing/hexmap/GUIHex.java
> rails/ui/swing/hexmap/GUIMapImage.java
> rails/ui/swing/hexmap/GUITile.java
> rails/ui/swing/hexmap/HexMap.java
> 
> data/18EU/MapImage.svg
> 
> Bill

[Rails-devel] 1889 Bug (and patch): D Private doesn't get free tile lays

[Bill R. <ro...@gm...>]

In a game I am playing, we encountered a bug in 1.4.2 that is not in 1.4.1.  Specifically, there is a company with the D private, which allows free tiles to be laid in the mountains (in rails XML, these tile lays are free="yes" and extra="no").  The attached .rails file exhibits the problem: Brad's TR does not get offered a free tile lay in F5.

Tracking the problem down lead to the method getSpecialTileLays in OperatingRound: when testing to see if special tile lays with extra="no" are possible, this method checks to see if the tile specified in the SpecialTileLay can be laid.  Unfortunately in the 1889 Private D is not restricted to a specific tile, so the action wasn't being added to the list.  The attached patch changes this to a different (and I think equivalent?) method of testing if normal tile lays are still available -- I check that the map tileLaysPerColour is not empty (as is done by the method areTileLaysPossible when it tests if normal tile lays are available).

It is not clear to me that this is the best solution.  Other solutions might be:

1) Add three SpecialTileLays to Private D in 1889, one for each available tile (7,8,9, in this case)
2) Change SpecialTileLay to keep a list of available tiles, with corresponding changes to OperatingRound and LayTile
3) If the tile in SpecialTileLay is null, treat this as no restriction: get the lists of all available tiles in the restricted hexes and check to see if any of them are valid, adding LayTile actions as appropriate.

Bill Rosgen

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[Erik V. <eri...@xs...>]

Bill,

Sending me either a patch or a set of full copies of all changed files might
help, but I'm not sure to what extent I would really use it. I could try to
run it, or I might just keep it as a visual reference to compare our
approaches.  In any case, don't put much effort into it.  I'm myself now
about to try the Batik/Swing interface, as discussed with Brett.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Bill Rosgen [mailto:ro...@gm...]
> Verzonden: vrijdag 3 juni 2011 16:49
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> version)
> 
> I've also partly implemented this.  I've gotten as far as displaying the
map and
> getting it in the right place at the right size with an attempt to make
the rest
> of the interface work.  My implementation also has some problems:
> 
> - It is slow.  Drawing the map the first time takes a long time (10
seconds, or
> so, on my laptop)
> - The rest of the interface doesn't really match: I've had to suppress /
change
> the usual red outline displayed around tiles that are selected or eligible
for
> building.
> - I have yet to put any of this into XML -- it's currently all hardcoded
(size, x,y
> offset, filename of the map, etc.).
> 
> I can send you my code, but I'm not sure what is the best way to do it.  I
can
> send a patch against the current svn code, but that may not be useful if
> you've also modified many of the same things.  I've not experienced any
> crashes, but it's not clear that my code wouldn't also crash on your
machine.
> 
> Bill
> 
> On 2011-06-03, at 20:43 , Erik Vos wrote:
> 
> > I have partly implemented displaying the 18EU SVG background map, with
> > mixed success.
> > See http://voshw.home.xs4all.nl/18EUmap.jpg for a screenshot (which is
> > not very sharp, the original display is a lot better).
> > To me, it looks fine. (I haven't done zooming yet, and the tile lay
> > costs and other overlays have not yet been suppressed.)
> >
> > However, there are some issues:
> > - I'm regularly seeing the Hotspot JVM crash with an
> > EXCEPTION_ACCESS_VIOLATION message (I'm running Rails from Eclipse). I
> > have quite a lot of different error reports, which don't help me one
> > bit. One possible cause I found on the web refers to garbage
> > collection.  I tried to increase memory, and indeed that seems to
> > reduce the problem (I'm now using -Xmx1024m), but the crashes have not
> completely disappeared.
> > - Map window initialization has markedly slowed down, and map actions
> > such as laying tiles have become pretty sluggish.  Displaying tooltips
> > has also slowed down.
> >
> > I would like to give other people a chance to play with this new
> > stuff, but I'm not sure if I should commit my changes to the SVN
> > trunk.  Perhaps we should create a  branch for this experimental
> > feature (but I have no clue how to do that - I've never done branching
> before).
> > On the other hand, I have already added a configuration property to
> > completely suppress the use of SVG maps, so probably no harm would be
> > done by putting this code into the trunk anyway.
> >
> > Suggestions?
> >
> > Erik.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Erik Vos [mailto:eri...@xs...]
> >> Verzonden: maandag 23 mei 2011 9:31
> >> Aan: 'Development list for Rails: an 18xx game'
> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> >> version)
> >>
> >> Thanks Bill, this looks pretty good.
> >>
> >> There is no hurry with working this out; from my side it has always
> >> been a long shot.
> >> Feel free to experiment, otherwise I will do so over time.
> >>
> >> I suppose we'll need an extra <Image> tag in Map.xml, with attributes
> >> filename, x, y, scale.
> >> In presence of a map image, displaying all tiles with non-positive
> >> numbers (i.e., preprinted tiles) should be suppressed (except when
> >> testing alignment).
> >>
> >> Erik.
> >>
> >>> -----Oorspronkelijk bericht-----
> >>> Van: Bill Rosgen [mailto:ro...@gm...]
> >>> Verzonden: maandag 23 mei 2011 4:23
> >>> Aan: Development list for Rails: an 18xx game
> >>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission
> >>> (revised
> >>> version)
> >>>
> >>> Here's another attempt, as I have a copy of Adobe Illustrator, so
> >>> can
> >> convert
> >>> the PDF to SVG -- in theory without losing anything.  Let me know if
> >>> this
> >> file is
> >>> readable on other systems (I've tested it in Safari and it seems to
> >>> work
> >> fine).
> >>>
> >>> I've also removed some of the 'unnecessary' elements, such as the
> >>> income track, the hex numbers (since Rails will also display them?).
> >>> It's easy
> >> for me
> >>> to leave things like hex-numbers on the map, if desired -- creating
> >>> this
> >> file
> >>> took literally about 5 minutes, so I don't mind making other versions.
> >>>
> >>> Note that this file is *not* my artwork: I've just taken John
> >>> Tamplin's
> >> PDF and
> >>> converted it to SVG.  He probably doesn't mind, since he's
> >>> distributing
> >> the
> >>> PDF anyway, but this might be something to think about regarding
> >>> other games.  I can also re-draw some of the other maps that we
> >>> don't have PDFs for, but they won't look exactly like the printed
> >>> versions do, and this
> >> will take
> >>> more time.
> >>>
> >>> I can take a look at displaying this in Rails, but I'm likely to be
> >>> busy
> >> for about
> >>> the next week, so I can't make any promises regarding timeliness.
> >>>
> >>> Bill
> >>
> >>
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> What Every C/C++ and Fortran developer Should Know!
> >> Read this article and learn how Intel has extended the reach of its
> >> next- generation tools to help Windows* and Linux* C/C++ and Fortran
> >> developers boost performance applications - including clusters.
> >> http://p.sf.net/sfu/intel-dev2devmay
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the
cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background Maps

[brett l. <bre...@gm...>]

That sounds like a very possible option. If we can let Batik handle
all of the image processing internally, that sounds like a win to me.

---Brett.



On Fri, Jun 3, 2011 at 11:56 AM, Erik Vos <eri...@xs...> wrote:
> This stuff is mostly new to me, but on a first look into Batik, I wonder if we could use the Batik Swing interface.
> Should we change the map into a JSVGCanvas?
>
> Or two?  Because, to achieve displaying the map *below* the tiles, I had to insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on layer 0 (top).  Without that layered pane, it turned out the other way around (don't know why).
>
> Erik
>
> P.S.  I changed the subject of this thread.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: vrijdag 3 juni 2011 19:28
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>> version)
>>
>> I have a feeling that old drawing code is just incredibly inefficient and adding
>> the map might tip it over into unusability. I'll blame my limited understanding
>> of AWT. It's probably time to refactor a bunch of that. ;-)
>>
>> Some possible places to look for improvements:
>>
>> 1.  It looks like we're still using AffineTransforms on the rasterized version of
>> the hex. (A remnant from when we were still using GIF-based tiles. There is
>> likely a way to get Batik to manipulate the vector-based format prior to
>> rasterization in a more efficient way.
>>
>> Once we rasterize the image, we should avoid changing it.
>>
>> 2. There may be a better way to load the map than with
>> BufferedImageTranscoder.
>>
>> 3. Profiling the code will likely help quickly locate the reason drawing is slow.
>> It looks like there's some profiling plugins available for Eclipse (
>> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how well
>> they work.
>>
>> Though, simply adding a few debugging statements starting at paint() or
>> paintComponent() might be sufficient to see how often they're called in a
>> single rendering. It might just be a simple issue of repainting the window
>> more often than we really need to.
>>
>>
>> ---Brett.
>>
>>
>>
>> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
>> > OK, I have attached a patch file that includes all differences.  Hope it's not
>> too big...
>> > The main part is a trimmed version of the 18EU map, with all empty borders
>> removed (by Inkscape).
>> > I did that in the hope that it would help fixing the crash problem, but it
>> didn't help at all.  But in any case I think it's better to avoid such empty
>> borders.
>> >
>> > Erik.
>> >
>> >> -----Oorspronkelijk bericht-----
>> >> Van: brett lentz [mailto:bre...@gm...]
>> >> Verzonden: vrijdag 3 juni 2011 16:54
>> >> Aan: Development list for Rails: an 18xx game
>> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>> >> version)
>> >>
>> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
>> >> > I would like to give other people a chance to play with this new
>> >> > stuff, but I'm not sure if I should commit my changes to the SVN
>> >> > trunk.  Perhaps we should create a  branch for this experimental
>> >> > feature (but I have no clue how to do that - I've never done
>> >> branching  before).
>> >> > On the other hand, I have already added a configuration property to
>> >> > completely suppress the use of SVG maps, so probably no harm would
>> >> > be done by putting this code into the trunk anyway.
>> >> >
>> >> > Suggestions?
>> >> >
>> >>
>> >> Post your implementation to the list as a set of diffs. Perhaps just
>> >> a second set of eyes can help spot the issue.
>> >>
>> >> > Erik.
>> >>
>> >> ---Brett.
>> >>
>> >> ---------------------------------------------------------------------
>> >> --------- Simplify data backup and recovery for your virtual
>> >> environment with vRanger.
>> >> Installation's a snap, and flexible recovery options mean your data
>> >> is safe, secure and there when you need it. Discover what all the
>> cheering's about.
>> >> Get your free trial download today.
>> >> http://p.sf.net/sfu/quest-dev2dev2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > ----------------------------------------------------------------------
>> > -------- Simplify data backup and recovery for your virtual
>> > environment with vRanger.
>> > Installation's a snap, and flexible recovery options mean your data is
>> > safe, secure and there when you need it. Discover what all the cheering's
>> about.
>> > Get your free trial download today.
>> > http://p.sf.net/sfu/quest-dev2dev2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Discover what all the cheering's about.
>> Get your free trial download today.
>> http://p.sf.net/sfu/quest-dev2dev2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Background Maps

[Erik V. <eri...@xs...>]

This stuff is mostly new to me, but on a first look into Batik, I wonder if we could use the Batik Swing interface.
Should we change the map into a JSVGCanvas? 

Or two?  Because, to achieve displaying the map *below* the tiles, I had to insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on layer 0 (top).  Without that layered pane, it turned out the other way around (don't know why).

Erik 

P.S.  I changed the subject of this thread.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: vrijdag 3 juni 2011 19:28
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> version)
> 
> I have a feeling that old drawing code is just incredibly inefficient and adding
> the map might tip it over into unusability. I'll blame my limited understanding
> of AWT. It's probably time to refactor a bunch of that. ;-)
> 
> Some possible places to look for improvements:
> 
> 1.  It looks like we're still using AffineTransforms on the rasterized version of
> the hex. (A remnant from when we were still using GIF-based tiles. There is
> likely a way to get Batik to manipulate the vector-based format prior to
> rasterization in a more efficient way.
> 
> Once we rasterize the image, we should avoid changing it.
> 
> 2. There may be a better way to load the map than with
> BufferedImageTranscoder.
> 
> 3. Profiling the code will likely help quickly locate the reason drawing is slow.
> It looks like there's some profiling plugins available for Eclipse (
> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how well
> they work.
> 
> Though, simply adding a few debugging statements starting at paint() or
> paintComponent() might be sufficient to see how often they're called in a
> single rendering. It might just be a simple issue of repainting the window
> more often than we really need to.
> 
> 
> ---Brett.
> 
> 
> 
> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
> > OK, I have attached a patch file that includes all differences.  Hope it's not
> too big...
> > The main part is a trimmed version of the 18EU map, with all empty borders
> removed (by Inkscape).
> > I did that in the hope that it would help fixing the crash problem, but it
> didn't help at all.  But in any case I think it's better to avoid such empty
> borders.
> >
> > Erik.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: brett lentz [mailto:bre...@gm...]
> >> Verzonden: vrijdag 3 juni 2011 16:54
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> >> version)
> >>
> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
> >> > I would like to give other people a chance to play with this new
> >> > stuff, but I'm not sure if I should commit my changes to the SVN
> >> > trunk.  Perhaps we should create a  branch for this experimental
> >> > feature (but I have no clue how to do that - I've never done
> >> branching  before).
> >> > On the other hand, I have already added a configuration property to
> >> > completely suppress the use of SVG maps, so probably no harm would
> >> > be done by putting this code into the trunk anyway.
> >> >
> >> > Suggestions?
> >> >
> >>
> >> Post your implementation to the list as a set of diffs. Perhaps just
> >> a second set of eyes can help spot the issue.
> >>
> >> > Erik.
> >>
> >> ---Brett.
> >>
> >> ---------------------------------------------------------------------
> >> --------- Simplify data backup and recovery for your virtual
> >> environment with vRanger.
> >> Installation's a snap, and flexible recovery options mean your data
> >> is safe, secure and there when you need it. Discover what all the
> cheering's about.
> >> Get your free trial download today.
> >> http://p.sf.net/sfu/quest-dev2dev2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[brett l. <bre...@gm...>]

I have a feeling that old drawing code is just incredibly inefficient
and adding the map might tip it over into unusability. I'll blame my
limited understanding of AWT. It's probably time to refactor a bunch
of that. ;-)

Some possible places to look for improvements:

1.  It looks like we're still using AffineTransforms on the rasterized
version of the hex. (A remnant from when we were still using GIF-based
tiles. There is likely a way to get Batik to manipulate the
vector-based format prior to rasterization in a more efficient way.

Once we rasterize the image, we should avoid changing it.

2. There may be a better way to load the map than with BufferedImageTranscoder.

3. Profiling the code will likely help quickly locate the reason
drawing is slow. It looks like there's some profiling plugins
available for Eclipse ( http://www.eclipse.org/tptp/home/downloads/ ),
but I'm not sure how well they work.

Though, simply adding a few debugging statements starting at paint()
or paintComponent() might be sufficient to see how often they're
called in a single rendering. It might just be a simple issue of
repainting the window more often than we really need to.

---Brett.



On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
> OK, I have attached a patch file that includes all differences.  Hope it's not too big...
> The main part is a trimmed version of the 18EU map, with all empty borders removed (by Inkscape).
> I did that in the hope that it would help fixing the crash problem, but it didn't help at all.  But in any case I think it's better to avoid such empty borders.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: vrijdag 3 juni 2011 16:54
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>> version)
>>
>> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
>> > I would like to give other people a chance to play with this new
>> > stuff, but I'm not sure if I should commit my changes to the SVN
>> > trunk.  Perhaps we should create a  branch for this experimental
>> > feature (but I have no clue how to do that - I've never done
>> branching  before).
>> > On the other hand, I have already added a configuration property to
>> > completely suppress the use of SVG maps, so probably no harm would be
>> > done by putting this code into the trunk anyway.
>> >
>> > Suggestions?
>> >
>>
>> Post your implementation to the list as a set of diffs. Perhaps just a second
>> set of eyes can help spot the issue.
>>
>> > Erik.
>>
>> ---Brett.
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Discover what all the cheering's about.
>> Get your free trial download today.
>> http://p.sf.net/sfu/quest-dev2dev2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[Erik V. <eri...@xs...>]

OK, I have attached a patch file that includes all differences.  Hope it's not too big...
The main part is a trimmed version of the 18EU map, with all empty borders removed (by Inkscape). 
I did that in the hope that it would help fixing the crash problem, but it didn't help at all.  But in any case I think it's better to avoid such empty borders.

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: vrijdag 3 juni 2011 16:54
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> version)
> 
> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
> > I would like to give other people a chance to play with this new
> > stuff, but I'm not sure if I should commit my changes to the SVN
> > trunk.  Perhaps we should create a  branch for this experimental
> > feature (but I have no clue how to do that - I've never done
> branching  before).
> > On the other hand, I have already added a configuration property to
> > completely suppress the use of SVG maps, so probably no harm would be
> > done by putting this code into the trunk anyway.
> >
> > Suggestions?
> >
> 
> Post your implementation to the list as a set of diffs. Perhaps just a second
> set of eyes can help spot the issue.
> 
> > Erik.
> 
> ---Brett.
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[brett l. <bre...@gm...>]

On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
> I would like to give other people a chance to play with this new stuff, but
> I'm not sure if I should commit my changes to the SVN trunk.  Perhaps we
> should create a  branch for this experimental feature (but I have no clue
> how to do that - I've never done branching  before).
> On the other hand, I have already added a configuration property to
> completely suppress the use of SVG maps, so probably no harm would be done
> by putting this code into the trunk anyway.
>
> Suggestions?
>

Post your implementation to the list as a set of diffs. Perhaps just a
second set of eyes can help spot the issue.

> Erik.

---Brett.

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[Bill R. <ro...@gm...>]

I've also partly implemented this.  I've gotten as far as displaying the map and getting it in the right place at the right size with an attempt to make the rest of the interface work.  My implementation also has some problems:

- It is slow.  Drawing the map the first time takes a long time (10 seconds, or so, on my laptop)
- The rest of the interface doesn't really match: I've had to suppress / change the usual red outline displayed around tiles that are selected or eligible for building.
- I have yet to put any of this into XML -- it's currently all hardcoded (size, x,y offset, filename of the map, etc.).

I can send you my code, but I'm not sure what is the best way to do it.  I can send a patch against the current svn code, but that may not be useful if you've also modified many of the same things.  I've not experienced any crashes, but it's not clear that my code wouldn't also crash on your machine.

Bill

On 2011-06-03, at 20:43 , Erik Vos wrote:

> I have partly implemented displaying the 18EU SVG background map, with mixed
> success.
> See http://voshw.home.xs4all.nl/18EUmap.jpg for a screenshot (which is not
> very sharp, the original display is a lot better). 
> To me, it looks fine. (I haven't done zooming yet, and the tile lay costs
> and other overlays have not yet been suppressed.)
> 
> However, there are some issues:
> - I'm regularly seeing the Hotspot JVM crash with an
> EXCEPTION_ACCESS_VIOLATION message (I'm running Rails from Eclipse). I have
> quite a lot of different error reports, which don't help me one bit. One
> possible cause I found on the web refers to garbage collection.  I tried to
> increase memory, and indeed that seems to reduce the problem (I'm now using
> -Xmx1024m), but the crashes have not completely disappeared.
> - Map window initialization has markedly slowed down, and map actions such
> as laying tiles have become pretty sluggish.  Displaying tooltips has also
> slowed down.
> 
> I would like to give other people a chance to play with this new stuff, but
> I'm not sure if I should commit my changes to the SVN trunk.  Perhaps we
> should create a  branch for this experimental feature (but I have no clue
> how to do that - I've never done branching  before).
> On the other hand, I have already added a configuration property to
> completely suppress the use of SVG maps, so probably no harm would be done
> by putting this code into the trunk anyway.
> 
> Suggestions?
> 
> Erik.
> 
>> -----Oorspronkelijk bericht-----
>> Van: Erik Vos [mailto:eri...@xs...]
>> Verzonden: maandag 23 mei 2011 9:31
>> Aan: 'Development list for Rails: an 18xx game'
>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>> version)
>> 
>> Thanks Bill, this looks pretty good.
>> 
>> There is no hurry with working this out; from my side it has always been a
>> long shot.
>> Feel free to experiment, otherwise I will do so over time.
>> 
>> I suppose we'll need an extra <Image> tag in Map.xml, with attributes
>> filename, x, y, scale.
>> In presence of a map image, displaying all tiles with non-positive numbers
>> (i.e., preprinted tiles) should be suppressed (except when testing
>> alignment).
>> 
>> Erik.
>> 
>>> -----Oorspronkelijk bericht-----
>>> Van: Bill Rosgen [mailto:ro...@gm...]
>>> Verzonden: maandag 23 mei 2011 4:23
>>> Aan: Development list for Rails: an 18xx game
>>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>>> version)
>>> 
>>> Here's another attempt, as I have a copy of Adobe Illustrator, so can
>> convert
>>> the PDF to SVG -- in theory without losing anything.  Let me know if
>>> this
>> file is
>>> readable on other systems (I've tested it in Safari and it seems to
>>> work
>> fine).
>>> 
>>> I've also removed some of the 'unnecessary' elements, such as the
>>> income track, the hex numbers (since Rails will also display them?).
>>> It's easy
>> for me
>>> to leave things like hex-numbers on the map, if desired -- creating
>>> this
>> file
>>> took literally about 5 minutes, so I don't mind making other versions.
>>> 
>>> Note that this file is *not* my artwork: I've just taken John
>>> Tamplin's
>> PDF and
>>> converted it to SVG.  He probably doesn't mind, since he's
>>> distributing
>> the
>>> PDF anyway, but this might be something to think about regarding other
>>> games.  I can also re-draw some of the other maps that we don't have
>>> PDFs for, but they won't look exactly like the printed versions do,
>>> and this
>> will take
>>> more time.
>>> 
>>> I can take a look at displaying this in Rails, but I'm likely to be
>>> busy
>> for about
>>> the next week, so I can't make any promises regarding timeliness.
>>> 
>>> Bill
>> 
>> 
>> 
>> 
> ----------------------------------------------------------------------------
> --
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its next-
>> generation tools to help Windows* and Linux* C/C++ and Fortran developers
>> boost performance applications - including clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today. 
> http://p.sf.net/sfu/quest-dev2dev2 
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Background Map submission (revised version)

[Erik V. <eri...@xs...>]

I have partly implemented displaying the 18EU SVG background map, with mixed
success.
See http://voshw.home.xs4all.nl/18EUmap.jpg for a screenshot (which is not
very sharp, the original display is a lot better). 
To me, it looks fine. (I haven't done zooming yet, and the tile lay costs
and other overlays have not yet been suppressed.)

However, there are some issues:
- I'm regularly seeing the Hotspot JVM crash with an
EXCEPTION_ACCESS_VIOLATION message (I'm running Rails from Eclipse). I have
quite a lot of different error reports, which don't help me one bit. One
possible cause I found on the web refers to garbage collection.  I tried to
increase memory, and indeed that seems to reduce the problem (I'm now using
-Xmx1024m), but the crashes have not completely disappeared.
- Map window initialization has markedly slowed down, and map actions such
as laying tiles have become pretty sluggish.  Displaying tooltips has also
slowed down.

I would like to give other people a chance to play with this new stuff, but
I'm not sure if I should commit my changes to the SVN trunk.  Perhaps we
should create a  branch for this experimental feature (but I have no clue
how to do that - I've never done branching  before).
On the other hand, I have already added a configuration property to
completely suppress the use of SVG maps, so probably no harm would be done
by putting this code into the trunk anyway.

Suggestions?

Erik.

> -----Oorspronkelijk bericht-----
> Van: Erik Vos [mailto:eri...@xs...]
> Verzonden: maandag 23 mei 2011 9:31
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> version)
> 
> Thanks Bill, this looks pretty good.
> 
> There is no hurry with working this out; from my side it has always been a
> long shot.
> Feel free to experiment, otherwise I will do so over time.
> 
> I suppose we'll need an extra <Image> tag in Map.xml, with attributes
> filename, x, y, scale.
> In presence of a map image, displaying all tiles with non-positive numbers
> (i.e., preprinted tiles) should be suppressed (except when testing
> alignment).
> 
> Erik.
> 
> > -----Oorspronkelijk bericht-----
> > Van: Bill Rosgen [mailto:ro...@gm...]
> > Verzonden: maandag 23 mei 2011 4:23
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> > version)
> >
> > Here's another attempt, as I have a copy of Adobe Illustrator, so can
> convert
> > the PDF to SVG -- in theory without losing anything.  Let me know if
> > this
> file is
> > readable on other systems (I've tested it in Safari and it seems to
> > work
> fine).
> >
> > I've also removed some of the 'unnecessary' elements, such as the
> > income track, the hex numbers (since Rails will also display them?).
> > It's easy
> for me
> > to leave things like hex-numbers on the map, if desired -- creating
> > this
> file
> > took literally about 5 minutes, so I don't mind making other versions.
> >
> > Note that this file is *not* my artwork: I've just taken John
> > Tamplin's
> PDF and
> > converted it to SVG.  He probably doesn't mind, since he's
> > distributing
> the
> > PDF anyway, but this might be something to think about regarding other
> > games.  I can also re-draw some of the other maps that we don't have
> > PDFs for, but they won't look exactly like the printed versions do,
> > and this
> will take
> > more time.
> >
> > I can take a look at displaying this in Rails, but I'm likely to be
> > busy
> for about
> > the next week, so I can't make any promises regarding timeliness.
> >
> > Bill
> 
> 
> 
>
----------------------------------------------------------------------------
--
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its next-
> generation tools to help Windows* and Linux* C/C++ and Fortran developers
> boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel