960
edits
Difference between revisions of "Platform Limitations"
Jump to navigation
Jump to search
Added some known platform limitations
(Added some known platform limitations) |
|||
| Line 5: | Line 5: | ||
== Compiler limitations == | == Compiler limitations == | ||
=== Old GCC versions === | |||
Some platforms (like [[BeOS]] and [[SymbianOS]](?)) are stuck with versions of the GCC compiler as old as 2.95. Those old versions weren't as standard compliant as the later ones, so while accepting some non-standard constructions, they can also break with correct ones. Sometimes we can also face annoying bugs in the compiler, but we have to workaround them since it's very unlikely those platforms will get an updated compiler. In the end we have to use a subset of C++ that all the compilers we use recognize. [[Buildbot]] is very useful to detect broken compilations after code changes. | |||
== Platform limitations == | == Platform limitations == | ||
=== | === Number of open files === | ||
* The number of files that can be simultaneously opened is limited in Microsoft Visual C++. When a large number of files is opened simultaneously, opening new files yields unexpected results. The most typical side effect is that opening new files or checking for existence of files fails for no reason. The actual error can be viewed using [http://www.cplusplus.com/reference/clibrary/cstdio/perror.html perror] | * The number of files that can be simultaneously opened is limited in Microsoft Visual C++. When a large number of files is opened simultaneously, opening new files yields unexpected results. The most typical side effect is that opening new files or checking for existence of files fails for no reason. The actual error can be viewed using [http://www.cplusplus.com/reference/clibrary/cstdio/perror.html perror] | ||
* This issue is also visible in the [[PlayStation Portable]], which can only have around 10 open files at any given time. | |||
=== Available RAM === | |||
The [[Nintendo DS]] has only 4MB of RAM to run the whole program. Considering the ScummVM executable weights almost 2MB and more features are added to the common code with each release, it leaves little memory for the engines. Memory footprint should be reduced in both: | |||
* binary size: try to avoid hardcoding large static tables, move optional features into conditional blocks so the binary size is reduced when they're disabled, (something about templates?)... | |||
* runtime memory usage: keep an eye on the memory leaks (make periodic runs under valgrind), don't keep in memory objects that will only be used for a small period of time, ... | |||
== Operating system limitations == | == Operating system limitations == | ||