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