From: Erik V. <eri...@hc...> - 2005-10-14 14:03:47
|
John, I'll try to look into this in more detail later. For now I would like to add, that I have been adding some additional preprinted tiles (for 1870 and 18AL) to the Marco's TileDesigner database (and many more will follow). Such tiles have negative numbers, and I have been trying to extend Marco's numbers sensibly. Perhaps we should start to standardize these numbers too? Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > John A. Tamplin > Sent: 11 October 2005 17:14 > To: rai...@li... > Subject: [Rails-devel] proposed structure for tile information > > Hello -- I have developed my own software for generating > print-ready tiles > from the TileDesigner source and database, and I have been > encouraged to > contribute that code to rails. Here is an outline of my > proposal, and if > the developers agree that this is of interest I will port my > current perl > code to Java and submit it. Note that at present I am not > committing to > integrate it with the rest of the project or even implement the GUI > interface, but at least it will get a common code base in > place and be > easy to extend to other renderers. Everything is vector > based so it is > scalable to any size or resolution. This message will contain the > definition of what goes into a tile, and later messages will > include the > object factoring for the code to manipulate and draw tiles. > > Currently, my tile data is kept in an Informix database and > is derived > from the original TileDesigner database as well as PS18XX > data. The tile > data has been modified to get print-ready output and to allow layout > tweaks at database import time rather than strictly when it > is rendered, > so manual changes can be made (especially needed for very > crowded tiles) > while simple tiles require little intervention. > > I propose to create an XML DTD for tile information that > represents all > information required for a tile, including everything > required to draw the > tile as well as any data necessary for gameplay. This is > intended to be > an interchange format rather than a storage format, although > it could be > used that way until a proper database is created. I know > there is an XML > format that is currently in place that does part of this, but > it needs to > include much more. > > Here is the current database schema for the tile database. Note that > there is some derived data in here, such as connectivity > information -- > the derived data is treated as a cache and would not be > present in the > exchange format, rather it would be generated on import. All > positions > are defined in polar coordinates -- (ang,dist) is the angle > and distance > from the center of the tile, with distance being scaled by > the radius of > the tile. So, (0,1) is the right-most point on a flat-bottom tile. > > tiles > ===== > tile_id serial unique identifier > tile_code char(16) code of tile, not necessarily unique > tile_shape char(4) hex etc > printed_number char(4) number actually printed on tile > color varchar(20,6) > label char(20) TileDesigner calls it category > label_ang smallfloat Coordinates of label > label_dist smallfloat > label_rotate smallfloat rotation of label relative to tile > label_font char(1) choice of which font to draw > (limited set) > label_justify char(2) justification of label > long_name char(32) full descriptive name of tile > origin varchar(32,0) original game using tile > edge_conn integer bitmap of inter-edge connections > d0-d4=AB-AF, d5-d9=BC-BA, ... > relatively easy to rotate with tile > junc_edge_conn integer bitmap of connections > from junctions to edges > d30-d31: two-bit type field > 00: normal; d0-d5=J0/A - J0/F, > d6=J1/A... > 01: 6-way; always connected to nearest > edge, d0-d4=J0/J1 - J0/J5, ... > 1x: reserved > interjunc_conn integer bitmap of connections > between junctions > d0-d4=J0/J1 - J0/J5, ... > > tile_junctions > ============== > tile_id integer foreign key into tiles > junction_num smallint tile_id,junction_num is primary key > junction_type char(4) type of junction, including > number of tokens > junction_ang smallfloat polar coordinates of junction > junction_dist smallfloat > junction_rotate smallfloat rotation of junction > relative to tile > null for whistlestops means draw it > with a dot rather than a bar > junction_revenue char(4) revenue (can mean other things for some > junction types such as > refueling junctions) > revenue_ang smallfloat polar coordinates of revenue label > revenue_dist smallfloat null means don't draw it > > tile_jun_annot (typically home tokens or reserved slots) > ============== > tile_id integer tile_id,junction_num > foreign key to > tile_junctions > token_slot smallint index from 1 into token slots > in junction > annotation_id integer foreign key into annotations > > tile_connections > ================ > tile_id integer foreign key into tiles > pos1_ang smallfloat polar coordinates of 1st end > pos1_dist smallfloat > pos2_ang smallfloat polar coordinates of 2nd end > pos2_dist smallfloat rules for canonical choice of > 1st/2nd ends > conn_type char(8) connection type (includes > gauge, ferries,..) > conn_level smallint drawing order for overlapped connections > basic rule - if two connections meet at > some point, their levels must > be within 1. > If they cross, their levels must be at > least 2 apart. > conn_radius smallfloat radius to draw connection. > negative means > it curves away from the center, positive > curves toward the center of the tile. A > typical 7 tile would be -.5, while #8 > would be -1.5. A 0 radius results in a > straight line. > > tile_annotations > ================ > tile_id integer foreign key into tiles > tile_annot_num smallint tile_id,tile_annot_num > is primary key > annotation_id integer foreign key into annotations > annot_ang smallfloat polar coordinations of annotation > annot_dist smallfloat > annot_scale smallfloat scale to draw annotation > annot_rotate smallfloat orientation of annotation > base_level boolean true if drawn as part of tile background > > annotations > =========== > annotation_id serial unique key > annot_desc char(40) text description of annotation > annot_text varchar(255) Postscript code to draw annotation > > tile_upgrades > ============= > base_tile integer foreign key into tiles > upgrade_tile integer foreign key into tiles > base_tile,upgrade_tile is primary key > > game_tiles > ========== > game_id integer foreign key into games > tile_id integer foreign key into tiles > orientation smallint rotation relative to canonical > orientation > quantity smallint number of tiles present, 0 indicates it > is a tile on the map, a negative number > indicates the given number are supplied > but are treated as infinite. > tile_number char(4) number printed on tile in this game > game_upgrades boolean use game-specific upgrades > rather than std > spec_upgrades boolean does game require special upgrade info > > The annotations table would likely need to be modified to > include other > ways of drawing the annotation, as well as gameplay > interactions (ie, a > river annotation needs to somehow include the fact that it > costs money to > build on that hex). > > So, a sample subset of an XML file for a couple of tiles: > > <tile id=27 code="7" origin="1829" color="yellow"> > <conn pos1="(330,.866025388)" pos2="(270,.866025388)"/> > </tile> > <tile id=32 code="14" origin="1829N" color="green"> > <junction type="2" revenue="30"/> > <conn pos1="(270,.866025388)" pos2="(0,0)"/> > <conn pos1="(90,.866025388)" pos2="(0,0)"/> > <conn pos1="(30,.866025388)" pos2="(0,0)"/> > <conn pos1="(330,.866025388)" pos2="(0,0)"/> > </tile> > <tile id=312 orientation="ew" code="1830-PRR" printed="" > origin="1830" > color="fixed" label="Philadephia" label_pos="(90,.3)" > label_justify="c" label_font="A"> > <junction type="1" revenue="10"> > <annotation code="PRR_token"> > </junction> > <conn pos1="(0,.866025388)" pos2="(0,0)"/> > <conn pos1="(180,.866025388)" pos2="(0,0)"/> > <conn pos1="(0,.866025388)" pos2="(330,.5)" radius=-.5/> > <conn pos1="(330,.5)" pos2="(270,.5)" radius=.5/> > <conn pos1="(180,.866025388)" pos2="(210,.5)" radius=-.5/> > <conn pos1="(210,.5)" pos2=("270,.5)" radius=.5/> > </tile> > > Note that many of the parameters are defaulted when the > import code can > figure them out easily. We might also make aliases for the edges for > position codes to avoid the normal value of sqrt(3), such as > sideA etc. > > Also note that the tile database includes tiles from all games, and > additional tables define which tiles are present in which games, and > game-specific modifications (such as orientation changes, > text labels, or > different upgrade paths). If no game-specific upgrades are > provided, the > subset of upgrade possibilities that are present in the game > are used. > Additional work needs to be done to have location-specific > upgrades in > particular games, such as those who take normal tiles in > early stages of > the game but have special brown or gray upgrades. > > The map object maintains a connectivity graph between junctions, and > incrementally updates it when tiles are laid or upgraded. It > provides an > interface to the route calculation code to find the reachable > subgraph of > all junctions reachable from a given companies tokens (taking > into account > blocking by tokens and special game rules like 1860 allowing > one blocked > junction to be run through). This would also be used by the user > interface code for playing tiles and tokens (with some > additional work for > tile placement since you have to look at tiles you can lay from the > frontiers of the reachability graph). The route calculation > code would be > responsible for figuring out which of those are reachable by > a particular > train according to the game's rules and computing the optimal route. > > Next I will send the object breakdown for tile rendering. > > -- > John A. Tamplin ja...@ja... > 770/436-5387 HOME 4116 Manson Ave > Smyrna, GA 30082-3723 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Erik V. <eri...@hc...> - 2005-10-15 16:12:49
|
Some comments inserted below. > Hello -- I have developed my own software for generating > print-ready tiles > from the TileDesigner source and database, and I have been > encouraged to > contribute that code to rails. Here is an outline of my > proposal, and if > the developers agree that this is of interest I will port my > current perl > code to Java and submit it. Note that at present I am not > committing to > integrate it with the rest of the project or even implement the GUI > interface, but at least it will get a common code base in > place and be > easy to extend to other renderers. Everything is vector > based so it is > scalable to any size or resolution. This message will contain the > definition of what goes into a tile, and later messages will > include the > object factoring for the code to manipulate and draw tiles. > > Currently, my tile data is kept in an Informix database and > is derived > from the original TileDesigner database as well as PS18XX > data. The tile > data has been modified to get print-ready output and to allow layout > tweaks at database import time rather than strictly when it > is rendered, > so manual changes can be made (especially needed for very > crowded tiles) > while simple tiles require little intervention. > > I propose to create an XML DTD for tile information that > represents all > information required for a tile, including everything > required to draw the > tile as well as any data necessary for gameplay. This is > intended to be > an interchange format rather than a storage format, although > it could be > used that way until a proper database is created. I know > there is an XML > format that is currently in place that does part of this, but > it needs to > include much more. In fact we have separated the visual (View) and the gameplay-related (Model) properties of tiles. The latter are included in Tiles.xml (one central file that contains all tiles, and a subset per game). Tiles.xml IMO contains pretty much all we need for route calculation purposes (if we manage to relate stations to company tokens). These XML files are currently derived from TileDesigner using classes util.ConvertTilesXML and util.MakeGameTileSets. Having a big XML file (being a dump of your database) as an alternative source (replacing TIleDesigner.xml) looks like a very good idea, as TileDesigner currently does not fulfill all possible needs. The main remaining problem with our Model/View separation could be how to deal with company tokens and Home base inidications for tiles with more than one city. IMO the biggest problem is posed by the 1835 brown Hamburg tile (#221). Does your database take care of the peculiarities of this tile, both in drawing and in route/revenue calculation? On tile drawing: I'm afraid that the displayed tiles will be too small to show labels and perhaps even revenues. I have been trying to get toolTips (mouseover popups) working, but this does not yet work in the current UI design. The tool tips should include all relevant hex and tile info, which should be derived from the corresponding model objects (MapHex and Tile). > Here is the current database schema for the tile database. Note that > there is some derived data in here, such as connectivity > information -- > the derived data is treated as a cache and would not be > present in the > exchange format, rather it would be generated on import. All > positions > are defined in polar coordinates -- (ang,dist) is the angle > and distance > from the center of the tile, with distance being scaled by > the radius of > the tile. So, (0,1) is the right-most point on a flat-bottom tile. <snip> Some elements look rather convoluted to me (such as the bitmaps), but I understand that we will not directly confronted with these details. > The annotations table would likely need to be modified to > include other > ways of drawing the annotation, as well as gameplay > interactions (ie, a > river annotation needs to somehow include the fact that it > costs money to > build on that hex). I would stress that we should keep Hex and Tile info strictly separate. Hex info remains valid regardless the current (including preprinted tile): hex name, city name, impassible hex sides. I would also put the cost to lay the first tile there, to avoid having different Tile definitions for the same preprinted tile. > So, a sample subset of an XML file for a couple of tiles: > > <tile id=27 code="7" origin="1829" color="yellow"> > <conn pos1="(330,.866025388)" pos2="(270,.866025388)"/> > </tile> > <tile id=32 code="14" origin="1829N" color="green"> > <junction type="2" revenue="30"/> > <conn pos1="(270,.866025388)" pos2="(0,0)"/> > <conn pos1="(90,.866025388)" pos2="(0,0)"/> > <conn pos1="(30,.866025388)" pos2="(0,0)"/> > <conn pos1="(330,.866025388)" pos2="(0,0)"/> > </tile> > <tile id=312 orientation="ew" code="1830-PRR" printed="" > origin="1830" > color="fixed" label="Philadephia" label_pos="(90,.3)" > label_justify="c" label_font="A"> > <junction type="1" revenue="10"> > <annotation code="PRR_token"> > </junction> > <conn pos1="(0,.866025388)" pos2="(0,0)"/> > <conn pos1="(180,.866025388)" pos2="(0,0)"/> > <conn pos1="(0,.866025388)" pos2="(330,.5)" radius=-.5/> > <conn pos1="(330,.5)" pos2="(270,.5)" radius=.5/> > <conn pos1="(180,.866025388)" pos2="(210,.5)" radius=-.5/> > <conn pos1="(210,.5)" pos2=("270,.5)" radius=.5/> > </tile> > > Note that many of the parameters are defaulted when the > import code can > figure them out easily. We might also make aliases for the edges for > position codes to avoid the normal value of sqrt(3), such as > sideA etc. We have numbered sides 0...5 (0 is S or SW). > Also note that the tile database includes tiles from all games, and > additional tables define which tiles are present in which games, and > game-specific modifications (such as orientation changes, > text labels, or > different upgrade paths). If no game-specific upgrades are > provided, the > subset of upgrade possibilities that are present in the game > are used. > Additional work needs to be done to have location-specific > upgrades in > particular games, such as those who take normal tiles in > early stages of > the game but have special brown or gray upgrades. Upgrades are specified in TileSet.xml. The upgrade rules can include hex or label specifications (see the upgrades for #170 in 1870). So in total we currently have three map-related XML files and one set of images per game. The images and Tiles.xml are auto-generated, either from TileDesigner or from your database or root XML file, whatever source fits best. Map.xml and TileSet.xml will, IMO, always be hand-made. As you correctly indicated, these XML files are incomplete, and some of these are not yet parsed at all. Your input on improving this design is very welcome. However, I believe that the separation of concerns that these different XML files represent should remain intact. > The map object maintains a connectivity graph between junctions, and > incrementally updates it when tiles are laid or upgraded. It > provides an > interface to the route calculation code to find the reachable > subgraph of > all junctions reachable from a given companies tokens (taking > into account > blocking by tokens and special game rules like 1860 allowing > one blocked > junction to be run through). This would also be used by the user > interface code for playing tiles and tokens (with some > additional work for > tile placement since you have to look at tiles you can lay from the > frontiers of the reachability graph). The route calculation > code would be > responsible for figuring out which of those are reachable by > a particular > train according to the game's rules and computing the optimal route. So far we have not worked on these aspects at all. So this area is wide open to you! Erik. |
From: John A. T. <ja...@ja...> - 2005-11-20 15:22:32
|
Sorry, I was cleaning up old email and realized I hadn't responded to this one. Erik Vos wrote: >In fact we have separated the visual (View) and the gameplay-related >(Model) properties of tiles. The latter are included in Tiles.xml >(one central file that contains all tiles, and a subset per game). >Tiles.xml IMO contains pretty much all we need for route calculation >purposes (if we manage to relate stations to company tokens). >These XML files are currently derived from TileDesigner using >classes util.ConvertTilesXML and util.MakeGameTileSets. > >Having a big XML file (being a dump of your database) >as an alternative source (replacing TIleDesigner.xml) >looks like a very good idea, as TileDesigner >currently does not fulfill all possible needs. > >The main remaining problem with our Model/View separation >could be how to deal with company tokens and Home base >inidications for tiles with more than one city. > >IMO the biggest problem is posed by the 1835 brown Hamburg tile (#221). >Does your database take care of the peculiarities of this tile, >both in drawing and in route/revenue calculation? > > Note that my code currently only cares about drawing the tiles and has not been used for route/revenue calculations. That said, I don't think there is anything that will prevent it from being useful for that with the appropriate API additions. The Hamburg tile is handled, although it is somewhat cheating by calling the junction type BridgedTripleCity, which special cases how the junction is drawn. >On tile drawing: I'm afraid that the displayed tiles will be too small >to show labels and perhaps even revenues. I have been trying >to get toolTips (mouseover popups) working, but this does not >yet work in the current UI design. > > Everything scalable, so at some scale there will be sufficient room to draw it all readably. One thing that could be easily added is code to omit drawing some things at small scales, so the user can adjust the scale to get the level of detail they want automatically. >The tool tips should include all relevant hex and tile info, >which should be derived from the corresponding model objects >(MapHex and Tile). > > I think the tool tips are useful, but in general you want to have the critical information directly on the tile. Granted, at some scales this isn't feasible (say if you are viewing 18C2C's map all on the screen at once), but in general I think it needs to be there. Think about AH's 1830 -- even though the resolution was atrocious, they actually made it useable with only 16 colors. With more colors available, we can properly antialias the text/graphics and so make it look better at smaller sizes, plus these days we can probably assume a larger minimum screen size. >Some elements look rather convoluted to me (such as the bitmaps), >but I understand that we will not directly confronted with these details. > > What bitmaps are you referring to? Everything is scalable graphics. >I would stress that we should keep Hex and Tile info strictly separate. >Hex info remains valid regardless the current (including >preprinted tile): hex name, city name, impassible hex sides. >I would also put the cost to lay the first tile there, >to avoid having different Tile definitions for the same >preprinted tile. > > It depends on how you look at it -- to me it seems like the map is just a bunch of pre-printed tiles, all of which can be upgraded subject to normal upgrade requirements. Thus a plain grass hex with one city is eligible to upgrade to tiles 5, 6, and 57 depending on the game, while the fixed Philidelphia tile in 1830 has no legal upgrades. Particular instances of tiles can have unique annotations so that solves the problem of duplicating tile definitions. Since the current code is not involved in gameplay-related things, this needs to be extended a bit to include information on what the annotation means, whether it is a building cost (and for example what privates might eliminate or change that building cost), a reserved token slot (and when that reservation ceases, as in the Erie tile in 1830 or the teleport token slots in 1846), etc. Why should the code for placing a tile on the bare map be treated any differently than upgrading an existing tile? If you treat the map as a bunch of tiles from the beginning, that exception is resolved for free. >>We might also make aliases for the edges for >>position codes to avoid the normal value of sqrt(3), such as >>sideA etc. >> >> > >We have numbered sides 0...5 (0 is S or SW). > > Having different coordinate systems for the sides versus everything else seems a bad plan -- if you just mean the name of the shortcuts being side0 etc that is obviously no problem. >So in total we currently have three map-related XML files >and one set of images per game. >The images and Tiles.xml are auto-generated, either from >TileDesigner or from your database or root XML file, >whatever source fits best. > >Map.xml and TileSet.xml will, IMO, always be hand-made. > > It depends on what you mean by "hand made" -- in a sense, everything is hand-made: the tiles data (to whatever level of layout detail) is ultimately entered manually, the descriptions of the rules are manually entered, etc. If that information is stored in a database somewhere, I don't see why the XML equivalents cannot be generated automatically from the database. I have even taken tile descriptions from PS18XX by limited parsing of the Postscript code, and I am pretty sure doing the same for the maps would work as well. >As you correctly indicated, these XML files are incomplete, >and some of these are not yet parsed at all. >Your input on improving this design is very welcome. > >However, I believe that the separation of concerns that these >different XML files represent should remain intact. > > My database code includes tile upgrades, both generic and game-specific. There is therefore one API for fetching this tile information. If you don't want to encapsulate this interface in a TileDatabase (or whatever class) so the underlying backend can be changed, we can certainly do that although it seems to restrict options in the future. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
From: Erik V. <eri...@hc...> - 2005-11-20 18:34:31
|
A few responses: > The Hamburg tile is handled, although it is somewhat cheating > by calling > the junction type BridgedTripleCity, which special cases how the > junction is drawn. I realise that a case like this we will have to special-case (if that is a verb) by creating a class indeed. > >Some elements look rather convoluted to me (such as the bitmaps), > >but I understand that we will not directly confronted with > these details. > > > > > What bitmaps are you referring to? Everything is scalable graphics. Like this (from your original post to which I responded): junc_edge_conn integer bitmap of connections from junctions to edges d30-d31: two-bit type field 00: normal; d0-d5=J0/A - J0/F, d6=J1/A... 01: 6-way; always connected to nearest edge, d0-d4=J0/J1 - J0/J5, ... 1x: reserved interjunc_conn integer bitmap of connections between junctions d0-d4=J0/J1 - J0/J5, ... - well, you asked for comments, IIRC.... > >I would stress that we should keep Hex and Tile info > strictly separate. > >Hex info remains valid regardless the current (including > >preprinted tile): hex name, city name, impassible hex sides. > >I would also put the cost to lay the first tile there, > >to avoid having different Tile definitions for the same > >preprinted tile. > > > > > It depends on how you look at it -- to me it seems like the > map is just > a bunch of pre-printed tiles, all of which can be upgraded subject to > normal upgrade requirements. Thus a plain grass hex with one city is > eligible to upgrade to tiles 5, 6, and 57 depending on the > game, Well, in fact we have taken it even one step further than that, by declaring all preprinted hexes to be just ordinary tiles. So, in our setup, the hex is a location (which may have properties, such as being a destination, or having impassable sides), and is initially covered by a preprinted tile (which may have a city on it, or just be open prairie). This approach makes it even easier, and also allowed us to use Marco Rocci's tile designer (in which such preprinted tiles have negative tile numbers) to display these tiles. Once we manage to create whole maps as graphic objects, these will (I suppose) also show the preprinted tiles, so by then we can suppress displaying of these 'negative' tiles. But we could keep using them as holders of the upgrade rules. > while > the fixed Philidelphia tile in 1830 has no legal upgrades. According to most people H12 is Altoona, and opinions differ as to whether H16 or H18 is Philadelphia (I'm in the latter camp). But that aside. > Particular > instances of tiles can have unique annotations so that solves the > problem of duplicating tile definitions. Since the current > code is not > involved in gameplay-related things, this needs to be > extended a bit to > include information on what the annotation means, whether it is a > building cost (and for example what privates might eliminate > or change > that building cost), a reserved token slot (and when that reservation > ceases, as in the Erie tile in 1830 or the teleport token slots in > 1846), etc. > > Why should the code for placing a tile on the bare map be treated any > differently than upgrading an existing tile? If you treat > the map as a > bunch of tiles from the beginning, that exception is resolved > for free. Indeed, as we did. > >>We might also make aliases for the edges for > >>position codes to avoid the normal value of sqrt(3), such as > >>sideA etc. > >> > >> > > > >We have numbered sides 0...5 (0 is S or SW). > > > > > Having different coordinate systems for the sides versus > everything else > seems a bad plan -- if you just mean the name of the shortcuts being > side0 etc that is obviously no problem. For easy orienting and rotating tiles the tile orientation can best be expressed as a number internally. But for external use (XML's, logs etc.) I favour wind directions too. > >So in total we currently have three map-related XML files > >and one set of images per game. > >The images and Tiles.xml are auto-generated, either from > >TileDesigner or from your database or root XML file, > >whatever source fits best. > > > >Map.xml and TileSet.xml will, IMO, always be hand-made. > > > > > It depends on what you mean by "hand made" -- in a sense, > everything is > hand-made: the tiles data (to whatever level of layout detail) is > ultimately entered manually, the descriptions of the rules > are manually > entered, etc. If that information is stored in a database > somewhere, I > don't see why the XML equivalents cannot be generated > automatically from > the database. I have even taken tile descriptions from PS18XX by > limited parsing of the Postscript code, and I am pretty sure > doing the > same for the maps would work as well. Again, that is about like what we did: - class util.ConvertTilesXML takes an XML dump of Marco's dictionary and creates the generic file tiles/Tiles.xml. - class util.MakeGameTileSets uses that file, and the game's TileSet.xml, to create a subset as the game's Tiles.xml. Erik. |
From: John A. T. <ja...@ja...> - 2005-11-20 22:03:52
|
On Sun, 20 Nov 2005, Erik Vos wrote: >> What bitmaps are you referring to? Everything is scalable graphics. > > Like this (from your original post to which I responded): > > junc_edge_conn integer bitmap of connections from junctions to > edges > d30-d31: two-bit type field > 00: normal; d0-d5=J0/A - J0/F, d6=J1/A... > 01: 6-way; always connected to nearest > edge, d0-d4=J0/J1 - J0/J5, ... > 1x: reserved > interjunc_conn integer bitmap of connections between junctions > d0-d4=J0/J1 - J0/J5, ... It is pretty easy to do quick connectivity lookups and to rotate the connectivity graphs. It is just a cache of the detailed junction/connection data, but much faster than having to check everything. If you don't need it for rails, that can certainly be left out. > - well, you asked for comments, IIRC.... Certainly, I just thought you were referring to bitmap images. > Once we manage to create whole maps as graphic objects, these > will (I suppose) also show the preprinted tiles, so by then > we can suppress displaying of these 'negative' tiles. > But we could keep using them as holders of the upgrade rules. Why would you want to have an entire map as a single graphic object, rather than consisting of the tiles which know how to draw themselves? > For easy orienting and rotating tiles the tile orientation can > best be expressed as a number internally. > But for external use (XML's, logs etc.) I favour wind directions too. Since everything is in polar coordinates, it is trivial to rotate everything by just adding a angular offset. I was just suggesting a shorthand for manually created XML tiles. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
From: Erik V. <eri...@hc...> - 2005-11-20 22:24:27
|
> > Once we manage to create whole maps as graphic objects, these > > will (I suppose) also show the preprinted tiles, so by then > > we can suppress displaying of these 'negative' tiles. > > But we could keep using them as holders of the upgrade rules. > > Why would you want to have an entire map as a single graphic object, > rather than consisting of the tiles which know how to draw themselves? To make it look a lot better, with coastlines, rivers and all.... But that is entirely optional. > > For easy orienting and rotating tiles the tile orientation can > > best be expressed as a number internally. > > But for external use (XML's, logs etc.) I favour wind > directions too. > > Since everything is in polar coordinates, it is trivial to rotate > everything by just adding a angular offset. Sure, but that is GUI matter. This is what we now do in the GUI (the "view") as well. But in the "model", which drives the GUI, we also need to register the orientation in some way, with respect to some standard orientation. We have 6 possible orientations, so what is more natural that to number these from 0...5? Erik. |
From: John A. T. <ja...@ja...> - 2005-10-14 14:49:02
|
On Fri, 14 Oct 2005, Erik Vos wrote: > I'll try to look into this in more detail later. > > For now I would like to add, that I have been adding some > additional preprinted tiles (for 1870 and 18AL) to the > Marco's TileDesigner database (and many more will follow). > Such tiles have negative numbers, and I have been trying > to extend Marco's numbers sensibly. > Perhaps we should start to standardize these numbers too? I have every tile for every game on Chris/John Galt's tile encyclopedia as well as all of the tiles from Steve Thomas's PS18XX files, plus some other tiles that are not currently in either. The first problem is that what is called "tile code" in TileDesigner is not unique (there are duplicates across games), and that it is difficult to extend it usefully when merging in all the other data. I decided to have a unique serial key (32-bit integer) which is sequentially assigned to each tile, in addition to the code. I also made the code alphanumeric, so it is easier to say "122/EU" to mean the 18EU version of tile 122. In addition, the number printed on the tile is kept separately from the code (but defaulted from it) so the number can be printed differently. In addition, each game can specify the orientation of a given tile separately (but I do not currently handle some of the issues where the same tile in one game may have multiple orientations or different printings have different orientations) as well as the number to be printed, since some identical tiles are printed with different numbers in different games. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |