Structure of platform specific vs non platform specific code

rikki cattermole via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue May 9 21:12:37 PDT 2017


On 09/05/2017 7:08 PM, Igor wrote:
> On Tuesday, 9 May 2017 at 15:37:44 UTC, Stefan Koch wrote:
>> On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote:
>>> On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote:
>>>> Hi,
>>>>
>>>> I am following Casey Muratori's Handmade Hero and writing it in DLang.
>>>
>>> This sounds very interesting.  Maybe make it a public github project?
>>
>> It can only accessible for those who bought the game.
>
> That is right. If I manage to keep it up at least a bit more I will put
> it at https://github.com/HandmadeHero but that is only accessible for
> those who buy the game.
>
> Also thanks for the suggestions. I will definitely use it for
> platformServices part.
>
> 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.

A render point[0] versus window:

[0] 
https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/rendering.d
[1] 
https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/window/defs.d#L17


More information about the Digitalmars-d-learn mailing list