For example, many dev-kits provide very advanced functionality by “hiding” details, such as how tiles work. In reality, however, all computers (which MIDRES supports) have tiles: they are implemented in a (sometimes profoundly) different way, from case to case.

In other words, since the programs that adopt other dev-kits run even where the concept of “tile” does not exist, this implies that the programmer cannot directly write logics that treat tiles for what they are, so with a C code “close” to the machine. This does not imply that, by itself, the result will be inefficient. At least, it doesn't necessarily have to be it in an absolute sense. Surely, it will not be as efficient on all targets as it is the one obtained by adopting the MIDRES library.

This is because the programmer who adopts the MIDRES library can enjoy some advantages on the hardware, linked exclusively to the fact that it is isomorphic. In MIDRES library the tiles are a resource under the complete control of the programmer and not of the library: the library does not need to map them in the same way, and the game can therefore have all possible tiles for that hardware (256, 128, 64, it depends), even in multiple copies.

This is so because, if MIDRES library tried to “standardize” them, it would be an abstraction and one always falls back to a specific implementation of an abstract computer, in this case always equipped with the same tiles mapping, and it would not be isomorphic.

The library also offers functions to define and manipulate the tiles and guarantees that, when they are compiled, they will “automagically” become direct reads/writes in video ram and in the appropriate memory area.

This is due to the fact that it is isomorphic and that is why the client also comes into play with an isomorphic library and that, once a sufficiently valid and efficient software has been created, it will be so wherever it is recompiled.

Move to page OTHER FEATURES OF THE MIDRES LIBRARY.