Open main menu

Platform Limitations

Revision as of 09:00, 11 April 2011 by Fingolfin (talk | contribs) (→‎Platform Limitations: Change Portability Guide link to Coding Conventions)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Platform Limitations

This page contains known limitations and problems of the various compilers that ScummVM can be build with, as well as limitations and problems of the several platforms and operating systems that ScummVM runs under. Note that this page is far from being complete.

You may also want to take a look at our Coding Conventions for some general portability hints.

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

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 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