D game development: a call to action

[Johannes Pfau via Digitalmars-d]

Am Thu, 18 Dec 2014 00:58:02 +0100
schrieb Joseph Rushton Wakeling via Digitalmars-d
<digitalmars-d at puremagic.com>:

> On 17/12/14 08:53, Manu via Digitalmars-d wrote:
> > Errors should be fine... I imagine assert is an intrinsic defined by
> > the backends(?).
> 
> TBH I think it was a daft question.  An Error thrown by assert
> failure ought to bring down the whole program anyway, and probably
> for a game you'd use the -release flag to strip out asserts for
> release builds.
> 
> > In Fuji, I register an assert handler (core.exception.assertHandler
> > = myAssert) which is implemented by Fuji and is portable.
> >
> > Oh yeah, TLS, that's another one that tends to require special
> > treatment.
> >
> > Basically, the language will produce working code for all platforms
> > I've tried if you avoid: exceptions, TLS, GC.
> > I'm fine with this, that's how I write code anyway. In the case of
> > Fuji, there are Fuji API's to do most of the low-level
> > druntime/phobos stuff that might not be supported (threads,
> > synchronisation, allocation, etc).
> 
> Sounds interesting -- can you clarify the issue with TLS?  (Apologies
> if you've already explained this in earlier discussions, feel free to
> tell me to just search the forums if so;-)

Native TLS can allocate in some cases. For example if you access the TLS
block of a library for the first time in a thread, it might allocate
this block. Not sure if there are any other issues.
Or maybe he's referring to the fact that some platforms (Android, I
guess most of the consoles as well) don't support TLS at all.
GCC Emulated TLS is slow, allocates and doesn't work with the GC. DMD
emulated TLS doesn't work with shared libraries afaik.

TLS constructors are also problematic, although not necessarily for
games. But they complicate shared library loading a lot, some special
cases are almost impossible to implement (Running a TLS ctor of a
dynamically loaded library in already running threads).