Re-scaling Simutrans

Topic: Re-scaling Simutrans (Read 35707 times) previous topic - next topic

Re: Re-scaling Simutrans

Reply #35 – July 23, 2009, 08:08:44 pm

Hajo,

thank you for your input - it is always useful to know the design thinking behind things :-) However, that doesn't really address what I put in my original post as to the reasons for re-scaling: with the new mechanisms in Simutrans-Experimental that require journey times to be measured for matters such as journey time tolerance and comfort, the relative scale of 1km/tile does not work properly, and produces times that are too high. It also allows for insufficient distinction between short, medium and long distance transport (which distinction is important in Simutrans-Experimental, because different sorts of vehicles with different comfort levels, loading times, catering levels, etc. are appropriate for different sorts of journeys).

I had asked a number of specific questions in my original post about economic aspects - I should be very interested indeed in people's views on those particular points. Thank you everyone for your input so far :-)

Re: Re-scaling Simutrans

Reply #36 – July 23, 2009, 08:44:22 pm

Quote from: jamespetts – on July 23, 2009, 08:08:44 pm

with the new mechanisms in Simutrans-Experimental that require journey times to be measured for matters such as journey time tolerance and comfort, the relative scale of 1km/tile does not work properly, and produces times that are too high.

Vehicle speed is a very artificial number in Simutrans. I see no problem to adapting the "time" to a value that works with your formulas?

1km/h doesn't really mean anything currently ... it was just chosen in a manner that 50km/h looked "sensible" to my eyes in a city. You could easily define a "time" scale that fits your formulas - what the player sees on screen is one thing, what the simulation engine uses is another.

Edit: Once I have more time, I'll try to find your questions in the first post. It's a lot of text. But currently I think you try things that Simutrans was not made for, and you might need to program a new transport game core for those ...

Edit 2: I've tried to read a bigger portion of your text. To me, it seems you strive for "realistic" in terms of distance and time scale, which the Simutrans engine cannot provide. So either you drop that requirement, and adjust your formulas so that a 200 tile travel is "uncomfortable" or you need to create a different engine. I'd advice to move from a tile based world to a continuous world, with tables and trees as core date structures, and lookup by object id, not by tile position.

Re: Re-scaling Simutrans

Reply #37 – July 23, 2009, 09:00:59 pm

Hajo,

thank you for your replies :-) I realise that one cannot get it to be completely realistic in Simutrans - I am simply aiming for "more realistic", or, perhaps more accurately, "realistic enough to give full usefulness to the Simutrans-Experimental features". The main reason for the re-scaling is simply to provide a better balance between short, medium and long distance journeys to require the player to use appropriate vehicles for each type, and provide more interesting choices and the possibility for more interesting and subtly intricate networks.

What I found when calculating the figures is that, on any denomination of scale, on a smaller map, either the scale is so small that short distance vehicles are useless because anything more than a few tiles is at least medium distance, or the scale is so large that long distance vehicles are useless because the longest possible straight line journey on the map is barely above what might be considered medium distance. The only solution was to have larger maps. I do not think that a complete rewrite is necessary for that, and in any event, is not something that I have the time or capability to do.

Re: Re-scaling Simutrans

Reply #38 – July 23, 2009, 09:21:30 pm

Quote from: jamespetts – on July 23, 2009, 09:00:59 pm

What I found when calculating the figures is that, on any denomination of scale, on a smaller map, either the scale is so small that short distance vehicles are useless because anything more than a few tiles is at least medium distance, or the scale is so large that long distance vehicles are useless because the longest possible straight line journey on the map is barely above what might be considered medium distance. The only solution was to have larger maps.

Did you try exponential or logarithmic scales? Even something like discomfort = pow(distance, 2), could stretch the short distance comfort zone to about city size, but make longer travels very uncomfortable?

Re: Re-scaling Simutrans

Reply #39 – July 23, 2009, 09:25:44 pm

I had not considered a non-linear system, but wouldn't that break lots of other things, all of which ****ume that things are linear? Wouldn't that also be very confusing and unintuitive for players? Also, I wanted to use realistic values for comfort: the only way to get a reasonable balance without doing an unfeasably enormous amount of testing is to use real-world numbers. Using real numbers for comfort and journey time also makes it much easier for players to understand.

Further, wouldn't a non-linear scale for calculating journey times make a mess of the routing system that uses journey times to calculate the shortest route, causing it to favour excessively a larger number of short journeys over the same distance rather than a fewer number of longer ones?

Re: Re-scaling Simutrans

Reply #40 – July 23, 2009, 09:29:58 pm

Quote from: jamespetts – on July 23, 2009, 09:25:44 pm

Further, wouldn't a non-linear scale for calculating journey times make a mess of the routing system that uses journey times to calculate the shortest route, causing it to favour excessively a larger number of short journeys over the same distance rather than a fewer number of longer ones?

It would indeed. Thus I'd suggest to leave the time as it is now, but for your new formulas, don't use time as input but x^time or time^x ... I'm sure people can imagine that a double as long travel is less than half as comfortable?

Re: Re-scaling Simutrans

Reply #41 – July 23, 2009, 09:39:06 pm

Hajo,

I'm afraid that I don't quite understand, I'm sorry - could you elaborate? I must confess, I am no mathematician, and somewhat shaky on low-level programming...

Re: Re-scaling Simutrans

Reply #42 – July 23, 2009, 09:42:17 pm

Maybe I just talked stupid ... if you need the comfort level in routing decisions, and it is not linear, it might be a problem indeed. I've been out of this for too long, but maybe someone who is more into it, can check if a non-linear scaling could help?

Re: Re-scaling Simutrans

Reply #43 – July 23, 2009, 09:49:59 pm

I don't need the comfort level in routing decisions at present (but I want to retain it as an option for the future), but I need the journey times in routing decisions, and also for calculating (1) whether the journey is so long that p****engers won't bother travelling at all; (2) how important that comfort is (for calculating revenue); and (3) how important that speed is (for calculating the revenue). To make things comprehensible for players, I want the average speed displayed on the "average speed" graph to be on a commensurate scale to any reference to kilometres in the game.

Re: Re-scaling Simutrans

Reply #44 – July 24, 2009, 08:42:28 pm

I tried 4096x4096 512xcities 128xindustries with default city size equals 1600, and it took about 2 min on release build.
When I increase size of cities to 50000 on choice map, it took about 15 min to create ( ~50min on gprof build ).

Run on:
AMD 64bit 5200+ (2Cores), 4GB Ram
Ubuntu 9.04 32bit
Simutrans Experimental 5.1

Gprof output from 4096x4096 512xcities 128xindustries with median citizens per city 50000 below
Memory consumed by simutrans after creating map was 830 MB.

Profile contains:
1. starting simutrans ( ~30s)
2. creating map ( ~50min)
3. about ~3min freeplay without user action
4. saving map (~2min)
5. game exit ( ~20 s )

Code: [Select]


Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ks/call  Ks/call  name    
 13.00    117.11   117.11 549407190     0.00     0.00  stadt_t::bewerte_loc(koord, char const*, int)
 10.64    212.96    95.85 364706243     0.00     0.00  karte_t::lookup(koord) const
  6.85    274.68    61.72    14224     0.00     0.00  karte_t::sync_step(long, bool, bool)
  5.14    321.02    46.34 3704417418     0.00     0.00  int_noise(long, long)
  5.13    367.21    46.20 3983280983     0.00     0.00  karte_t::lookup_kartenboden(koord) const
  4.85    410.87    43.65   237557     0.00     0.00  slist_tpl<weg_t*>::remove(weg_t* const&)
  3.55    442.85    31.98  6996965     0.00     0.00  display_img_nc(short, short, short, unsigned short const*)
  2.99    469.74    26.89 31000511     0.00     0.00  planquadrat_t::get_kartenboden() const
  2.64    493.49    23.75 431849510     0.00     0.00  karte_t::ist_in_kartengrenzen(short, short) const
  2.51    516.10    22.61   417116     0.00     0.00  bauplatz_mit_str****e_sucher_t::find_dist_next_special(koord) const
  1.73    531.66    15.56 2424424730     0.00     0.00  ding_t::get_pos() const
  1.24    542.81    11.14 24962556     0.00     0.00  stadt_t::baue()
  1.04    552.19     9.38   967778     0.00     0.00  hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::put(sync_steppable*, sync_steppable*)
  0.94    560.68     8.49 915996195     0.00     0.00  grund_t::get_hoehe() const
  0.94    569.17     8.49 2637349483     0.00     0.00  operator==(koord const&, koord const&)
  0.94    577.62     8.45 411601927     0.00     0.00  smoothed_noise(int, int)
  0.90    585.75     8.12 606167970     0.00     0.00  simrand(unsigned int)
  0.80    592.98     7.23 1392724500     0.00     0.00  grund_t::get_weg(waytype_t) const
  0.78    600.02     7.04 320128882     0.00     0.00  ding_t::get_flag(ding_t::flag_values) const
  0.77    607.00     6.98        2     0.00     0.38  karte_t::distribute_groundobjs_cities(int, short, short)
  0.76    613.85     6.85 2349165751     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::const_iterator::operator++()
  0.75    620.63     6.79 328759854     0.00     0.00  planquadrat_t::get_boden_in_hoehe(short) const
  0.75    627.37     6.73 2349165751     0.00     0.00  koord_distance(koord3d, koord)
  0.74    634.05     6.68      542     0.00     0.00  slist_tpl<koord>::at(unsigned int) const
  0.71    640.46     6.41 330637814     0.00     0.00  karte_t::lookup(koord3d) const
  0.71    646.83     6.37 313375935     0.00     0.00  fussgaenger_t::sync_step(long)
  0.65    652.68     5.86 755799640     0.00     0.00  slist_iterator_tpl<hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::node_t>::next()
  0.63    658.34     5.65 210929037     0.00     0.00  grund_t::get_vmove(koord) const
  0.60    663.71     5.38 16777215     0.00     0.00  planquadrat_t::rdwr(karte_t*, loadsave_t*, koord)
  0.60    669.08     5.37 316523988     0.00     0.00  vehikel_basis_t::fahre_basis(unsigned int)
  0.54    673.96     4.88 1126814832     0.00     0.00  grund_t::hat_weg(waytype_t) const
  0.49    678.38     4.42  3085439     0.00     0.00  get_aus_liste(vector_tpl<haus_besch_t const*> const&, int, unsigned short, climate)
  0.48    682.71     4.33 2755450246     0.00     0.00  koord::koord(short, short)
  0.47    686.91     4.21  2396339     0.00     0.00  brueckenbauer_t::finde_ende(karte_t*, koord3d, koord, bruecke_besch_t const*, char const*&, bool)
  0.45    690.96     4.04 102900481     0.00     0.00  interpolated_noise(double, double)
  0.44    694.93     3.98 42030290     0.00     0.00  binary_heap_tpl<route_t::ANode*>::pop()
  0.44    698.89     3.96 137476790     0.00     0.00  stadt_t::bewerte_pos(koord, char const*)
  0.44    702.82     3.92 2349582813     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::const_iterator::operator!=(weighted_vector_tpl<gebaeude_t*>::const_iterator const&)
  0.42    706.64     3.82      542     0.00     0.00  slist_tpl<koord>::remove(koord const&)
  0.41    710.35     3.71 46569685     0.00     0.00  grund_t::calc_back_bild(signed char, signed char)
  0.41    714.03     3.69 2349165737     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::const_iterator::operator*() const
  0.39    717.56     3.53 58107946     0.00     0.00  pixcopy(unsigned short*, unsigned short const*, unsigned int)
  0.38    720.95     3.39 203741444     0.00     0.00  karte_t::ist_in_kartengrenzen(koord) const
  0.37    724.30     3.35     5442     0.00     0.00  wegbauer_t::intern_calc_route(vector_tpl<koord3d> const&, vector_tpl<koord3d> const&)
  0.37    727.61     3.31 105455715     0.00     0.00  grund_t::get_neighbour(grund_t*&, waytype_t, koord) const
  0.36    730.82     3.21 1162947311     0.00     0.00  koord3d::get_2d() const
  0.34    733.88     3.06 113961692     0.00     0.00  planquadrat_t::get_boden_count() const
  0.33    736.85     2.98 23772308     0.00     0.00  hashtable_tpl<char const*, groundobj_besch_t*, stringhash_t>::empty() const
  0.32    739.76     2.91 326629625     0.00     0.00  hashtable_iterator_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::next()
  0.29    742.34     2.58 2401002969     0.00     0.00  slist_tpl<hashtable_tpl<char const*, groundobj_besch_t*, stringhash_t>::node_t>::empty() const
  0.28    744.90     2.56 394409010     0.00     0.00  karte_t::lookup_hgt(koord) const
  0.27    747.34     2.44 680559013     0.00     0.00  route_t::ANode::operator<=(route_t::ANode) const
  0.25    749.63     2.29 308512111     0.00     0.00  stadt_t::bewerte_str****e(koord, int, char const*)
  0.25    751.89     2.27 561700816     0.00     0.00  simrand_plain()
  0.23    753.97     2.07  1672401     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::remove_at(unsigned int)
  0.23    756.00     2.04        2     0.00     0.06  karte_t::cleanup_karte(int, int)
  0.22    758.00     2.00 40583965     0.00     0.00  wegbauer_t::is_allowed_step(grund_t const*, grund_t const*, long*)
  0.20    759.85     1.84   900162     0.00     0.00  MTgenerate()
  0.20    761.67     1.82 507734363     0.00     0.00  haus_besch_t::is_allowed_climate(climate) const
  0.19    763.38     1.71 15174334     0.00     0.00  karte_t::ist_platz_frei(koord, short, short, int*, climate_bits) const
  0.18    765.02     1.65 50622775     0.00     0.00  karte_t::access(koord)
  0.18    766.65     1.63 426771711     0.00     0.00  ptrhash_tpl<sync_steppable*>::comp(sync_steppable*, sync_steppable*)
  0.18    768.28     1.63 342388308     0.00     0.00  koord3d::koord3d()
  0.18    769.91     1.63 329983232     0.00     0.00  ding_t::set_flag(ding_t::flag_values)
  0.18    771.53     1.61 454396529     0.00     0.00  slist_iterator_tpl<hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::node_t>::get_current() const
  0.18    773.12     1.59 546432400     0.00     0.00  karte_t::ist_in_gittergrenzen(short, short) const
  0.17    774.68     1.56       91     0.00     0.00  setsimrand(unsigned int, unsigned int)
  0.17    776.23     1.54   685454     0.00     0.00  display_img_wc(short, short, short, unsigned short const*)
  0.17    777.75     1.53   967831     0.00     0.00  hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::remove(sync_steppable*)
  0.17    779.27     1.52 600437204     0.00     0.00  operator==(koord const&, koord const&)
  0.17    780.79     1.51 811692728     0.00     0.00  grund_t::get_grund_hang() const
  0.17    782.29     1.50 16781312     0.00     0.00  planquadrat_t::~planquadrat_t()
  0.17    783.78     1.50 298990603     0.00     0.00  slist_iterator_tpl<hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::node_t>::access_current()
  0.16    785.25     1.47 50361612     0.00     0.00  karte_t::calc_natural_slope(koord) const
  0.16    786.65     1.40 339770087     0.00     0.00  dingliste_t::bei(unsigned char) const
  0.15    788.02     1.36 163078008     0.00     0.00  dingliste_t::get_top() const
  0.15    789.38     1.35 44949134     0.00     0.00  binary_heap_tpl<route_t::ANode*>::insert(route_t::ANode*)
  0.15    790.72     1.34 326615405     0.00     0.00  hashtable_iterator_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::get_current_value() const
  0.15    792.06     1.34 27655731     0.00     0.00  hausbauer_t::get_special(int, haus_besch_t::utyp, unsigned short, bool, climate)
  0.15    793.38     1.32 174228472     0.00     0.00  marker_t::ist_markiert(grund_t const*) const
  0.15    794.70     1.31 17150081     0.00     0.00  perlin_noise_2D(double, double, double)
  0.13    795.91     1.22 62590928     0.00     0.00  karte_t::max_hgt(koord) const
  0.13    797.12     1.21 245128128     0.00     0.00  operator+(koord const&, koord const&)
  0.13    798.33     1.21 804865381     0.00     0.00  boden_t::get_typ() const
  0.13    799.52     1.20 594593471     0.00     0.00  slist_iterator_tpl<haus_besch_t const*>::next()
  0.13    800.71     1.19 146899693     0.00     0.00  operator+(koord3d const&, koord const&)
  0.13    801.88     1.18                             non-virtual thunk to fussgaenger_t::sync_step(long)
  0.12    803.00     1.11 179042014     0.00     0.00  boden_t::ist_natur() const
  0.12    804.11     1.11 34200191     0.00     0.00  freelist_t::gimme_node(unsigned int)
  0.12    805.15     1.04    14227     0.00     0.00  karte_ansicht_t::display(bool)
  0.11    806.17     1.02 414274897     0.00     0.00  grund_t::get_weg_hang() const
  0.11    807.18     1.01 464087130     0.00     0.00  koord3d::koord3d(short, short, signed char)
  0.11    808.20     1.01 16789631     0.00     0.00  karte_t::raise_clean(short, short, short)

EDIT: profile result moved in code section

Re: Re-scaling Simutrans

Reply #45 – July 24, 2009, 10:14:44 pm

YOu took also quite a time to set everything, as simutrans spend more than in minute in sync_steps()? Im am surpirsed than 3 minutes of free running required nearly 30% of the total time.

Re: Re-scaling Simutrans

Reply #46 – July 24, 2009, 10:46:05 pm

So it seems that stadt_t::bewerte_loc(koord, char const*, int) is the culprit. The question is: are there any possible optimisations for this method?

Thank you very much, incidentally, Hanczar for running this test - very useful!

Edit: One possible optimisation that I have already spotted is to change the int argument to a uint16 - would this break anything?

Re: Re-scaling Simutrans

Reply #47 – July 25, 2009, 07:49:21 pm

How scaling is implemented

The new version 6.0 of Simutrans-Experimental now implements the new scale feature. The way that it works is that there is a setting in simuconf.tab (replacing the old "journey_time_multiplier_percent") called "distance_per_tile". This designates the number of meters that each tile represents, in multiples of 10. So, at the default of distance_per_tile=25, each tile represents 250m, or 1/4 of a kilometre. To use the scale from Simutrans Standard, one can simply set distance_per_tile=100, which is 1km/tile. To check the scale used in the particular game, one can use the map window and "show map scale", which will show the current scale in tiles per kilometre. This value is saved with saved games.

All of the following values from paksets are ****umed to be in kilometres and are adjusted accordingly when the pakset is loaded to the appropriate per-tile values for internal use, the UI showing the per kilometre values where appropriate:

Goods/p****enger revenues
Vehicle running costs (not the fixed maintenance)
Way building costs
Way maintenance costs
Tunnel building costs
Tunnel maintenance costs

Note that bridges are not subject to this scaling on purpose: the scale is more accurate when used with per tile values for bridges than for per kilometre values (bridges are hardly ever many kilometres long, and there would be insufficient granularity for bridge lengths).

Also, all distance based settings in simuconf.tab, such as those relating to the distance ranges of short, medium and long distance p****engers, are now in kilometres and not tiles. They are stored internally as tiles, but read from the file as kilometres.

Thus, there is now automatic and accurate correlation between the speeds, the distances and the journey times, all of which use real-world figures and are calibrated with realistic values. There is a particular advantage of that, which is that, if fantastical values were used, an enormous amount of trial and error testing would be needed to ensure that they were calibrated correctly with one another. With every new set of values, the complexity of testing them all against each other would increase exponentially. Simutrans-Experimental introduces a great many new values that need calibrating, and it would be impracticable to test them all in that way. Using real-life values, however, one can just get real world data to calibrate them. One can obtain the real-life building costs of a kilometre of railway track and compare that to the real life cost of running a particular 'bus for one kilometre, or hauling a ton of coal for one kilometre.

Not only are real-world values easier to calibrate, but, if real-world values are used, it gives players who are new to Simutrans but know about real-life transportation the ability to use their actual knowledge to make sensible decisions in the game. People ought not have to learn a great deal of game-specific rules to play a simulation game: real life knowledge should suffice wherever possible. Similarly, if real-world values are used, players can learn about reality simply by playing the game, which makes playing rather more satisfying.

Re: Re-scaling Simutrans

Reply #48 – July 26, 2009, 12:33:25 am

How does this relate to, for example, city sizes? If I were to set distance_per_tile=24, I'd ****ume I'd need to quadruple the city populations to get the same effect?

Re: Re-scaling Simutrans

Reply #49 – July 26, 2009, 09:36:10 am

Yes, you should indeed increase city sizes from what is the norm in Simutrans-Standard to get the balance right in Simutrans-Experimental with the distance_per_tile at a lower setting (including the default of 25). It does not necessarily have to be quardupled, however: if you increase the number of cities and do not disable the feature that will make cities more likely to spawn on lower grounds, you will often tend to get larger urban areas comprising a cluster of a number of individual towns and cities in some places, which is rather more realistic than having single large cities evenly spaced throughout the terrain.

Re: Re-scaling Simutrans

Reply #50 – July 28, 2009, 04:49:57 pm

I have read this thread with some interest, since while I enjoy playing Simutrans, there is some features that are slightly unrealistic. A truck, and even most trains, do not need 2 km to get up to speed. And, living in a moderate sized European city, I think most people would think they'd die if they had to walk up to 1.5 km to the nearest bus-stop (I'd be good for them, but that's something else!). Hence, there's a slight scale issue

The post that made most sense to me is:

Quote from: prissi

Simutrans could have a 3D map with a 16x16 mesh on a single tile which could give 16 times larger maps wihtout loosing to much detail level, imho. But that is ratehr a new effort which would be only loosely built on Simutrans.

Fortunately, I am not a programmer, so I can have the most ridiculous ideas without having to feel guilty because it is not feasible; I was thinking about something among the lines described by Prissi, where a city tile would represent a certain distance, and a 'country-side' tile another distance. As long as cities are static, that would probably even be feasible, as soon as they start expanding I guess that's a programming challenge. Setting aside a certain amount of space for a city might be an option, but has of course other disadvantages.

The 16x16 mesh as proposed by Prissi would of course be ideal, but as I understand not too easy to implement with the current code (like my proposals are

)

Regardless, keep up the great work!!

Re: Re-scaling Simutrans

Reply #51 – July 29, 2009, 08:08:02 am

Ahh, it's not really feasible to have different distances in and out of cities: the inconsistencies in scale would lead to bizarre anomalies (a road/rail line going through a city would be much longer than one going around a city, even though the former is a straight line and the latter a detour, and so on). The 3d system is theoretically possible, but it would require an unimaginably enormous amount of effort, not just coding (although that would be gargantuan in itself), but re-doing all the thousands upon thousands of graphics from scratch.

Re: Re-scaling Simutrans

Reply #52 – July 29, 2009, 09:41:55 am

Quote from: jamespetts – on July 29, 2009, 08:08:02 am

The 3d system is theoretically possible, but it would require an unimaginably enormous amount of effort, not just coding (although that would be gargantuan in itself), but re-doing all the thousands upon thousands of graphics from scratch.

i would think of a mixed system, with the terrain full 3D (a very loose mesh, the tile grid), to save memory and adding more realistic reliefs. All the objects (with the possible exception of ways), instead, should be our beloved sprites. vehicles could then drive on the mesh in 8 views and buildings would need a 3D basement (like now on slopes).

Re: Re-scaling Simutrans

Reply #53 – July 29, 2009, 10:07:12 am

Quote from: fabio – on July 29, 2009, 09:41:55 am

i would think of a mixed system, with the terrain full 3D (a very loose mesh, the tile grid), to save memory and adding more realistic reliefs. All the objects (with the possible exception of ways), instead, should be our beloved sprites. vehicles could then drive on the mesh in 8 views and buildings would need a 3D basement (like now on slopes).

With your 'mixed' system all streets, brigdes and tunnels have to redone too, because they depend on slopes!

Re: Re-scaling Simutrans

Reply #54 – July 29, 2009, 11:26:59 am

still they are a smaller amount. and they could also be replaced by real 3D roads+texture, possibly using Timothy's algorithm for curves.

Re: Re-scaling Simutrans

Reply #55 – July 29, 2009, 04:34:24 pm

Fabio,

if you want to do all the coding and re-drawing for all the paksets, and/or can find people who can, be my guest... ;-) Even that suggestion would, at best, mean that, instead of being a very, very, very, very large amount of work, it would just be a very, very large amount of work. Coding and pakset building resources are currently very limited.

Re: Re-scaling Simutrans

Reply #56 – July 30, 2009, 01:26:18 pm

well, we could have a "gradual" approach to this issue.

1) the terrain can be seen as a 3D mesh. a mesh could reproduce the current terrain: grid 1 tile * 1 tile and 1 in height. textures would apply depending on climate settings, plus shadows on-the-fly. no change to the appearance, so no need for changing graphics at all. terrain is (if possible) a single object, could this reduce the memory consumption?
terraforming only changes the nodes of the mesh.

2a) as a second step, in future, multiple heights could be allowed (half, doulbe, triple, etc.).
at this stage, only half height should imply new graphics and only for half heights (as for steeper slopes no roads would be allowed, maybe excepting powerlines).

2b) as another option, heights could be made freeform, this would imply completely new ways. but this step could never come.

in any case, the tile-based system wouldn't ever change, nor would buildings and vehicles.

Re: Re-scaling Simutrans

Reply #57 – July 30, 2009, 02:19:00 pm

It would still require more coding than available resources presently permit, unless you are able to increase those available resources... ;-)

(At present, the focus is on bug fixing, balancing and pakset production to get at least a working, balanced version with a fully compatible pakset released as a complete package).

Re: Re-scaling Simutrans

Reply #58 – July 30, 2009, 02:40:15 pm

being (at least at the first stage) player-transparent, we should also see the cost/benefits ratio, considering programming time as a cost and resource saving as a benefit. also being open to further development is a potential benefit.

for sure it's not (top) priority, but if the ratio is positive, it could be considered as a mid-long term investment.

Re: Re-scaling Simutrans

Reply #59 – July 30, 2009, 08:10:16 pm

If we find anyone capable of programming graphics to that level, willing to invest that much in the way of resources. Certainly, I wouldn't have a clue where to start graphics programming - my geometary is hopeless.

Re: Re-scaling Simutrans

Reply #60 – July 31, 2009, 07:45:11 am

If you use OpenGL it will do all the geometry transformations for you. The world would be made of quads, that is the openGL equivalent of a tile, or maybe triangles, two of which can shape a tile.

Re: Re-scaling Simutrans

Reply #61 – August 04, 2009, 07:06:11 am

My two cents... If using OpenGL then the updating of the ground tile textures for seasonal changes would be shortened, due to the benefits of the graphics card memory and processor. I honestly don't recall at the moment if unaccelerated OpenGL would take too great of a performance hit, though.

Re: Re-scaling Simutrans

Reply #62 – August 04, 2009, 07:40:01 am

Unaccelerated OpenGL (I translate this to "software emulation" instead of using hardware to render) uses to be very slow. Linux users can test the Mesa library to get an idea of software OpenGL rendering speed.

But many systems should support OpenGL these days and if I ever make a 3D game I guess I'll use OpenGL. At least I got good results with C and Java OpenGL bindings.

Re: Re-scaling Simutrans

Reply #63 – January 05, 2010, 12:28:38 pm

Hello together!

What I not yet completely understand: Is now "everything" (like speeds, distances, time, station coverage, vehicle size) in Simutrans-Experimental true to scale with this feature?
And if not, why not?

Thank you for your enlightenment!

Greetings,

Mazze

Re: Re-scaling Simutrans

Reply #64 – January 05, 2010, 01:54:49 pm

Distances, revenues and costs scale in Simutrans-Experimental. It does not make any sense also to scale time by the same rate, as scaling everything equally would have no effect on anything, and would be pointless. Because distance, but not time, is scaled, speed cannot be fully scaled. Acceleration is, however, from Simutrans-Experimental 7.1 and onwards, scaled with the distance. Station coverage is not scaled because it needs to be customisable independently of the scale, and it would be confusing to specify such short distances in meters in simuconf.tab rather than tiles. However, the default setting of 3 tiles in Pak128.Britain-Ex's simuconf.tab takes into account the fact that the scale for Pak128.Britain-Ex is 250m/tile (or 4 tiles/km).

Re: Re-scaling Simutrans

Reply #65 – January 05, 2010, 03:16:24 pm

Thank you for your explanation. I was a long-time Simutrans player (quite some years ago already), I'm now coming back -- at least at the forum, not yet playing -- because of Simutrans-Experimental sounding that promising.

Maybe I quirked it a bit up when talking about "scaling time", but what I meant was, are trains -- when running at 100km/h -- travelling 100km in Simutrans in one fictional Simutrans-hour? And of course I know, that it does not make sense to have "1 fictional Simutrans-hour = 1 realtime hour", but if it was "1 fictional Simutrans-hour = 1/6th of a realtime hour" the factor in time would be 1 to 6, and the train travelling at 100km/h should go as far as 600km in one realtime hour. This would allow for more realistic scheduling and gameplay -- and the use of real-worls values instead of fictional ones.

I have two things I've thought of that are depending on my question above, and I'm sure, the second one was already denied earlier, but I just wanted to give it a short try here for Simutrans-Experimental:

*) Why don't we make station-coverage degrading the farther we get from the station? This could attract people near the station more, but would only attract some of those living further away. This would make up for a more realistic station planning and placement, which is not just build upon trying not to miss any tile, and every tile that you hit is a 100% hit. The coverage could also be depending on the station-type if this would resemble anything that makes sense, or on the length of the journey somebody wants to make (for a long journey, you are maybe more likely to accept a bit of a way than for a short inner-city ride).

*) When scale in Simutrans-Experimental is now true, and time is just representatively faster in a defined and maybe during gameplay changeable factor, it would be really attracting to me to have the option of schedules. This would include scheduling of not just arrival and departure times of trains or other vehicles, but also implicite planning of a station stop's occupation, trying to make good connections for important routes so that nobody has to wait too long for connecting lines, and the situation of vehicles being late. Of course it would make sense then, that p****engers try to take a route which costs less time and money, depending on their connections.

For the first part of my post, I just wanted to be sure I understand the features and the work of relation of time and distance in Simutrans-Experimental correctly, for the second part, it is more something like a wishlist, and I wanted to contribute something to this great game I always liked very much already.

Have a good time,

Mazze

Re: Re-scaling Simutrans

Reply #66 – January 05, 2010, 03:44:56 pm

Mazze,

thank you for your interest in Simutrans-Experimental. Subject to the fact that there are, and always have been, two independent time scales in Simutrans (albeit standing in a fixed relationship to each other): the macro (p****age of years for the purposes of billing and technological advancement); and the micro (the p****age of hours, for the purpose of speeds, journey times and waiting times), the speeds and distances are all internally consistent at any scale, such that, at a speed of X km/h, a convoy will travel X km in one hour on the micro scale.

As to your suggestions, the former might be worth considering at some point (along with the possibility of different kinds of stops having different coverage radii), although adding new such features is not a high priority at present, as there are a number of playability issues and bugs that need to be ironed out, I need to help to make Pak128.Britain-Ex more complete. I shall bear it in mind for the future, however, if it can be implemented without overly degrading performance. One potential issue is how to represent this easily in a relatively simple GUI.

The second suggestion is more problematic, since introducing timetabling is likely to make playing Simutrans efficiently enormously difficult: real-life timetables require extraordinarily expensive and complex computer software to perfect, and, in the days before computers, skilled mathematicians had to spend days, weeks or months agonising over every detail. The complexity of the task increases exponentially with the complexity of the network, so that, for a network complexity of N1 and a timetable complexity of T1, a network complexity of N2 would produce a timetable complexity of N4, and a network complexity of N10 would produce a timetable complexity of T2,048.

Thank you for the suggestions, though: much appreciated. Do enjoy playing Simutrans-Experimental!