Menu
▾
▴
Re: [Rails-devel] Tile Database API & route calculation
|
From: John A. T. <ja...@ja...> - 2006-07-08 20:42:54
|
Erik Vos wrote:
>Looks good to me generally.
>See some comments below.
>
>
>
>>Ok, after looking at Iain's code, I propose the following:
>>
>>Extend the tile XML file to show additional exclusive track
>>use and add
>>necessary drawing data:
>>
>><Tile id="62" colour="green" category="NY">
>> # position/rotation can be defaulted
>> <Station id="1" type="City" slots="2" value="80"
>>position="90,.4" rotation="0" />
>> <Station id="2" type="City" slots="2" value="80"
>>position="270,.4" rotation="0" />
>> # gauge and level are defaulted, use shorter labels for
>>size and parsing speed
>> <Track from="1" to="A" />
>> <Track from="1" to="F" />
>> <Track from="2" to "E" />
>> <Track from="2" to "D" />
>></Tile>
>>
>>
>
>I presume that, in case a city has more than one slot,
>slot center locations will be calculated from
>the Station position and the tile orientation.
>Can't we better specify these explicitly?
>
>
The tile code draws the entire city structure as one, and only needs the
center point and orientation of the city structure. For hit detection,
I suggest that simply saving the calculated position is better than
trying to store that in the XML data, espeially since zooming and
panning is going to change where it is drawn.
>><Tile id="Map-1841-Milano" colour="yellow" category="M">
>> <Annotation text="Milano" size="12pt" position="270,.7"
>>justify="b" rotation="0" />
>> <Station id="1" type="City" slots="1" value="60"
>>position="210,.6" />
>> <Track from="1" to "A">
>> <Excludes from="1" to "B" />
>> </Track>
>> <Track from="1" to "B">
>> <Excludes from="1" to="A" />
>> </Track>
>></Tile>
>><Tile id="23" colour="green">
>> <Track from="A" to="D" />
>> <Track from="D" to="B" />
>></Tile>
>><Tile id=16 colour="green">
>> <Track from="A" to "C" level="0"/>
>> <Track from="B" to "D" level="2"/>
>></Tile>
>><Tile id="Map-1830-Altoona" colour="fixed">
>> <Station id="1" type="City" slots="1" value="10"
>>reservedtoken="PRR" />
>> <Track from="E" to="1" />
>> <Track from="B" to="1" />
>> <Track from="B" to="E">
>> <Draw from="E" to="[210,.25]" radius="-.25" />
>> <Draw from="[210,.25]" to="[300,.25]" radius=".25" />
>> <Draw from="[300,.25]" to="B" radius="-.25" />
>> </Track>
>></Tile>
>>
>>
>
>This tile happens to be the only one with drawing instructions.
>I presume, that in all other cases the drawing instructions are
>derived automatically.
>
>
Yes, in the other cases it is trivial to draw straight lines and curved
lines between the edges with practically no computation. Better to
leave that calculation to the software rather than requiring a person to
draw it, and only providing specific drawing instrcutions.
>For instance tile #65 (OO city with a sharp and a wide bend):
>would the tracks be curved by default (as they should, IMO),
>or are special drawing instructions needed to achieve that?
>(TileDesigner derives such things from the specified off-center city
>location).
>
>
The way I handled that in my tile database is I generated the exact
positions and curvatures from the TileDesigner code and stored them in
the database, but only for those which had non-trivial drawing
requirements. If the city circles are positioned on the natural curves
between edges, it should be detected as such automatically.
>>Tile code defaults to the id if it is numeric, otherwise it
>>defaults to
>>"", can be overriden with code="603" etc.
>>
>>
>
>What is the purpose of the tile code?
>
>
The tile code is the number printed on the tile. Unfortunately, these
are not unique as various games have duplicated
>In Tiles.xml I had made a distinction between "id" and "name",
>where id must be unique. "name" was intended to be the tile number
>as printed on the tile (not by TileDesigner, though),
>and is displayed on the screen and in the logs where applicable.
>
>
TileDesigner calls what is printed on the tile the code, so it sounds
like you just renamed it to "name". To me, "name" would be more like
"Milano" or "M" than the number printed on the tile. Obviously, it is
trivial to name it whatever you want (as many of the other terms from
TileDesigner have been changed, such as Junction->Station,
Level->Colour, etc).
>So the two different tiles 69 have ids 69 and 1069, but both have
>name="69". Is this perhaps what you intend to use code for?
>
>
Yes.
>And what is the use of "Category"? Just a simple way to create annotation?
>
>
No, Category controls which tiles may be played there. For example, in
1830 the B tiles may only be played in Baltimore and Boston and also
control upgrades. At sufficient zoom levels, it should be displayed on
the map as it is relevant to game play.
>Wouldn't preprinted Milano then also need drawing specifications
>to show the tracks joining?
>
>
That is the point of the exclude list, to show that the two connections
join before the city and therefore can't be use simultaneously.
>How about scaling?
>The main problem we have with the tiles generated by TileDesigner is,
>that these do not scale down very well.
>Revenue value and tile number get unreadable on the map.
>Do you have a fix for that?
>
>
My perl port of TileDesigner generates Postscript code. The proposed
structure would have it drawing directly on a canvas, whether that is on
the screen or a postscript output file. My intent for handling small
scale is to simply omit text when the scaled point size gets too small.
In this way, the tile code and small text annotations show up
automatically at high zoom levels, while the tile category will show up
even to relatively low zoom levels, with the smallest drawn hexes
showing only the background and track. The RenderTile object that knows
about drawing on the screen would simply compare the final point size of
text it is to draw with a configurable cutoff and ignore the request if
it is too small.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
