From: Stefan F. <ste...@we...> - 2011-11-08 22:55:01
|
I have fixed several issues in the code to display SVG background maps. To test if SVG maps are a possible solution for Rails I have asked Peter Mumford for his 18GA map, which is available on boardgamegeek. Fortunately he provided a SVG conversion that I have added to the repository. The other map that was already available, but was not usable to the code issues, is for 18EU. Anyone who want to test background maps in development has to activate the configuration setting in the configuration menu in the Map panel => Display Background map. I would be glad to get some feedback for different hardware. On my large external TFT monitor everything is perfect readable, however the fonts of the 18GA map on my notebook display are somehow small. Stefan |
From: Erik V. <eri...@xs...> - 2011-11-08 23:08:17
|
That's a big achievement! Thanks, Stefan. Zooming now works fine (except the first time, strange enough, for both 18EU and 18GA). Erik. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Tuesday, November 08, 2011 11:58 PM > To: Development list for Rails: an 18xx game > Subject: [Rails-devel] Background maps > > I have fixed several issues in the code to display SVG background maps. > > To test if SVG maps are a possible solution for Rails I have asked Peter > Mumford for his 18GA map, which is available on boardgamegeek. > Fortunately he provided a SVG conversion that I have added to the > repository. > > The other map that was already available, but was not usable to the code > issues, is for 18EU. > > Anyone who want to test background maps in development has to activate > the configuration setting in the configuration menu in the Map panel => > Display Background map. > > I would be glad to get some feedback for different hardware. On my large > external TFT monitor everything is perfect readable, however the fonts of > the 18GA map on my notebook display are somehow small. > > Stefan > > ---------------------------------------------------------------------------- -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Stefan F. <ste...@we...> - 2011-11-11 06:30:41
|
On Wednesday, November 09, 2011 12:08:09 am Erik Vos wrote: > That's a big achievement! Thanks, Stefan. > > Erik. > Thanks to your preparations, but my contribution was merely to fix some bugs: Main issues were that the scale variable was defined as an integer, so that rounding errors occurred and the an assignment of a Dimension object variable where in reality a cloning was required. To state my level of happiness for this code: The combination of a SVG canvas for the background map in a layer behind a Swing Canvas, which are aligned by manual calibration, acts only as a work- around solution. Especially as tiles are SVG themselves but they get converted to BufferedImages and then painted on the Swing Canvas. In the long run I suggest to follow the approach that Adam Badura suggested with his patch recently: A joint SVG document is manipulated to combine all graphic elements and is rendered by batik. A possible alternative is to paint everything on one or two instances of JSVGCanvas. > Zooming now works fine (except the first time, strange enough, for both > 18EU and 18GA). I have not experienced the effect: What exactly is the bug (not zooming, background and tile have deviate in zoom) and is it reproducible at any start-up or was it really only the first time you have started a game of 18GA and 18EU? > > -----Original Message----- > > From: Stefan Frey [mailto:ste...@we...] > > Sent: Tuesday, November 08, 2011 11:58 PM > > To: Development list for Rails: an 18xx game > > Subject: [Rails-devel] Background maps > > > > I have fixed several issues in the code to display SVG background maps. > > > > To test if SVG maps are a possible solution for Rails I have asked Peter > > Mumford for his 18GA map, which is available on boardgamegeek. > > Fortunately he provided a SVG conversion that I have added to the > > repository. > > > > The other map that was already available, but was not usable to the code > > issues, is for 18EU. > > > > Anyone who want to test background maps in development has to activate > > the configuration setting in the configuration menu in the Map panel => > > Display Background map. > > > > I would be glad to get some feedback for different hardware. On my large > > external TFT monitor everything is perfect readable, however the fonts of > > the 18GA map on my notebook display are somehow small. > > > > Stefan > > --------------------------------------------------------------------------- > - -- > > > RSA(R) Conference 2012 > > Save $700 by Nov 18 > > Register now > > http://p.sf.net/sfu/rsa-sfdev2dev1 > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > --------------------------------------------------------------------------- > --- RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@xs...> - 2011-11-11 09:11:21
|
> > Zooming now works fine (except the first time, strange enough, for > > both 18EU and 18GA). > > I have not experienced the effect: What exactly is the bug (not zooming, > background and tile have deviate in zoom) and is it reproducible at any start- > up or was it really only the first time you have started a game of 18GA and > 18EU? Before your changes it went wrong consistently and (I think) in a reproducible way. I don't understand why it still went wrong the first time after I pulled your changes; it was as if Rails was still running without these changes. Anyway, what happened in the past was, that when I reversed the zooming direction (from in to out or vice versa), the map did not change scale once (or maybe twice). Something like: 1. Zoom in: all OK. 2. Zoom in: still OK. 3. Zoom out: tiles zoom out, map unchanged. 4 (or 5). Zoom out: both zoom out, but remain out of sync. That misbehaviour seems to have been fixed now. On your other remarks on SVG: obviously, the current code is a klu(d)ge. I can't really comment on the best way to approach it, as I have no experience with real SVG programming, and very little with graphics programming in general. I'm leaving that to Adam and you (and Brett, if he feels up to it). Erik. |
From: Stefan F. <ste...@we...> - 2011-11-11 09:48:15
|
Reverse zooming direction was wrong due to the Dimension variable assignment instead of cloning. So two variables shared the same instance of a dimension object. That was a little tricky to find. Sometimes Eclipse has not finished rebuilding (compiling) the workspace before you run Rails, so that the version with the previous code starts. On Friday, November 11, 2011 10:11:12 am Erik Vos wrote: > > > Zooming now works fine (except the first time, strange enough, for > > > both 18EU and 18GA). > > > > I have not experienced the effect: What exactly is the bug (not zooming, > > background and tile have deviate in zoom) and is it reproducible at any > > start- > > > up or was it really only the first time you have started a game of 18GA > > and > > > 18EU? > > Before your changes it went wrong consistently and (I think) in a > reproducible way. > I don't understand why it still went wrong the first time after I pulled > your changes; it was as if Rails was still running without these changes. > > Anyway, what happened in the past was, that when I reversed the zooming > direction (from in to out or vice versa), the map did not change scale once > (or maybe twice). > Something like: > 1. Zoom in: all OK. > 2. Zoom in: still OK. > 3. Zoom out: tiles zoom out, map unchanged. > 4 (or 5). Zoom out: both zoom out, but remain out of sync. > > That misbehaviour seems to have been fixed now. > > On your other remarks on SVG: obviously, the current code is a klu(d)ge. I > can't really comment on the best way to approach it, as I have no > experience with real SVG programming, and very little with graphics > programming in general. I'm leaving that to Adam and you (and Brett, if he > feels up to it). > > Erik. > > > --------------------------------------------------------------------------- > --- RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |