Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Sun Jul 22, 2018 10:17 pm

All times are UTC




Post new topic  Reply to topic  [ 27 posts ]  Go to page 1 2 Next
Author Message
 Post subject: [DD] Scale and limits
PostPosted: Mon Nov 20, 2006 9:53 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Tue Dec 03, 2002 10:36 am
Posts: 13174
Location: The Netherlands
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:
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?

_________________
Image
Dutch Trainset for OpenTTD | Dutch Trainset Topic | Combined Roadset v0.10


Last edited by Hyronymus on Mon Nov 20, 2006 11:07 am, edited 1 time in total.

Top
   
PostPosted: Mon Nov 20, 2006 10:47 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Oct 16, 2004 1:42 pm
Posts: 1887
Location: C:\
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 offline due to european security gedöns. DSVGO & GDPR

if you´re asking me per PN or mail, you could have all the files you want.

just playin` family in real life.. nice graphics..! nice sound..!


Top
   
 Post subject:
PostPosted: Mon Nov 20, 2006 11:06 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Tue Dec 03, 2002 10:36 am
Posts: 13174
Location: The Netherlands
Thanks for pointing that out but do you have an opinion too?

_________________
Image
Dutch Trainset for OpenTTD | Dutch Trainset Topic | Combined Roadset v0.10


Top
   
 Post subject:
PostPosted: Mon Nov 20, 2006 1:36 pm 
Offline
TTDPatch Developer
TTDPatch Developer
User avatar

Joined: Fri Mar 07, 2003 1:10 pm
Posts: 3602
Location: Germany
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


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 12:00 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sun Oct 20, 2002 2:55 pm
Posts: 2743
Location: Georgia
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


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 12:46 am 
Offline
Chairman
Chairman

Joined: Sun Sep 03, 2006 8:06 am
Posts: 801
Location: Plymouth, England
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.


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 3:19 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sun Oct 20, 2002 2:55 pm
Posts: 2743
Location: Georgia
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


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 7:06 am 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Fri May 26, 2006 3:54 pm
Posts: 221
Location: Perth, Australia
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...


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 8:47 am 
Offline
TTDPatch Developer
TTDPatch Developer
User avatar

Joined: Fri Mar 07, 2003 1:10 pm
Posts: 3602
Location: Germany
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


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 12:57 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon May 02, 2005 11:05 am
Posts: 15415
Skype: XeryusTC
Location: localhost
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


Top
   
 Post subject:
PostPosted: Sat Nov 25, 2006 1:55 am 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Fri May 26, 2006 3:54 pm
Posts: 221
Location: Perth, Australia
*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.


Top
   
 Post subject:
PostPosted: Sun Nov 26, 2006 3:19 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sun Oct 20, 2002 2:55 pm
Posts: 2743
Location: Georgia
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


Top
   
 Post subject:
PostPosted: Sun Nov 26, 2006 12:54 pm 
Offline
OpenTTD Developer
OpenTTD Developer
User avatar

Joined: Mon Jun 09, 2003 6:21 pm
Posts: 4535
Location: /home/sweden
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)


Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 2:14 pm 
Offline
TTDPatch Developer
TTDPatch Developer
User avatar

Joined: Fri Mar 07, 2003 1:10 pm
Posts: 3602
Location: Germany
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


Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 4:37 pm 
Offline
OpenTTD Developer
OpenTTD Developer
User avatar

Joined: Mon Jun 09, 2003 6:21 pm
Posts: 4535
Location: /home/sweden
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:
File comment: Please note that the red dots should tangent the border of the tile. Bad drawing from my side.
snappoints.png
snappoints.png [ 17.91 KiB | Viewed 11709 times ]

_________________
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 5:05 pm 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Fri May 26, 2006 3:54 pm
Posts: 221
Location: Perth, Australia
Wouldn't something like this be easier?

Code:
'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?)


Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 6:19 pm 
Offline
OpenTTD Developer
OpenTTD Developer
User avatar

Joined: Mon Jun 09, 2003 6:21 pm
Posts: 4535
Location: /home/sweden
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)


Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 6:26 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Tue Dec 03, 2002 10:36 am
Posts: 13174
Location: The Netherlands
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.

_________________
Image
Dutch Trainset for OpenTTD | Dutch Trainset Topic | Combined Roadset v0.10


Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 6:27 pm 
Offline
TTDPatch Developer
TTDPatch Developer
User avatar

Joined: Fri Mar 07, 2003 1:10 pm
Posts: 3602
Location: Germany
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


Top
   
 Post subject:
PostPosted: Sun Dec 10, 2006 10:26 pm 
Offline
OpenTTD Developer
OpenTTD Developer
User avatar

Joined: Mon Jun 09, 2003 6:21 pm
Posts: 4535
Location: /home/sweden
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:
'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)


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 27 posts ]  Go to page 1 2 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.