On Sunday, 1 November 2015 at 02:35:49 UTC, Manu wrote:
> In terms of what I've used commercially, Fuji is the platform abstraction and core concept implementation that lives below the layer that the high-level interacts with. Editors and tooling (I feel this is what you're talking about when you start using words like 'Unity' or 'Unreal') typically impose particular design decisions wrt scene-graph, physics implementations, etc. The goal of Fuji is not to be Unity, it's intended to be the platform which you could build Unity above, and all commercial engines I've had contact with do have such a layer.
>
> I'm not sure if that answers your question.
> For what it's intended to be, Fuji is quite comprehensive. As a
> full-game-engine a-la Unity/Unreal, it needs all the high-level stuff
> built on top. The reason I didn't touch that, is because that layer is
> extremely subjective, and there are no right/wrong answers there. I
> also change my mind on that stuff every year or 2. Whereas the lower
> level is a lot less subjective, and it's been more-or-less constant
> since I started Fuji in 2003. I still wouldn't do it differently
> today, although I have a lot more experience and console generations
> to draw wisdom from.

Nonono, you're fine, what I'm looking for is a lightweight engine that ISN'T like Unity or Unreal and the sophisticated nature of their tools. Often, their engine design decisions back me into a corner when it comes to how I want to organize my own project, and they're oftentimes overkill.

About the only thing I would want to keep from those two monster engines is some live compilation feature where changes in source, assets, or UI scripting are immediately apparent in-game. But that takes a massive amount of work, I understand if it's not a priority. You have to port the thing to D in the first place, a significant undertaking in and of itself.

What you have seems to be great, so I'll follow it eagerly.

On 1 November 2015 at 16:45, Nerve via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> About the only thing I would want to keep from those two monster engines is some live compilation feature where changes in source, assets, or UI scripting are immediately apparent in-game. But that takes a massive amount of work, I understand if it's not a priority. You have to port the thing to D in the first place, a significant undertaking in and of itself.

I actually wrote that exact thing at Remedy (for Quantum Break) which runtime compiles D code, and hot-swaps the new code into the live data... if only I could liberate the source >_<

On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
> I actually wrote that exact thing at Remedy (for Quantum Break) which runtime compiles D code, and hot-swaps the new code into the live data... if only I could liberate the source >_<

Wow, I had no idea D was being used for such a massive project, especially on a current-gen console. If I might ask before taking the thread too far off-topic, what tools did you guys use to maintain productivity and organization in such a huge project? (Debuggers, editors, IDEs, etc.)

On 1 November 2015 at 17:43, Nerve via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
>>
>> I actually wrote that exact thing at Remedy (for Quantum Break) which runtime compiles D code, and hot-swaps the new code into the live data... if only I could liberate the source >_<
>
>
> Wow, I had no idea D was being used for such a massive project, especially on a current-gen console. If I might ask before taking the thread too far off-topic, what tools did you guys use to maintain productivity and organization in such a huge project? (Debuggers, editors, IDEs, etc.)

Visual Studio. I'm not aware of any practical alternatives on any platform >_<
I really, really wish there was competition in the IDE space. We're
all sick to death of MS and Visual Studio, we'd all jump ship in an
instant, but there's just nothing that comes close.

On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
> I actually wrote that exact thing at Remedy (for Quantum Break) which runtime compiles D code, and hot-swaps the new code into the live data... if only I could liberate the source >_<

Well, Remedy owns the source, but they can't own your knowledge. You could write something up explaining how it works and let someone else write something from that.

On 01/11/15 08:30, Manu via Digitalmars-d wrote:
> I actually wrote that exact thing at Remedy (for Quantum Break) which
> runtime compiles D code, and hot-swaps the new code into the live
> data... if only I could liberate the source >_<

Wow.  That sounds like it could have uses far beyond games -- I'm thinking Erlang-style hot-swapping of components of super-high-uptime (web) services ...

On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
> If people find this to be an interesting project, and I do take some
> time to do this port, what I'd really love is to work together with
> some of the niche platform support guys and use it to stress test
> toolchains for various platforms. I'd also like help from guys like
> Johannes to make regularly released builds of some console
> cross-compilers available so that it can keep on building.
> The CI of this project for those platforms would more-or-less verify
> that the toolchains and druntime+friends are working.

Sounds great, would make a good stress test for Android and maybe even a base for D games for Android.  See my post in the announce forum earlier today about Android progress.

Am Sun, 1 Nov 2015 11:33:21 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> So, I just wanted to put this idea out there, and see what other people make of it.
> 
> I have this game engine (https://github.com/TurkeyMan/fuji), it's
> lived for about 12 years now (first commit in 2004, and it existed
> prior before source control). I called it 'Fuji' (a modest, yet
> pleasing and attractive mountain). It supports (or has supported)
> shit-loads of platforms; I'm a game-engine dev for life, and I have a
> fetish for portability, and niche platform support.
> Needless to say, it has had a LOT of time and energy put into it, and
> I would say it's infrastructurally better than most proprietary
> commercial game-engines I've worked with (although there are some
> missing features, I just implement what I need), mainly in that I have
> the luxury to aggressively refactor when design decisions turned out
> to be mistakes, and no deadlines to meet.
> It is a very good example of what we use in real-world AAA gamedev.
> 
> It's written in C, obviously. It has comprehensive bindings for D, which I'm pretty sure I'm the only one that's ever used, and I use it in all my modern D projects.
> 
> Anyway. I'm spending less time on hobby game-dev these days, obviously I'm not going to make the worlds next big game engine... Hobbyists will just use Unity. I'm not quite sure what to do with it.
> 
> I have been thinking about full-scale porting to D, and it would serve there is a massive-scale long-term codebase, with portability as it's primary objective, and I don't know of another project quite like this in the D ecosystem? Also, perhaps D gamedevs might be interested in an all-D game engine they can use and hack on.
> 
> So, when I think on that, I consider what would be lost... and the answer is; almost all platforms. But this is something that can be addressed.
> 
> If people find this to be an interesting project, and I do take some
> time to do this port, what I'd really love is to work together with
> some of the niche platform support guys and use it to stress test
> toolchains for various platforms. I'd also like help from guys like
> Johannes to make regularly released builds of some console
> cross-compilers available so that it can keep on building.
> The CI of this project for those platforms would more-or-less verify
> that the toolchains and druntime+friends are working.

Sounds like a great idea!

I can certainly build the GDC toolchains*. But I guess the first thing you'll need if you want to use Dreamcast, NDS and other low memory systems is a @nogc druntime port? I had a look at this some time ago and there's some work to be done until we can build a druntime completely without GC.



*
or better: also provide build scripts. We now use docker.io containers
to build the binary GDC toolchains. Building a toolchain with the latest
GDC version is as simple as running one docker command:

docker run
-v ~/shared-dir/:/home/build/shared #results will be saved here
-t jpf91/build-gdc /usr/bin/build-gdc build
--toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32

It should be easy enough to add support for console toolchain build scripts.

Docs:
http://build-gdc.readthedocs.org/en/latest/
Sources:
https://github.com/D-Programming-GDC/build-gdc
https://github.com/D-Programming-GDC/build-gdc-config
https://github.com/D-Programming-GDC/build-gdc-docker

On 2015-11-01 02:33, Manu via Digitalmars-d wrote:

> I have been thinking about full-scale porting to D

You could enhance DStep [1] to handle complete source code and not only headers.

[1] https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg

On 2 November 2015 at 01:50, Jack Stouffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
>>
>> I actually wrote that exact thing at Remedy (for Quantum Break) which runtime compiles D code, and hot-swaps the new code into the live data... if only I could liberate the source >_<
>
>
> Well, Remedy owns the source, but they can't own your knowledge. You could write something up explaining how it works and let someone else write something from that.

It's not that. We all felt happy to release the tech open-source (at the time I left), which may have changed since, but I have no reason to believe it has. It's just taking the time to separate the tech from any proprietary stuff.