Suggestions on tiles

[Peter Dobrovka]

I have several suggestions for you, pick out what you like:

1. Street tiles

One piece of street should be 1x1. But this should mean only one lane (and so one direction)! To lay a bidirectional road you need to have minimum 2 tiles. Exactly like the railroad tracks.

Why? I tell you:
- Streets become broader in comparison to railroads like in reality
- You can construct multiple-laned roads
- You can construct one-way-roads (or at last have them in the random map in your cities).
- You can have roads with a grassy stripe between the lanes.

In Traffic giant the sidewalks are an additional 1 x1 tile, where you can place your bus stops.

2. Railroad tiles

No changes to TT.
But I would suggest to have the station platforms being separate 1 x 1 tiles. It looks nicer.
And I would suggest to disallow 90° curves.
Place signals between tiles, not on them (like in simutrans)

3. Buildings

Can consist of x*y tiles

4. Elevated tiles

In various heights, allow to build on on them like on a "second floor".


Peter

[Arathorn]

Sounds good, thank you!
Maybe the normal tiles can be devided into four sub-sections, a double road would take the whole tile and the train only half of it (two quarters).
buildings could then be one tile or more.

[SHADOW-XIII]

I was talking eariler with rein about two-way railways on the same square ... but he didn't agree .. maybe now he will

[rein]

well, i was about to make a pointer in every tile to a construction (in dynamic array) that stands on it - so there's no problem in 'multi-tlie buildings

hmm, the trhead about roads really sound interesting, but tiles will have to be smaller 2 times... similar thing could be done with various road tiles and appropriate flags to them (one-way, two-way, is sidewalk etc) but i was also thinking about making defined multi-tile roads complexes, for example a big crossing with many slip-roads just as a one construction (with special vehicle paths declared in ini files)

[SHADOW-XIII]

Like I said he change his mind

[Peter Dobrovka]

The only difference in making 2 x 2 tiles or to subdivide a tile into 4 pieces is that the latter is much more complicated to handle and less flexible.

Peter

[mp3Pro]

how about making it where you actually get a a curve instead of an angle on the curves?

[Raichase]

Peter! You are a brain and a half! Glad to have you working with us Oh and welcome to our forum :)

[Hajo]

The only difference in making 2 x 2 tiles or to subdivide a tile into 4 pieces is that the latter is much more complicated to handle and less flexible.
Peter

Why?

I mean I'm facing the same problem in Simutrans, and I tend to use the subdivision approach - but of course one of my reasons is that this way large parts of the existing code do not need to be changed.

I see one big problem of the 2x2 tiles appraoch. It needs 4 times the memory always. The subdivision approach only needs 4 times the memory for divided tiles which are usually only a small fraction of all tiles (only roads and rails probably).

OTOH the 2x2 tiles approach allows a overall much more detailed map structure - is that worth the amount of memory consumed?

I mean, quite some players ask for big maps, to please them maps should use as little memory as possible - at least in Simutrans the memory is the only real limit for map size.

Example: a 640x640 map in Simutrans no uses roughly 70MB ram. Dividing all sqaures in 2x2 boosts the memory consumption to 280MB!

c.u.
Hajo

[Peter Dobrovka]

The only difference in making 2 x 2 tiles or to subdivide a tile into 4 pieces is that the latter is much more complicated to handle and less flexible.
Peter

Why?

I mean I'm facing the same problem in Simutrans, and I tend to use the subdivision approach - but of course one of my reasons is that this way large parts of the existing code do not need to be changed.

Well, I think this may be a very large portion of your reasons.

I see one big problem of the 2x2 tiles appraoch. It needs 4 times the memory always. The subdivision approach only needs 4 times the memory for divided tiles which are usually only a small fraction of all tiles (only roads and rails probably).

I don´t think so. You would need 4 times them mem for the landscape, but for everything else the subdivision would consume about the same as the "many tiles" approach.

OTOH the 2x2 tiles approach allows a overall much more detailed map structure - is that worth the amount of memory consumed?

I think it is. Of course the handling is not the only argument. With subdivision you cannot place something half a tile left or right and cannot build half tiles.
One tile for 2 lanes is too rough for my fine esthetic feelings... : wink :

Now my answer is done, but I cannot leave this uncommented:

Example: a 640x640 map in Simutrans no uses roughly 70MB ram. Dividing all sqaures in 2x2 boosts the memory consumption to 280MB!

AAAAARGH!
Why? What information do you store in the squares?
If you consider 4 bytes and a pointer per square for the landscape you will get 3276800 bytes.

Peter

[Hajo]

AAAAARGH!
Why? What information do you store in the squares?
If you consider 4 bytes and a pointer per square for the landscape you will get 3276800 bytes.

Peter

A square with a reference to one ground is 10 bytes. Squares can have more than one ground, each additonal ground adds 4 bytes to the square.

The ground is between 24 and 40 bytes depending on the ground type.

But there are up to two trees per sqaure, and each tree is 28 bytes. Buildings are 56 bytes. There are ways. There are height arrays and marker arrays. I think overall it just sums up to the amount that I measured without much waste in the square data struture itself.

Why are the objects so 'big'?

Each object constains its position on the map, that is 6 bytes. It has an image number, that is 2 bytes. A set of flags, that is another 2 bytes. Then the compiler adds some overhead (virtual function table ???), that are 12 bytes. So the absolutely minimum for an object is 22 bytes. Trees have a type and an age so it sums up to 28 bytes.

I'd pretty much like to shrink all the objects, but I don't see much more potential for doing so ATM. IMO it needs a completely different design if you want to shrink the memory requirements significantly.

I'm curious how the TT2 programmers will solve that problem.

c.u.
Hajo

[Hajo]

With subdivision you cannot place something half a tile left or right and cannot build half tiles.

With subdivision you can build half tiles. At least for ways.

Object placement:

In Simutrans you can already place objecte freely inside of tiles and across tile boundaries. This is quite independant from subdivison or tile sizes. Just think the tiles are nodes of a one-level deep quadtree.

Vehicles move over tiles and tile borders. That should prove that there are no positioning restrictions.

If you don't believe me, I'll change the city building code to shuffle the houses around ... will look ugly but should prove the fact that each thing can be placed anywhere on the map. I don't use that because if houses are centered on the sqaures 'collsion detection' is much easier, just check if the sqaure is occupied. Trees are not centered ...

c.u.
Hajo

[rein]

before you will look into my simple code:

right now my tile structure uses separate pointer to dynamic vehicles list on it and a pointer to static world object (trees, houses, roads, railways, single rocks), and i think that needs to be changed asap. In this case we can use only one object per square... and i'm hasitating in one question:

should the tile points just to an OBJECT TYPE in object types array
OR
make a dynamic list of all objects on the map (apart from object types array) and make each tile pointing to a specified object (every tree or building on the map has it's own unique parameters)

[orudge]

The latter would be quite good in some ways, but would use a lot of memory, etc. I think the former might be better in performance terms. What does everybody else think about this?

[uzurpator]

Rein - how you want to alter the map with pointing to static default objects? I mean - each tree has its age and placement. Also - multi tile objects need to know which tiles they use, otherwise removing (or doing whatever else) them will only remove (or alter) contents one tile. The more problematic objects, the more data to store.

IMO the only way is the second one.

[orudge]

Yes, thinking about it, the latter may well be necessary. Especially if we want multi-level bridges and all that sort of thing.

[Hajo]

should the tile points just to an OBJECT TYPE in object types array
OR
make a dynamic list of all objects on the map (apart from object types array) and make each tile pointing to a specified object (every tree or building on the map has it's own unique parameters)

In Simutrans objects like vehicles have some static content and some dynamic content. I.e. the vehicle type determines all things like top speed, power, base value etc. but each vehicle has individual data like current speed, position in the map, user-given name ...

You won't succeed with static content only - well, the rocks and such things might all be the same

You need to find a good mixture of static type/description-like data and per-instance data.

c.u.
Hajo

[rein]

right, I think the same, first option was just temporary

and for all objects structure, unions would be the best i think to demarcate static (decoration, buildings) and moving ones (vehicles)

[Peter Dobrovka]

Well, Simutrans has of course offsets to move the graphics pixel-wise, but applying this to buildings and ways to position them on half or even quarter tiles makes normal collision detection by tiles impossible and comes close to collision detection by objects. Also the connection between ways becomes complicated because of the possibility of shifting.
Not to speak of the problems of uneven ground and the graphical artifacts that would result.
Better wasting some memory...

With some thinking I think it can be avoided that the compiler produces 12 redundant bytes per tile.

Anyway, here is my suggestion:

Tile:
4 Bytes and a pointer (=8 Bytes, important for memory alignment)
Byte 1 codes the height
Byte 2 codes the terrain type
Byte 3 and 4 remain as reserved for later ideas regarding the landscape.
The pointer points to something more complex, if it is there. If not, then it is NULL.
The complex structure is allocated when needed and demolished if not needed. It could look like this:
Byte 1: What is it? (track, street, building, etc.)
Byte 2: Who owns it? (player no)
Byte 3: At what height is it?
Byte 4: How high is it?
Byte 5 + 6: pointer to next complex structure (which may be at another heigth). NULL, if there is none.
Bytes 7,8,9,10,11,12,13,14,15,16: Store additional information, depending on Byte 1
Just as example:
Track:
Byte 7: Direction(s)
Byte 8: Y/N Flags (electrified, station, etc.)
Byte 9+10: Block No
Byte 11,12,13,14,15: special information for pathfinding
Byte 16: reserved for later ideas

Peter

[SHADOW-XIII]

But remember about building underground ...