[DD] Scale and limits

Development discussion about Transport Empire. Other discussion to General forum please.

Moderator: Transport Empire Moderators

User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13190
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

[DD] Scale and limits

Post by Hyronymus » 20 Nov 2006 09:53

Scale and limits

One tile is a square with a dimension of 16m x 16m (256 m2). A default map is 1,024 x 1,024 tiles (or 16,384m x 16,384m (≈ 256 km2)). There should be hard limits imposed on the maximum size of the map.

Code: Select all

Unsigned
32 bit (int)   	= 4,294,967,296
16 bit (short)	= 65,536
 8 bit (byte)	= 256 (equals TT size)
Height is stored as a mesh of all vertices with a 0.1 m resolution. 65,536 values are possible: 0 being the lowest, 65,535 being the highest. Server limits (via lua scripts) can determine soft limits.

Question1: Do we accept the tile size of 16m x 16m?
Question2: What does the code block illustrate?
Last edited by Hyronymus on 20 Nov 2006 11:07, edited 1 time in total.

User avatar
Seelenquell
Tycoon
Tycoon
Posts: 1888
Joined: 16 Oct 2004 13:42
Location: C:\

Re: [DD] Scale and limits

Post by Seelenquell » 20 Nov 2006 10:47

Hyronymus wrote:Scale and limits

One tile is a square with a dimension of 16m x 16m (256 m2). A default map is 1,024 x 1,024 tiles (or 16,384m x 16,384m (≈ 16 km2)).

16000mx16000m=256(km²) :twisted:
i did all models/renderings/textures myself. no conversions.

seelenquell.pytalhost.com has been reactivated from 16/07/28 till 18/05/31.. now it´s deactivated. at least there..
new URL is: http://seelenquell.125mb.com

User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13190
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus » 20 Nov 2006 11:06

Thanks for pointing that out but do you have an opinion too?

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os » 20 Nov 2006 13:36

TTD has actually the concept of fine (precise) coordinates because if you have a coordinate system only of tiles, how do store where a vehicle is on that tile?

So TTD tiles are 16x16 fine units. The reason is simple, 0..15 can be stored in 4bits. So converting between fine coordinates is easy with a simple bit shifting. I guess the best way is to show it in hex format:

0x0TTP

TT = tile coordinate = 0..255
P = precise/fine coordinate = 0.15

So you not only need a scale for your tile coordinates, but aswell a scale for on the tile. Because I don't think your vehicles should move in one step from 1 meter to the next one. Consindering you have a freeform camera. This really depends aswell on how close you can zoom up to a vehicle so you can see the steps...

If can't zoom closer as TTD, the 16 units/meters per tile like TTD are fine, otherwise you need a finer scale then meters...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image

User avatar
Lilman424
Tycoon
Tycoon
Posts: 2743
Joined: 20 Oct 2002 14:55
Location: Georgia
Contact:

Post by Lilman424 » 21 Nov 2006 00:00

The problem with assigning a hard scale of 16m per side for a tile is that the scales would be different. It makes sense for train cars, being that one tile would hold, what, 2 cars? However, that's a small scale for the entire map. An entire map, as said, would only be about 16 kilometers. That wouldn't even be enough to cover a large city, in theory. Maybe there should be one scale for vehicles and infrastructure and another for map elements.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction. - Albert Einstein

m4rek
Chairman
Chairman
Posts: 801
Joined: 03 Sep 2006 08:06
Location: Plymouth, England

Post by m4rek » 21 Nov 2006 00:46

Lilman424 wrote: Maybe there should be one scale for vehicles and infrastructure and another for map elements.
which just happens to be what i want to avoid... probably cos TTD has each "thing" for itself style scales. ie, everything has to be proportional to itself and itself alone.
Toyland isn't a climate, it's a mistake.
Everyone has a photographic memory - Some just don't have film
No matter how hard life gets, remember there is always light at the end of the tunnel. Let's just hope it's not a train.

User avatar
Lilman424
Tycoon
Tycoon
Posts: 2743
Joined: 20 Oct 2002 14:55
Location: Georgia
Contact:

Post by Lilman424 » 21 Nov 2006 03:19

But then either the scale is going to have to be much bigger (say, 50 m per side, or maybe 64 if you want to keep the powers of two), or else the maps are going to be huge, or the amount of stuff on the map is going to be small.

I mean, how many say, coal mines and coal power stations are less then 20 or so km apart?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction. - Albert Einstein

User avatar
aarona
Traffic Manager
Traffic Manager
Posts: 221
Joined: 26 May 2006 15:54
Location: Perth, Australia
Contact:

Post by aarona » 21 Nov 2006 07:06

I think we could get away with having mind bogglingly sized maps by dismissing the technique of having an array which tells us whats in each tile by using a quadtree.

Why might this work?
Now obviously if we have 16m per tile there is NOT going to be a lot of variation between height, texture, tree coverage, etc, ON AVERAGE. If there is an area of activity (e.g. road or town) then yes, there will be more data there, but on average most of the map is going to be just tree laden wasteland.

To store this information one could simple state in the area of the quadtree that there are x number of trees with a pattern of y (where y tells us the random seed to determining the spread of trees). This way we have a perlin noise situation, where we can now compress data down to a few parameters which are reproduceable on all machines.

Should a tree be destroyed/some rail be built etc, we would store the delta's. (That is, the difference between what the quadtree says, and whats actually in there).

For the heightfield...we would simply use a 256x256 map and spread it out, and use a sensible/reproduceable interpolation function to fill in the gaps...

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os » 21 Nov 2006 08:47

I don't want to cut this really here, but actually the discussion, is about the questions rised in the first post. What you actually do is to describe the random map generator.

To answer Question2 in short, it shows native data types which can be used to store positions in the engine, with the error mentioned in my last posts - That TTD doesn't use only Bytes but actually 12 bits in a word. -
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image

User avatar
XeryusTC
Tycoon
Tycoon
Posts: 15415
Joined: 02 May 2005 11:05
Skype: XeryusTC
Location: localhost

Post by XeryusTC » 21 Nov 2006 12:57

I think we should do vehicles in one scale and map objects (buildings, trees) in another scale. Imagine a big open mine, which can be several kilometers across, this means that one mine covers ~25% of the total map, scaling this down to a train of a reasonable size (say max. 15 cariages + 1 or 2 locs) would make the game much more playable. Another thing is the relative sizes of vehicles, I would like to see that your average road vehicle isn't the exact same size as a ship for example. And all building should be the same ofcourse, your 80m² house and a 500m² warehouse shouldn't be equally big.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
Image
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
Image Image Image Image Image Image Image

User avatar
aarona
Traffic Manager
Traffic Manager
Posts: 221
Joined: 26 May 2006 15:54
Location: Perth, Australia
Contact:

Post by aarona » 25 Nov 2006 01:55

*bump*

We really need to come to a conclusion here...

I'm for having a dual scale.
16m per tile for vehicles
32m per tile for landscape/scenery

Instead of using some radomly generated map, it might be cool if someone could submit a real life (with interesting features/but still useable) height map to be used for experimental purposes. The benefit is that you could get your own home town on the TE map (so to speak)!

Of couse we need to know the correct scale before this can be done, etc.

User avatar
Lilman424
Tycoon
Tycoon
Posts: 2743
Joined: 20 Oct 2002 14:55
Location: Georgia
Contact:

Post by Lilman424 » 26 Nov 2006 03:19

32 meters seems reasonable. that'd be about....12000 square feet per tile, which seems about right for a moderately sized house lot.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction. - Albert Einstein

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu » 26 Nov 2006 12:54

I agree, dual scale is the way to go.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os » 07 Dec 2006 14:14

To keep you on track:

We have now a dual scale, still not decide how scales work, and how they are stored internally and what sizes they have. How much precise units a tile needs.

I mean by scale as the DD text implies (you see the compare with TTD), how the engine can store a position of something like vehicles, like buildings, building parts? if you can store several stuff on one tile

Some sample:

A train is derived from a Vehicle Object.

vehicle.x = ?
vehicle.y = ?
vehicle.z = ?

if I put x = 1 what does that mean? 1 can't mean a full tile. so you need to devide your tile in some form for your vehicle. If we say a tile has 16 points in the x axis. A vehicle can be on 16 positions on a tile...
So if vehicle coordinate devided by 16 is the tile coordinate. Without such basic rules, you can't draw a object or do some logical calculations. If you can't decide it now or don't want it:

You need to estimate if you have enough number room to handle you needs in sizes (map size( and simple give the ratio a name as constant. FINETILESIZE. Set it to a good start number and be happy.
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu » 07 Dec 2006 16:37

We have dicided that for building tracks we will use snappoints as the red dots in the attachment. Tracks (green) will be connected to so that their corners are connected to two red dots, see the magenta circles. Note that if you put two tiles next to each other they will share the 5 dots at the border.

(I don't agree with this placement, I rather think it would be more efficent to just fit the center of the track to a snappoint, but this is what have been decided)

---

This means that these five dots per row/column needs to be included in the coordinates representation. Or should it be 4 since the "last" dot in a row will be shared with next tile?

Other than the 4 or five steps for the dots used for construction we need some steps in between to make vehicle movement smoth. When we say smooth, how close will we look? If we wan't to be able to go really close higher resulution is required.

eis_os says that TTD uses 16 points per tile where a tile is something like 24-32 pixels. Let's say our tiles will be like four TTD tiles and we'll allow double zoom, that means 24-32 => 94-128 pixles. So with the same amount of points per pixels => ~64 points.

Let say that the last (fivth) build-point will be stored on next tile, so that they will not be shared speeking of coordinates. That means we have 4 gaps between the buildpoints where each gap include the first build-point in that axis. 64/4 = 16, so for each gap there will be 16 coordinate steps, where the first one is a build-point.
Attachments
snappoints.png
Please note that the red dots should tangent the border of the tile. Bad drawing from my side.
snappoints.png (17.91 KiB) Viewed 12851 times
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

User avatar
aarona
Traffic Manager
Traffic Manager
Posts: 221
Joined: 26 May 2006 15:54
Location: Perth, Australia
Contact:

Post by aarona » 07 Dec 2006 17:05

Wouldn't something like this be easier?

Code: Select all

'Universal definitions for 32-bit systems
typedef u16 unsigned short;
typedef u8 unsigned char;

'Implementation
struct PositionT
{
   u16 TileLocation;
   u8 SubTileLocation;
};
Don't flame me if I got something muddled up but the theory is simple.
Max map size will be 2^16 (65,546) and the max "fine" detail will be 2^8 (256). Thus making 32 bits (standard integer size) in total.

Edit:
Zuu: Does this mean we can have two tracks on one tile? Or only the one? (If we can have two then what is the minimum distance between the tracks?)

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu » 07 Dec 2006 18:19

aarona wrote:Edit:
Zuu: Does this mean we can have two tracks on one tile? Or only the one? (If we can have two then what is the minimum distance between the tracks?)
I was thinking about track in the general meaning. Both train tracks and road lanes will be of same width => 4 tracks / cell. Though there are some objections against that scale.

As far as I know there is no minimum distance. Two tracks (general meaning) can be placed next to eachother so that they share one line of build-points.


I don't know how this setup of build-points handle tracks that does not go enterly in the base axis. For reference I diged up the thread where this is discussed. Actually I see no decission was made at the meeting. The logs with a longer discussion than in the thread can be found here (from TE website). The minutes from the meeting just state that no decission was taken.

----
In respond to your proposal: I think it is quite what I had in mind, just that I calculated that the sub-coordinate would be just 6 bits (64 possibilities) instead of 8 (256 possibilities).

If 8 bits are not an issue, sure go for it. It will mean that closeups will look better in sense of movements. I am not good at bit-magic but I guess 8 bits are esier to handle than 6 bits.

---

[OT] If the linked topic will open again I'll probably change my proposal to one snap on each of the 16 sub-cells. (and don't worry I won't edit my post, but make a new one!) [/OT]
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13190
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus » 07 Dec 2006 18:26

I unlocked the topic, Zuu. If you want to continu this discussion in that topic just let me know and I'll lock this one.

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os » 07 Dec 2006 18:27

Well, these points are in 3D Space in TTD and are 16 in x,y and 8 units in height. The 2D Sprite is 64x31 pixel in size.

Sure a struct is aswell possible, calculating with structs will be a bit unhandy, and surely not the fastest. But it's quite fast in access a special component. Depends how your compile handles it aswell.
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu » 10 Dec 2006 22:26

eis_os wrote:I mean by scale as the DD text implies (you see the compare with TTD), how the engine can store a position of something like vehicles, like buildings, building parts? if you can store several stuff on one tile
So from the questions above we have suggested this representation:
aarona wrote:

Code: Select all

'Universal definitions for 32-bit systems
typedef u16 unsigned short;
typedef u8 unsigned char;

'Implementation
struct PositionT
{
   u16 TileLocation;
   u8 SubTileLocation;
};
Which I think is good. For world XYZ-positions.

What I think we need to cuntinue with is how is buildings, tracks etc bound to a specific cell and sub-cell.

---


I also want to add that other than reprecenting a train with a dozens of XYZ-coordinates it might be an interesting and perhaps good idea to introduce a new L-axis[1] that follows the track. Then for the gfx engine the L-coordinate have to be translated to an XYZ-coordinate, but internal movement of trains might have use for a such L-axis. In an application where I have only one-way "tracks" I've implemented this aproach, but I understand it will be a bit more difficult with two-way "tracks".

[1] L was choosen becues it descibe length.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

Post Reply

Return to “Transport Empire Development”

Who is online

Users browsing this forum: No registered users and 8 guests