New Size Relations in 32-bit

[brupje]

Look your stations are nothing more than simple rails that are separated with signals at some points and all this needs only a simple pathfinding for trains to use it.
Now airport is NOT rails airplanes have every move hardcoded or else they wouldn't know where to go and even if it worked planes could just get stuck in the midle of your custom airport becouse you did a little mistake somewhere. So making fully working state machines for airports is not a very easy task let alone somehow making it modular...

Sorry I fail to see the difference, allow me to explain how it could work by a nice paint image. It shows two planes, one trying to get to the loading zone, one trying to take off. The user has to make sure the airport has enough capacity for the planes and there is no way planes can crash into eachother. Just like with trains. I can imagine airports in real life are doing the same.

[richk67]

There are no train equivalents for some airport operations - eg. wait in depot until a terminal is free. Also, unlike rail signalling, the finite state machine can make *different* decisions about the *same* sector depending on the final destination of the aircraft.

For example in the intercontinental, the taxiway always has a clockwise rotation for aircraft, but a helicopter waiting on the helipad that decides it needs the depot travels anti-clockwise to the depot, correctly blocking aircraft movement at the time. This just cannot be "signalled". Also, take the taxiway opposite the terminal pads - this has 3 two way entrance/exits, 1 one-way exit, and 4 two-way terminal pads. Laying out signals for that would be IMO impossible without dumbing down the movement to "allow only 1 aircraft in the taxiway sector" and writing a fully fledged PBS pathfinder for airports.

It is possible with the Intercontinental to have 8+ aircraft taxiing/on runways at the same time, with 2 helicopters landing as well. I just cant see that level of complexity becoming available through a self-build option. It wouldnt be at all compact either - with loads of space needed to make the signalling visible to the user.

[Aracirion]

I am trying again to sum up the possibilities discussed so far. My main point is that different sizes require work from coders, and personally I don't feel like just modeling for days stuff that will never be in the game because nobody will code it. It is absolutely necessary that some coders give their opinion on that topic. So please if anyone knows how to make coders read this post, do it!


If original sizes are kept, it will not be possible to model to scale! Rather, some kind of cartoon style will be required. train cars for example will have to be shorter and wider, so that 2 cars fit in one tile and the track still looks adequately wide. The same for planes: they have to be shorter and fatter as has been don in av8.

In addition, scales for different things ought to be made diffferent, for example make airport buildings smaller so that airplanes don't look so weird as in the render I posted earlier.

It is of course possible to model to scale and rescale the models later, however a lot of work can be saved if we know now that we don't have to do any to-scale models, eg. a plane has to look good only at one tile width, not at 4!

If sizes are to be made somewhat more realistic, a new system should be worked out now so that people know at what size they should model. In order to do this we should also be sure that this is going to developed, not just make grafics that nobody will implement!

ralistic sizes for vehicles together with a new economy model could in my opinion be a huge improvement for gameplay. However, I doubt they would work with the old economy. Thus modelling at this scale (that is what most are doing right now!) only makes sense if coders will code it!

[Ben_Robbins_]

I think the current solution is for everything to be modelled realisitic scale as was originally proposed by Alltaken. Then for the moment we render things close to the original scale in 32bpp. The obvious flaws, now more visible, should lead people on to coding it to make it posible for the other suggested scales. The fact that modells would already then be avaliable should be an encoragment for programmers to sort out these options.

My concern is that would it be posible for programmers to make the scaling of things customizable in the game, so you can pick 1 of the suggest 4? Or would this just varie so much that in fact you would just need different builds of the game alltogether?

Another minor concern with this is for trains that are longer than the originals, they don't need shrinking so much as squashing length ways, so some meshes would need a modifier just to temporarally reshape them to fit over the original graphics, but that can be debated later I think.

[athanasios]

I insist on realistic sizes. Yes, if graphics are available coders will be prompted to code. Otherwise even if they code there will be nothing available for their code.

It will be a great waste of effort to draw for current unrealistic scale, and then after a couple of years have to redraw. It is preferrable to draw a bigger realistic graphic and resize for current engine. Better 256, if hardware can handle. (Simutrans is already 128.)

[DaleStan]

Better 256, if hardware can handle. (Simutrans is already 128.)

And hardware already can't handle it.

One of the major reasons I quit playing Simutrans is because my computer can't handle more than 5 or so FPS with the 128 graphics.

[prissi]

[offtopic]
There have been lots of improvements to Simutrans, thus 128 set runs not that much slower than the 64 or 96 set.
[/offtopic]

The logic of the game should not be affected by the tilesize. Thus, it would make sense to allow for 32, 64, 128, 256, 512, ... tiles. (However, keeping in mind 256*256 mean 4 tiles wide on a 1024 screen and typically 30-60 kB per sprite, since jpg textures are really out of question only some transparency RLE seems likely to have enough performance). Especially considering the current images are already 256x256 rendered (mostly).

The main problem I see, is that OTTD (in relation to simutrans) needs a lot if things to start, which must be all there as basic requirement. You cannot start with just one house and one vehicle only roads etc. And that flexibility is harder to achieve in the current code, imho.

[Celestar]

Ok this is my very first post in a while, but I'm still active.

Just to throw it some numbers. Currently a tile is 32x32 pixels in size, with a maximum map size of 2048x2048 tiles (which is not going to be extended any time soon I guess), that makes a total of 65536 pixels. If you imagine each pixel to me 1 meters, that "map" is 65km in length. Otoh, if you want that map to be 4000km in length, each pixel is 61 meters in length or carries about 20 train carriages next to each other ... so both options are not really helpful. Even if we increase a tile to 128 x 128 pixels, it doesn't help a lot; thus we have to use "creative" scaling.

My suggestion would be:
For buildings, vehicles, etc a tile would be about 25 meters in length
For airport buildings a tile would be 250 meters in length.
For runways, one tile is 500 meters,
For distances between towns 2000 meters.

This leaves one little problem. a 25 meter wide tile would have to carry about several tracks next to each other which will not happen any time soon.

so if we have a 25 meter tile, with 64x64 pixels each pixel is 0.39 meters wide, which gives ample space for details.

A very large aircraft would then be 3x3 tiles in size with smaller aircraft being a little less than one tile.

Train engines and wagons would vary between 1/2th a tile and full tile.

Houses could be 2x2 or even 2x3 per tile up to houses that take about 2x2 tiles.

With 12.5meters, a wagon would be much longer than one tile, causing at least display problems in the "curves" (or kinks)

Celestar

[doktorhonig]

Time is another important aspect.

If we have that 65 km line, and a train travelling this distance (which would be a nice realistic distance for an express train, it should also look realistically.

So travelling this distance at 200km/h should take 20 minutes. I don't know how many years pass by in 20 minutes, but probably this train would be too old after some rides. (which is unrealistic, noone buys a train for 20 rides).
To do things right, we should find the right speed for the game. If it is too slow, we wouldn't be able to finish a game before we die. If it is slow, and we use a speedup (which would only look unrealistic) it would be ok though.
If time goes by too fast, a train is used a few times, before we buy a new one. This is actually happening in OpenTTD right now, it comes apparent when playing really large maps, and one ride is longer than a repair/service interval. The revenues are multiplied to compensate this, but with larger distances, this problem gets worse.

[Celestar]

I'm already in the planning stages of a economy/balancing branch which will commence at the end of this month. I will most certainly bear the time factor in mind. I think it will be adjustable in the end.

Celestar

[Darkvater]

I would like to summarize a part of the discussion there was on IRC with Aracirion.

Basically once 32bpp is finished, it will be ready to accept 32bpp graphics and use those. Since the 32bpp branch is basically nothing more than allowing full colour graphics to be used in OpenTTD all graphics used there have to use the same scale as the current graphics; or at least with scales *very*very* close to it. This is feasible and will work.

Lots of people here are however in favour of "realistic" scales, relative-sizes, etc. This simply is not possible without major changes to the code in big parts of it. If I look around at the current developers, including myself, I see the chances of this being coded (in addition to all the other features/fixes/changes there are still needed to be done) to be pretty slim and a pretty long-run investment.

I just wanted to clear some things up as Aracirion asked, and let you, the graphics artists know where we stand and so you know what effort to do.

[athanasios]

2048x2048 only? But there is a topic with a diff for 4096x4096...

[Ben_Robbins_]

Darkvater: So in conclusion it's what I said before. If there is chance of new scales being coded in then I think the graphics should be made now so they can meet all requiments, wich is realistic scale. But, for the moment we would render them to the original scales.

Cheers for yours and Celestar contribution to this disccusion, its cleared some stuff up.

[brupje]

Darkvater: So in conclusion it's what I said before. If there is chance of new scales being coded in then I think the graphics should be made now so they can meet all requiments, wich is realistic scale. But, for the moment we would render them to the original scales.

Cheers for yours and Celestar contribution to this disccusion, its cleared some stuff up.

The way I read that message was, all effort put into making realistic sizes is probably futile.

[Darkvater]

2048x2048 only? But there is a topic with a diff for 4096x4096...

Do you want a 32Kx32K map? I can make you a binary within 2 minutes. That does not mean it'll ever be usable. I have a not so old laptop and busy 2k maps are already a strain on the computer. Anything bigger than that is not really realistic. I've said the same about vehicles and I'll say the same about mapsizes: If you can show a sensible savegame which is FULL on a 2k map, we might consider upping the mapsize, but not before.

@burpje: not exactly futile, but pretty much unusable for a long time; which could boil down to futile.

[Celestar]

There will not be a computer in the coming years that can give you realistic sizes (unless you wanna go in the MPP region). Realistic sizes would be about 25m tiles and about 100.000x100.000 maps, resulting in a memory usage of something like 150GB, let alone the CPU cycles you need to burn, just to simulate the map. As I said above, there needs to be something like dynamic scaling.

I agree that things like houses, vehicles, trees should be in scale, as their sizes barely cover two orders of magnitude (start out with something like 3m for a smallish tree and end with something like 300m for an oil tanker). However, these things are basically not too poorly scaled now (apart from ships maybe).

Now if we assume the track layout to remain (and it will for a very long time), than the longest wagon needs to fit on the shortest possible straight piece of track. This shortest piece of track is half a diagonal of a square. Long passengers wagons are around 25m long (26.4 meters to be exact), which would mean a single tile needs to be 35.36 meters along one edge. Make that 32 meters for simplicity, so a 64x64 pixel tile gives you a resolution of half a meter and a 128x128 gives you 25cm. If this is still not good enough for you, give it a shot with 256x256 pixels and you end up with 12.5 cm.

Maybe it should be noted that increasing the pixel count per tile is not that much of an effort, it basically is the same as adding more zoom levels once the spirtes are there.

However, if you assume to store 10.000 sprites in the spritecache, with 32x32 pixels (32bpp) they need 40MB of memory, with 128x128 this already grows to half a gigabyte. 256x256 would be 2 GB, and 10.000 sprites is not THAT much as you might know.

So for a start, I think 64x64 pixel tiles would be a prudent option with the possibility to load 128x128 pixel tiles if the user thinks his hardware can cope.

Please bear in mind that openttd is still supposed to run on non-state-of-the-art hardware.

As Darkvater mentioned, it takes about 2 minutes to create a binary that can deal with 32kx16k maps, but trust me, I tried an 8k x 8k map and it runs unbearably slow even without a single vehicle on it on my computer (FX-57 CPU), and we do not feel like making openttd for 16CPU server-monsters.

Celestar

[Aracirion]

First thanks for the posts about the technical issues. This is really needed.

In my opinion bigger maps than 2k are not even desirable: Vehicles move at about realistic speeds in terms of distance/time (eg. my jumbo-takeoff animation posted earlier used realistic speed). Assuming a tile-size of 12,5m, 2048 tiles equal 25,6 km. a plane moving at 900 km/h will take about 1 m 40 s to cross that map. In my opinion this is enough for now.

So for a start, I think 64x64 pixel tiles would be a prudent option with the possibility to load 128x128 pixel tiles if the user thinks his hardware can cope.

The size currently worked on is tiles 256 pixel wide. If that is not technically possible anytime soon, I would propose stopping to work on that size and adopt 128 instead. that way, the level of detail required for models would be drastically reduced, and I suppose progress could be made much faster. As a bonus, it will be easier to make newgrfs, and we could expect more variation in vehicles available.

-EDIT-
@Celestar: do you think there will be so much oil around on a map that you need full-sized oil tankers to move it around? I f there won't, we also don't need a ship that size, and maybe 100m or so will be the longest ship.

[Celestar]

I think 128x128 is a good compromise if peter1138 and Darkvater agree. There could as well be a set of 64x64 for lower performing computers that just disables the closest zoom level.

About the oil tankers, I'm not so sure that we need a full sized one, but something like 150m would be nice.

Celestar

[Ben_Robbins_]

Darkvater: Is that ''long time'' long enough that models should just be made small now, and completely new models made at a future date? If 'long time' could mean its within a year or so of the 32bpp being done, then I think just making them fullsize now is the answer. I'm just concerned that people will think its not worth wasting a LOT of time modeling models for the additional zoom levels if its known that, a short period after, these models would be useless and need replacing.

[brupje]

I think 128x128 is a good compromise if peter1138 and Darkvater agree. There could as well be a set of 64x64 for lower performing computers that just disables the closest zoom level.


Celestar

That could be a unfair advantage in multiplayer mode.

You probably can store the sprites in PNG format in the spritebuffer. Exchanging performance for memory.