Am Thu, 18 Dec 2014 00:58:02 +0100
schrieb Joseph Rushton Wakeling via Digitalmars-d
<digitalmars-d@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).

On 18 December 2014 at 01:19, bitwise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 16 December 2014 at 15:39:06 UTC, bitwise wrote:
>>
>>
>>> You'll notice that the engine code is not D code...
>>
>>
>> Hmm... Indeed.. I just assumed when I saw Walter get all excited ;)
>>
>>
>>> D will work on most of those platforms just fine if you abandon the GC and exception handler.
>>
>>
>> Unfortunately, I don't know D-compiler/runtime well enough to actually try to get this to work, so I'll have to wait for an official port =/
>>
>>   Just out of curiosity though, what do you use for a level editor?

I usually use 3dsmax/blender for scene layout, but there is some
turbulence in that area as I often consider other options.
Otherwise I often use Lua for scripting things and various descriptors.

Scene management isn't really baked into Fuji. It's usually highly game-specific, so I don't like to insist on scene management strategy in the engine.


>> One of my main interests in D is the reflection system for runtime script-tweaking and auto-serialization.

Reflection is one of the key reasons that D will appeal to gamedevs. I've had good success. I made some comments about this in my dconf lecture wrt Remedy's implementation.


>> I have an engine of my own, but it's development slowly ground to a halt as I got fed up trying to achieve all the features I wanted using C++. Lately, I've been learning D and starting to look into porting it.

I'd be apprehensive to write something like an engine library in any
style other than extern(C) functions and opaque types.
But I'm obsessed with portability, and I like the idea that a large
and ambitious project like a game engine should be able to front-end
with any language.

Fortunately, D makes it really easy to wrap up a low-level engine library API for convenient front-end use.


> ^^^
>
> @manu I think my question got barried...

Sorry >_<

On 18 December 2014 at 02:18, CraigDillabaugh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 17 December 2014 at 01:28:55 UTC, Manu via Digitalmars-d wrote:
>>
>> The average gamer today is aged 30.
>> I for one haven't gotten any money from my mum for games recently...
>>
> Christmas is right around the corner ... you should reminder her :o)

:P

On 18 December 2014 at 09:58, Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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.

This is all true :)


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

Just that it depends on threading and synchronisation features in druntime, which probably isn't implemented for arbitrary console platforms ;)

On 18 December 2014 at 21:31, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Thu, 18 Dec 2014 00:58:02 +0100
> schrieb Joseph Rushton Wakeling via Digitalmars-d
> <digitalmars-d@puremagic.com>:
>
> 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).

Fortunately, most consoles don't usually have shared libraries... which eliminates one major source of problems ;)

On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote:
>> I find a much bigger problem is tendency for some programmers to
>> commit over-abstraction, sacrificing heaps of efficiency/performance
>> in the process. Most open-source engines are this kind, and will never
>> release a AAA game in a competitive market.
> ah, that's the other end of the spectrum (and my own problem too ;-).
> i'm still searching for good heuristic that will tell me when i should
> stop abstracting and just write the damn thing. ;-)

Programming is a wicked problem; you only know how to do it after you done it. So my suggestion is to just write the damn thing, and then rewrite the whole thing if it bugs you too much. Essentially a lot of rinse-and-repeat.

I always do refactoring manually, so I developed a nack for knowing how to write quick code that is easy to refactor.

Ofcourse having clients screaming in your neck helps alot too :)

On Thu, Dec 18, 2014 at 05:33:24PM +0000, Sebastiaan Koppe via Digitalmars-d wrote:
> On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote:
> >>I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market.
> >ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-)
> 
> Programming is a wicked problem; you only know how to do it after you done it. So my suggestion is to just write the damn thing, and then rewrite the whole thing if it bugs you too much. Essentially a lot of rinse-and-repeat.
> 
> I always do refactoring manually, so I developed a nack for knowing how to write quick code that is easy to refactor.
> 
> Ofcourse having clients screaming in your neck helps alot too :)

IME, starting out with abstraction rarely works well. If you're a one-man team, you'll never finish abstracting; if you're a multi-person team, the whole thing will be so over-engineered, baroque, and inefficient, that by the time you're halfway through it you already feel like rewriting it (again).

What works best IME is to just have a quick initial design to guide you (don't worry too much about abstracting it to the ideal, just have enough overall target items to set the direction so that you aren't getting yourself into the forest, and so that you have a rough high-level overview of how the whole thing is gonna fit together), then start coding. Most of the abstractions will come from refactoring, which should be done frequently. Abstractions derived in this way tend to be far more effective, because they will arise from actual usage patterns in your code, rather than some ivory-tower idealistic theoretically-beautiful model that will either never get implemented or is so far removed from reality that it's completely impractical and doesn't work well in practice.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.

On 19 December 2014 at 03:44, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thu, Dec 18, 2014 at 05:33:24PM +0000, Sebastiaan Koppe via Digitalmars-d wrote:
>> On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote:
>> >>I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market.
>> >ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-)
>>
>> Programming is a wicked problem; you only know how to do it after you done it. So my suggestion is to just write the damn thing, and then rewrite the whole thing if it bugs you too much. Essentially a lot of rinse-and-repeat.
>>
>> I always do refactoring manually, so I developed a nack for knowing how to write quick code that is easy to refactor.
>>
>> Ofcourse having clients screaming in your neck helps alot too :)
>
> IME, starting out with abstraction rarely works well. If you're a one-man team, you'll never finish abstracting; if you're a multi-person team, the whole thing will be so over-engineered, baroque, and inefficient, that by the time you're halfway through it you already feel like rewriting it (again).
>
> What works best IME is to just have a quick initial design to guide you (don't worry too much about abstracting it to the ideal, just have enough overall target items to set the direction so that you aren't getting yourself into the forest, and so that you have a rough high-level overview of how the whole thing is gonna fit together), then start coding. Most of the abstractions will come from refactoring, which should be done frequently. Abstractions derived in this way tend to be far more effective, because they will arise from actual usage patterns in your code, rather than some ivory-tower idealistic theoretically-beautiful model that will either never get implemented or is so far removed from reality that it's completely impractical and doesn't work well in practice.

I agree.

My rule for abstraction is to apply it as minimally as possible to avoid any platform-specific api being called from front-end code. That should be a good initial target. Further refinement will reveal it's self in practise, in the way that you say.