There are differences in languages, some are stronger in one area, and less strong in another. C and C++ is one the most flexible languages, as the language doesn't limit you. At the down-side, it doesn't help you much either.MagicBuzz wrote:In fact "anything" an be done with "any" langage".
The problem isn't a matter of langage nor even a problem that writting and maintaining more complex code in a langage than with another one.
In the end however, the differences are minor. If you know your way around in a language, you can express pretty much express anything you want, with a varying degree of complexity. (If a language supports a feature that you need out of the box, it's a great language. If it doesn't support a feature you need, you first have to build a layer on top of the language to add the feature, then you can express it on top of that layer. Building that layer may be a complex problem in itself though.)
It's much like natural languages. Different languages have different vocabularies, but in the end, you can express all notions in natural language, using more or less words.
Sort of.MagicBuzz wrote:The problem is a matter of "how it's done now".
The current solution is the current solution because it's in a sweet spot of the requirements. In other words, it works well, it is optimal in some way.
Much of the code is pretty well tuned for its function in OpenTTD. For example, the A* path-finder in the code is not a generic A* implementation that you find at the Internet. It once started as a generic implementation, and was subsequently extended and refined to get better performance for eg routing trains, ie all the slack has been taken out, so you can have more trains.
This means that it's very hard to beat the current solution, or to keep the same performance, but add more functionality (like having multiple layers). More functionality implies you have to do more work (namely everything that's extra), which will cost CPU time. That CPU time is thus not available for the old functionality, ie you loose performance wrt to the old functionality.
The dominant data structure IS the map. Everything is connected to it. Add a few CPU cycles to the access, and you will immediately see a drop in performance, as it's accessed zillions times each second.MagicBuzz wrote:The core of OTTD is about it's way to store and manage the map.
We can change the way it's coded, but this implies many changed in all features of the program.
You can perhaps hide most of the changes, there is a set of functions that abstracts the map structure. On the other hand, that abstraction is very very thin to avoid performance losses.
You cannot get more CPU cycles than you have, so at some point you have to decide whether a feature is worth the cost in other areas of the game.MagicBuzz wrote:And for some benefits it may bring some enormous limitations.
You do, until you invent a language that has free infinitely many CPU cycles.MagicBuzz wrote:You may have the same problems with any langage.
That won't happen with the current computer technology.