Structure of platform specific vs non platform specific code

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-09 20:08, Igor wrote:

> In case you are interested in the reasoning for having platform code
> that imports game code Casey explains that in case where you structure
> all platform specific code in functions that other code should call you
> are making a needlessly big interface polluting the API space. For
> example you would need CreateWindow function in such library which games
> would only need to call once at startup; they won't need to create and
> close additional windows during their execution and they don't even need
> to know "Window" is a thing. Also some of that code is so different on
> some platforms that no API can cover it clearly. For example what should
> one expect CreateWindow to do on Android platform.

Then I suggest you have three modules: platform, game and app. The 
platform module doesn't need to know anything about the game module and 
the game module needs to know very little about the platform module. The 
platform module should provide some form of view object where the game 
can render its content. Then it won't matter if the view is a window, 
part of a window or window (or whatever it's called) on Android.

The app module would be responsible to bring everything together. Simple 
example:

module app;

import platform;
import game;

void main()
{
     auto window = CreateWindow();
     auto view = window.view;
     auto game = new Game(view);

     game.start();
}

The view would (most likely) be platform dependent but provide the same 
API across all platforms.

-- 
/Jacob Carlborg