Menu
▾
▴
rails-devel
|
From: Martin B. <dr....@t-...> - 2014-04-21 11:02:57
Attachments:
signature.asc
|
Hi, as some of you know the Rails project is using Marcos Tile Designer to create new Tiles and more important a library. This programm is not supported anymore nor has been there any development for nearly 10 years. Anynone of you got some plans/recommendations on how to proceed ? One could use Inkscape, but then we would have to find a new conversion program to be able to not distort the maps and tiles between the different productions. And of Course theres no library function available with inkscape ? Regards, Martin |
|
From: brett l. <bre...@gm...> - 2014-04-22 13:55:17
|
That's a tricky issue. It would be really nice if TileDesigner were open sourced, so that we could update it. It might be possible to develop some SVG templates for each of the components of a tile. That would allow us to assemble new tiles in Inkscape using a standardized set of primitives on a standardized image base. ---Brett. ---Brett. On Mon, Apr 21, 2014 at 7:02 AM, Martin Brumm <dr....@t-...>wrote: > Hi, > > as some of you know the Rails project is using Marcos Tile Designer to > create new Tiles and more important a library. > > This programm is not supported anymore nor has been there any > development for nearly 10 years. > > Anynone of you got some plans/recommendations on how to proceed ? > One could use Inkscape, but then we would have to find a new conversion > program to be able to not distort the maps and tiles between the > different productions. > > And of Course theres no library function available with inkscape ? > > Regards, > Martin > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: John A. T. <ja...@ja...> - 2014-04-22 14:53:25
|
On Tue, Apr 22, 2014 at 9:54 AM, brett lentz <bre...@gm...> wrote: > That's a tricky issue. It would be really nice if TileDesigner were open > sourced, so that we could update it. > Hmm, it's not? At least Marco sent it to me when I asked. However, it is written in Delphi. For my use, I reimplemented it in perl, and that is still what I use to generate the production tiles. Of course, the goals for printing are different than for screen (and I made a number of changes to be able to generate print-ready output and more complex tiles), but I generate PostScript from the tile definitions and SVG wouldn't be hard (basically at the rendering stage you have methods for drawing an arc, circle, etc). Several years ago I started porting it to Java for use in Rails, but I didn't have time to finish it. If someone wants to take that and/or the perl code and modify I would be happy to send what I have (assuming I can find the Java port :). > It might be possible to develop some SVG templates for each of the > components of a tile. That would allow us to assemble new tiles in Inkscape > using a standardized set of primitives on a standardized image base. > I don't think you want to get in the business of hand-drawing tiles. Aside from consistency issues, you will also have to redraw every single tile if you decide to change some aspect - I think generating them from some tile description is the way to go. -- John A. Tamplin |
|
From: brett l. <bre...@gm...> - 2014-04-23 00:09:36
|
On Tue, Apr 22, 2014 at 10:52 AM, John A. Tamplin <ja...@ja...> wrote: > On Tue, Apr 22, 2014 at 9:54 AM, brett lentz <bre...@gm...>wrote: > >> That's a tricky issue. It would be really nice if TileDesigner were open >> sourced, so that we could update it. >> > > Hmm, it's not? At least Marco sent it to me when I asked. > > Unless the code has an explicit OSS license assigned that's compatible with the license used by Rails, we can't really use Marco's code even if you have it. > However, it is written in Delphi. For my use, I reimplemented it in perl, > and that is still what I use to generate the production tiles. Of course, > the goals for printing are different than for screen (and I made a number > of changes to be able to generate print-ready output and more complex > tiles), but I generate PostScript from the tile definitions and SVG > wouldn't be hard (basically at the rendering stage you have methods for > drawing an arc, circle, etc). > Yep. Jumping from Postscript to SVG is pretty easy. IIRC, Perl has GSAPI, which hooks into Ghostscript and can do that heavy-lifting. > > Several years ago I started porting it to Java for use in Rails, but I > didn't have time to finish it. If someone wants to take that and/or the > perl code and modify I would be happy to send what I have (assuming I can > find the Java port :). > If you're willing to contribute your Perl and/or Java code under the GPL v2+ license that Rails uses, we can probably make use of it. Posting the code to the list is a reasonable way to start. > > >> It might be possible to develop some SVG templates for each of the >> components of a tile. That would allow us to assemble new tiles in Inkscape >> using a standardized set of primitives on a standardized image base. >> > > I don't think you want to get in the business of hand-drawing tiles. > Aside from consistency issues, you will also have to redraw every single > tile if you decide to change some aspect - I think generating them from > some tile description is the way to go. > > I agree. It's not ideal, but implementing our own tile drawing engine is also not very appealing. ;-) The nice thing about using SVG is that certain classes of problems are at least a non-issue, when compared to the bitmap-based tile sets. > -- > John A. Tamplin > > ---Brett. |
|
From: Stefan F. <ste...@we...> - 2014-04-26 09:50:02
|
My own thoughts on this topic: * The important contribution of Marcos Tile Designer is not so much the UI tool itself, but the Tile definitions in file "TileDictionary.18t". * The process from "TileDictionary.18t" to the game specifics "Tiles.xml" is detailed here: https://sourceforge.net/apps/mediawiki/rail/index.php?title=Tile_creation * Access to Marcos and Johns code would be really helpful to avoid re-inventing the wheel again. I will send Marco an e-mail if he allows us to take a look at it. John, if you would share the code, it would be great. Maybe you could send it to one of the admins (Brett or myself)? * My proposal is to define tiles manually using the syntax we already have in Tiles.xml (instead of the one used in .18t, but keep in mind that this is only a different syntax to Marco, the content is identical). Take the example of tile 57 (straight city): <Tile colour="yellow" id="57" name="57"> <Station id="city1" position="0" slots="1" type="City" value="20"/> <Track from="city1" gauge="normal" to="side3"/> <Track from="city1" gauge="normal" to="side0"/> </Tile> This contains all information needed to generate a SVG from it. As John said this only requires rules for tracks/cities/token slots. By adopting different styles it would even be possible to support different layouts based on the same definitions. * For Rails 2.0 I have already simplified the handling of svg to some extent. My intention is to replace the current svg library (batik) by one which has a smaller footprint, is simpler to use and compatible with Android and/or JavaFX. Most likely this will happen at 2.1 / 2.2. However this is no precondition for a own svg-engine. * Some simplification of the map display code was done as well (mainly by factoring out code into MapOrientation class). However I still intend to refactor that even more. Again this is no precondition, but it a own SVG engine would really be helpful to make map painting easier. Currently the SVG tiles and the map code exist in two different worlds, loosely speaking ;-) * Hand-made graphics should be the exception and should be defined in plain svg. Most vector graphic programs (including inkscape) are able to save in "plain" svg, instead in their more bloated own svg based format. Question is if there is someone who would like to implement a tile to svg engine for Rails? It requires no detailed knowledge of any 18xx game, however some Java/svg/xml experience. I can offer my help and as mentioned some time ago, I have a duplicate version of http://www.amazon.com/SVG-Unleashed-Andrew-H-Watt/dp/0672324296 that I am willing to ship free-of-charge to a volunteer. The book is not perfect by any means, but I like it is a reference. However the available documentation on svg on the net covers every aspect needed for the task. If no one else is interested, it will be on my own list of to-dos after rails 2.0 is out. Stefan On 04/23/2014 02:09 AM, brett lentz wrote: > > On Tue, Apr 22, 2014 at 10:52 AM, John A. Tamplin <ja...@ja... > <mailto:ja...@ja...>> wrote: > > On Tue, Apr 22, 2014 at 9:54 AM, brett lentz <bre...@gm... > <mailto:bre...@gm...>> wrote: > > That's a tricky issue. It would be really nice if TileDesigner > were open sourced, so that we could update it. > > > Hmm, it's not? At least Marco sent it to me when I asked. > > > Unless the code has an explicit OSS license assigned that's compatible > with the license used by Rails, we can't really use Marco's code even if > you have it. > > However, it is written in Delphi. For my use, I reimplemented it in > perl, and that is still what I use to generate the production tiles. > Of course, the goals for printing are different than for screen > (and I made a number of changes to be able to generate print-ready > output and more complex tiles), but I generate PostScript from the > tile definitions and SVG wouldn't be hard (basically at the > rendering stage you have methods for drawing an arc, circle, etc). > > > Yep. Jumping from Postscript to SVG is pretty easy. IIRC, Perl has > GSAPI, which hooks into Ghostscript and can do that heavy-lifting. > > > Several years ago I started porting it to Java for use in Rails, but > I didn't have time to finish it. If someone wants to take that > and/or the perl code and modify I would be happy to send what I have > (assuming I can find the Java port :). > > > If you're willing to contribute your Perl and/or Java code under the GPL > v2+ license that Rails uses, we can probably make use of it. Posting the > code to the list is a reasonable way to start. > > It might be possible to develop some SVG templates for each of > the components of a tile. That would allow us to assemble new > tiles in Inkscape using a standardized set of primitives on a > standardized image base. > > > I don't think you want to get in the business of hand-drawing tiles. > Aside from consistency issues, you will also have to redraw every > single tile if you decide to change some aspect - I think generating > them from some tile description is the way to go. > > > I agree. It's not ideal, but implementing our own tile drawing engine is > also not very appealing. ;-) > > The nice thing about using SVG is that certain classes of problems are > at least a non-issue, when compared to the bitmap-based tile sets. > > -- > John A. Tamplin > > > ---Brett. > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2014-04-30 09:41:48
|
John: Thanks for your recommendations. Some quick comments below. Your comments are always helpful, so feel free to share your thoughts. Stefan > I wouldn't have kept the .18t file format with its painful conventions > for one. Yes that will be replaced by Tiles.xml, which is much nicer to write. > > For another, I would have separated tile layout from tile drawing, and > supported the tile definition either using the high-level approach of > "the city is here, and it is connected to these locations" and letting > the layout be generated, or allow you to specify the layout (exact > positions, rotations, etc) - as it, especially on crowded tiles, I had > to do special-case layout things and it still isn't great. I would have > also generalized the track layout to build bezier curves directly rather > than keeping all the special-case code for "if this position is > connected to this position, draw it this way". Most likely I will follow your recommendation to separate track configuration from tile drawing hints (where to position stations etc.). I even consider making another step: Allow parametrized tiles, tiles that use the same track layout, but differ in the station values and labels: Currently a new tile is defined any time the station value changes and/or a label is added to the tile. One could even consider the tile color to be a parameter of the tile and thus there is no need to duplicate the track layout definition only because the color changes. For sure they are different tiles that are required for a physical game, but not if they get generated automatically. One thing that we still want to support is a (visible to the user) tile-id that is identical to the 18xx tiles database and used for the boardgame. > > And: You are right, writing to Swing is an option. > However I expect that any suitable Java svg libraries with support for > Swing allow the creation of a svg file by writing to a Graphics2D > object. So if java as the implementation language switching from svg to > direct painting will be nearly transparent. > > > Let's just say I am skeptical of using an API designed for drawing on > the screen and getting good results generating SVG from it, but feel > free to go that route if you prefer. > > -- I agree with your sentiment. It seems odd to first create SVG via a Swing API dynamically and then convert the SVG back into Swing graphics. But this might be true only for the time being. Later on Rails graphics might be produced by another GUI library than Swing and/or the graphic shown is generated by a different SVG library, that uses a different API for creation. And given the current situtation I do not want to be tied to Swing. However all existing Java svg libraries create SVG files from Java via the Swing Graphics API. I wonder how this is solved by other languages. Is doubt that operating on the SVG via XML DOM is preferable. I would prefer an API similar to the javascript library http://raphaeljs.com/ . Given the fact that Java 6 ships JS support via the Rhino engine, and Java 8 comes with a brand-new JS engine (Nashorn), most likely raphaeljs is the way to go. |
|
From: John A. T. <ja...@ja...> - 2014-04-30 15:46:47
|
On Wed, Apr 30, 2014 at 5:41 AM, Stefan Frey <ste...@we...> wrote: > I even consider making another step: Allow parametrized tiles, tiles > that use the same track layout, but differ in the station values and > labels: Currently a new tile is defined any time the station value > changes and/or a label is added to the tile. > > One could even consider the tile color to be a parameter of the tile and > thus there is no need to duplicate the track layout definition only > because the color changes. > > For sure they are different tiles that are required for a physical game, > but not if they get generated automatically. > I'm not sure it is worth the trouble, but if I were going to do that I would do it by "subclassing" tiles and overriding parts I wanted to change. -- John A. Tamplin |
|
From: brett l. <bre...@gm...> - 2014-04-30 13:35:09
|
On Wed, Apr 30, 2014 at 5:41 AM, Stefan Frey <ste...@we...> wrote: > John: > Thanks for your recommendations. Some quick comments below. > Your comments are always helpful, so feel free to share your thoughts. > Stefan > > > I wouldn't have kept the .18t file format with its painful conventions > > for one. > > Yes that will be replaced by Tiles.xml, which is much nicer to write. > > > > > For another, I would have separated tile layout from tile drawing, and > > supported the tile definition either using the high-level approach of > > "the city is here, and it is connected to these locations" and letting > > the layout be generated, or allow you to specify the layout (exact > > positions, rotations, etc) - as it, especially on crowded tiles, I had > > to do special-case layout things and it still isn't great. I would have > > also generalized the track layout to build bezier curves directly rather > > than keeping all the special-case code for "if this position is > > connected to this position, draw it this way". > > Most likely I will follow your recommendation to separate track > configuration from tile drawing hints (where to position stations etc.). > > I even consider making another step: Allow parametrized tiles, tiles > that use the same track layout, but differ in the station values and > labels: Currently a new tile is defined any time the station value > changes and/or a label is added to the tile. > > One could even consider the tile color to be a parameter of the tile and > thus there is no need to duplicate the track layout definition only > because the color changes. > > For sure they are different tiles that are required for a physical game, > but not if they get generated automatically. > > One thing that we still want to support is a (visible to the user) > tile-id that is identical to the 18xx tiles database and used for the > boardgame. > > > > > And: You are right, writing to Swing is an option. > > However I expect that any suitable Java svg libraries with support > for > > Swing allow the creation of a svg file by writing to a Graphics2D > > object. So if java as the implementation language switching from svg > to > > direct painting will be nearly transparent. > > > > > > Let's just say I am skeptical of using an API designed for drawing on > > the screen and getting good results generating SVG from it, but feel > > free to go that route if you prefer. > > > > -- > > I agree with your sentiment. It seems odd to first create SVG via a > Swing API dynamically and then convert the SVG back into Swing graphics. > But this might be true only for the time being. Later on Rails graphics > might be produced by another GUI library than Swing and/or the graphic > shown is generated by a different SVG library, that uses a different API > for creation. And given the current situtation I do not want to be tied > to Swing. > > However all existing Java svg libraries create SVG files from Java via > the Swing Graphics API. I wonder how this is solved by other languages. > Is doubt that operating on the SVG via XML DOM is preferable. > I would prefer an API similar to the javascript library > http://raphaeljs.com/ . > > Given the fact that Java 6 ships JS support via the Rhino engine, and > Java 8 comes with a brand-new JS engine (Nashorn), most likely raphaeljs > is the way to go. > > The main reason I chose SVG, was because it meant that we weren't tied to just using Swing for our UI. Way back in the early days of the project, Erik did some very preliminary prototyping to demonstrate that a web-based UI was also possible and even desirable. I still believe that supporting the potential for more than the current Swing UI is nice-to-have. But, I think a flexible tile definition that can be used to render the tiles in a desire format also fits that requirement just as easily as using SVG for the tile graphics themselves. ---Brett. |
|
From: John A. T. <ja...@ja...> - 2014-04-30 15:13:12
|
On Wed, Apr 30, 2014 at 9:34 AM, brett lentz <bre...@gm...> wrote: > The main reason I chose SVG, was because it meant that we weren't tied to > just using Swing for our UI. Way back in the early days of the project, > Erik did some very preliminary prototyping to demonstrate that a web-based > UI was also possible and even desirable. > I'm not positive SVG is the way to go for a web-based app - personally, I would probably use sprited images downloaded from the server. Particularly if you are going to reuse the Java codebase and compile with GWT, as you get the compile-time spriting for free. I still believe that supporting the potential for more than the current > Swing UI is nice-to-have. But, I think a flexible tile definition that can > be used to render the tiles in a desire format also fits that requirement > just as easily as using SVG for the tile graphics themselves. > The rendering API that would have to be implemented is things like arcs, circles, transformed text, etc, so you should be able to draw it using Java2D or SVG or pretty much anything with basic drawing APIs. -- John A. Tamplin |
|
From: <com...@ip...> - 2014-04-30 15:20:29
|
I don't like the notion of downloading sprites every time you want to play a game. It restricts game functionality to online play only, and introduces new variables to the game-play process. Including the sprites as part of the download/install bundle would be fine, though. >I'm not positive SVG is the way to go for a web-based app - personally, I >would probably use sprited images downloaded from the server. Particularly >if you are going to reuse the Java codebase and compile with GWT, as you >get the compile-time spriting for free. |
|
From: John A. T. <ja...@ja...> - 2014-04-30 15:51:55
|
On Wed, Apr 30, 2014 at 11:20 AM, <com...@ip...> wrote: > I don't like the notion of downloading sprites every time you want to play > a game. It restricts game functionality to online play only, and introduces > new variables to the game-play process. Including the sprites as part of > the download/install bundle would be fine, though. That comment was in the context of a web app, in which case you are downloading the app itself and talking to a web server anyway (and that's the point, GWT bundles the sprites into the app download so there are no extra round-trips and it is permanently cacheable). -- John A. Tamplin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X