On 12/13/2014 11:39 PM, Manu via Digitalmars-d wrote:
> On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote:
>>>
>>> my engine: https://github.com/TurkeyMan/fuji
>>
>>
>> Please set fuji up at http://code.dlang.org !
>
> It's totally incompatible with dub. How does code.dlang.org deal with
> foreign build systems?
> It's very complex to package, since it supports so many optional
> features, platforms, and various multimedia API's for each platform.
>
> I use premake to create projects/makefiles, which I've been
> maintaining D support for years.
> The typical way is to just make the engine repo a submodule and extend
> the buildsystem to the host app (FeedBack is the best example).

The thing is, merely having the code there on github and referring to it now and then in the n.g. will result in likely:

    0

users. People are going to look for code like yours on code.dlang.org, and if it isn't there, they will assume it does not exist.

"Build it and they will come" is a stupid hollywood myth. It will never happen. So many excellent D projects have died because the creators did:

    0

promotion, and nobody used it. Please do not let this happen to your work!

I recommend:

1. find a way to make it work on dub. Ask for help. (Martin and Dmitry have been graciously helping me get my code up on dub.)

2. write article(s) about it, post them on your blog site, and ask someone to link 'em to Reddit.

3. announce it on gamedev.net

4. talk about it everywhere on the internet where game devs hang out

5. submit a presentation proposal about it for Dconf 2015, and every other programming conference. How about YOW 2015, it's even in Australia!

P.S. This applies to everyone writing open source D projects.

On Sun, 14 Dec 2014 17:45:06 +1000
Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> >> Hard to describe... just the sort you'd find in a big commercial game. Perhaps I could say something like, highly optimised and purpose specific, as opposed to generalised and flexible/object oriented.
> > i've seen such code. it's... ah, it's terrible. unmaintainable. and becomes garbage just when the next 3d-accel or processor is out. sure, nobody cares as it is sold million times already and everyone is working on another pile of shit now. libraries? code reusability? design? architecture? screw that! i moved out of that industry 'cause i couldn't take it anymore. they almost ruined my programming skills.
> >
> > that's why i was so wondered.
> 
> Where did you work? It sounds like you had a bad experience. I've worked in a few such environments, I can say we only got the balance right once.
ah, that was... "outhouse team", i think. we were not officialy part of the main firm, but were working on their titles. it doesn't really matter, i don't know what's going on there now, so let it be "the nameless one". ;-)

maybe i was just unlucky. i've dreamt of creating videogames from my childhood and was very excited to work in "real videogaming industry". that was more than decade ago, though, but i don't believe that things are changed radically since then. i was talking with some old mates recently (they are still making videogames) and was really wondered: they know alot about overhead of memory allocation, processor caches, videodriver glitches, but failing at basic CS things, such as "why crc32 isn't good function for hashing?". they know that crc32 should not be used in hashtables, but for what reason... it's mystery.

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

I did some googling on your game engine:

  http://fujiengine.org/

Good, but needs more info on why someone should invest time learning it.

  https://code.google.com/p/fuji/wiki/Platforms

Not so good. Says it's "Not maintained/out of date".

That's about it for its presence on the intertoobs.


Also, it's variously called "Mount Fuji Engine", "Fuji Engine", "Mt Fuji Engine" and just "Fuji". Need to pick one moniker for it and use that consistently everywhere in order to tie your brand together. Need a logo to tie it all together.

Sorry to be so blunt about this, but I want you to succeed!

On 14 December 2014 at 17:55, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/13/2014 11:39 PM, Manu via Digitalmars-d wrote:
>>
>> On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote:
>>>>
>>>>
>>>> my engine: https://github.com/TurkeyMan/fuji
>>>
>>>
>>>
>>> Please set fuji up at http://code.dlang.org !
>>
>>
>> It's totally incompatible with dub. How does code.dlang.org deal with
>> foreign build systems?
>> It's very complex to package, since it supports so many optional
>> features, platforms, and various multimedia API's for each platform.
>>
>> I use premake to create projects/makefiles, which I've been
>> maintaining D support for years.
>> The typical way is to just make the engine repo a submodule and extend
>> the buildsystem to the host app (FeedBack is the best example).
>
>
> The thing is, merely having the code there on github and referring to it now and then in the n.g. will result in likely:
>
>     0
>
> users.

That's fine, I'm not selling a product or anything.
It's for personal use... but I'm perfectly happy for other people to
take an interest if they want a professional engine dev helping on
their project, and portability to a very wide range of systems.


> People are going to look for code like yours on code.dlang.org, and if it isn't there, they will assume it does not exist.

Well it's not really D code, it just has quite comprehensive support
for D. I've taken a lot of time with the bindings, and making sure D
game projects can effectively be developed against my engine.
I still consider the D bindings experimental though, and I keep tweaking them ;)

I can't make D engine code until D is supported on the menagerie of console platforms that I support. We need better bare-metal support and more working toolchains.


> "Build it and they will come" is a stupid hollywood myth. It will never happen. So many excellent D projects have died because the creators did:
>
>     0
>
> promotion, and nobody used it. Please do not let this happen to your work!
>
> I recommend:
>
> 1. find a way to make it work on dub. Ask for help. (Martin and Dmitry have been graciously helping me get my code up on dub.)

Trouble with this is, I'm not interested in dub.
An exclusive language-specific build ecosystem is of absolutely no use to me!

If I'm mistaken about dub though and I could theoretically somehow make this work, I'm certainly willing to work with anyone who knows better than me how to get it working?


> 2. write article(s) about it, post them on your blog site, and ask someone
> to link 'em to Reddit.
>
> 3. announce it on gamedev.net
>
> 4. talk about it everywhere on the internet where game devs hang out

These are all good ideas, but I'm not really actually pimping a
project here. I'm not sure it's a project that I'll ever consider
'finished'.
It's had 12 years of work, and it's pretty robust and capable, but I
just don't have the time to finish/polish off all the stuff I want to.

I tend to work in a reactionary manner to emergent requirements :/
I am super happy for those requirements to be someone elses
requirements though, and I'm all good to give some of my time to help
get other peoples cool projects running well.


> 5. submit a presentation proposal about it for Dconf 2015, and every other programming conference. How about YOW 2015, it's even in Australia!
>
> P.S. This applies to everyone writing open source D projects.

Maybe one day I will, I like that idea, but I don't think that day is particularly soon with this project. I need to give it more undivided attention to get it to that state.

@manu

I'm a little confused.. Looking through your Fuji/Source/Drivers folder, I see folders for IPhone and Android, among others... does your engine actually run on these platforms?

I was under the impression that D could not compile to those targets yet.

Actually, iOS and Android both have x86 emulators don't they?

On Mon, 15 Dec 2014 23:40:43 +0000
bitwise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> @manu
> 
> I'm a little confused.. Looking through your Fuji/Source/Drivers folder, I see folders for IPhone and Android, among others... does your engine actually run on these platforms?
> 
> I was under the impression that D could not compile to those targets yet.

Fiji is not written in D, but it has extensive D API.

On Sunday, 14 December 2014 at 00:30:22 UTC, Joel wrote:
> I'm using Windows. I get this error trying to compile the demo on DGame.
>
> C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\build>dmd build.d
> Using the Digital Mars DMD compiler.
>
> C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\build>build.exe
> Assume 'C:\jpro\dpro2\OtherPeoples\derelict' as derelict path.
> Verify...
>
> Building all packages.
>
> Building Dgame/Audio
>
> ..\Audio\all.d
> ..\Audio\Internal\core.d
> ..\Audio\Listener.d
> ..\Audio\Sound.d
> ..\Audio\SoundFile.d
> ..\Audio\VorbisFile.d
> ..\Audio\WaveFile.d
>
> dmd -lib -O -release -inline -wi -of..\lib\Release/DgameAudio.lib
>  ..\Audio\all.
> d ..\Audio\Internal\core.d ..\Audio\Listener.d ..\Audio\Sound.d ..\Audio\SoundFi
> le.d ..\Audio\VorbisFile.d ..\Audio\WaveFile.d -IC:\jpro\dpro2\OtherPeoples -I..
> /../
> ..\Audio\Internal\core.d(32): Error: module Log is in file 'Dgame\Internal\Log.d
> ' which cannot be read
> import path[0] = C:\jpro\dpro2\OtherPeoples
> import path[1] = ../../
> import path[2] = C:\jpro\dmd2\windows\bin\..\..\src\phobos
> import path[3] = C:\jpro\dmd2\windows\bin\..\..\src\druntime\import
> import path[4] = C:\jpro\dmd2\windows\bin\..\import
> import path[5] = C:\jpro\dmd2\windows\bin\..\..\windows\import\gtkd\src
>
> Build Failed!

It seems, Dgame is searching for a path which does not exists
('Dgame/Internal/Log.d'). You should set the path where Dgame
lies to the global PATH (assuming you're using Windows), (e.g. if
it is C:/Foo/Bar/Dgame set 'C:/Foo/Bar/' into PATH). Then Dgame
should be able to find 'Dgame/Internal/Log.d'.
I havent maintained Dgame a long time (since I left D), maybe I
will find some time in the next year. ;)
Sorry for your trouble.

On 16 December 2014 at 09:40, bitwise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> @manu
>
> I'm a little confused.. Looking through your Fuji/Source/Drivers folder, I see folders for IPhone and Android, among others... does your engine actually run on these platforms?
>
> I was under the impression that D could not compile to those targets yet.

You'll notice that the engine code is not D code...
Most of those platforms run fine, although some are out of date. I
only tend to maintain the ones I'm actively using, some needs some
updates, but I'm good at that, and it's nice to dig out the consoles
from time to time to get them up to latest.

D will work on most of those platforms just fine if you abandon the GC
and exception handler. PS2 is probably the only platform that will
never work.
GC and exceptions typically require druntime port work.

> 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? One of my main interests in D is the reflection system for runtime script-tweaking and auto-serialization.

  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.