On 3/08/2015 1:51 a.m., Sebastiaan Koppe wrote:
> On Friday, 31 July 2015 at 03:29:59 UTC, Brandon Ragland wrote:

snip

>> People need to get their facts straight. I don't like Minecraft, but
>> by no means in Minecraft some amateur game from 1990s running terribly
>> on a computer.
>
> Compared to real games, it is.

Some of things that goes on in the modding world is truely amazing.
I can't find the tweets about it from @pahimar. But:
For every item/block with a recipe and vanilla items/blocks hardcoded. It'll calculate at the start of runtime an EMC value in EE3. It does it ridiculously fast.

He did an amazing job of optimizing it. I generally believe that we probably couldn't even match it in D.

Unfortunately Vanilla Minecraft is quite a dog still, but getting better slowly. Even with the mass breakages of mods in the mean time.

On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:
> Some of things that goes on in the modding world is truely amazing.
>
> For every item/block with a recipe and vanilla items/blocks hardcoded. It'll calculate at the start of runtime an EMC value in EE3. It does it ridiculously fast.

I understand absolutely nothing about it.

On 3/08/2015 1:35 p.m., Sebastiaan Koppe wrote:
> On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:
>> Some of things that goes on in the modding world is truely amazing.
>>
>> For every item/block with a recipe and vanilla items/blocks hardcoded.
>> It'll calculate at the start of runtime an EMC value in EE3. It does
>> it ridiculously fast.
>
> I understand absolutely nothing about it.

I'll try my best to explain it.

- An item/block may or may not have a crafting recipe, it may have many or uses a non crafting mechanism to create
- There could be 200k-400k+ blocks and items per modded instance
- Each item/block may have an "EMC" value which is 1 .. int.max
- The EMC value is calculated based upon the crafting recipes and all items/blocks that makes it up EMC values
- Vanilla blocks/items have hard coded EMC values
- Optionally other mods items/blocks may be required to have their values hard coded so the calculation can work
- Back in EE2 it was all hard coded
- In EE3 very few are hard coded

The usage of the EMC value doesn't really matter. What does matter is that these calculations occur at the start of runtime. If this was poorly written this would have massive performance problems.

On Monday, 3 August 2015 at 03:28:26 UTC, Rikki Cattermole wrote:
> On 3/08/2015 1:35 p.m., Sebastiaan Koppe wrote:
>> On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:
>>> Some of things that goes on in the modding world is truely amazing.
>>>
>>> For every item/block with a recipe and vanilla items/blocks hardcoded.
>>> It'll calculate at the start of runtime an EMC value in EE3. It does
>>> it ridiculously fast.
>>
>> I understand absolutely nothing about it.
>
> I'll try my best to explain it.
>
> - There could be 200k-400k+ blocks and items per modded instance

I don't understand why there are so many. Once you calculated the EMC for each block -or item-type, you have them all, no?

On 3/08/2015 6:53 p.m., Sebastiaan Koppe wrote:
> On Monday, 3 August 2015 at 03:28:26 UTC, Rikki Cattermole wrote:
>> On 3/08/2015 1:35 p.m., Sebastiaan Koppe wrote:
>>> On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:
>>>> Some of things that goes on in the modding world is truely amazing.
>>>>
>>>> For every item/block with a recipe and vanilla items/blocks hardcoded.
>>>> It'll calculate at the start of runtime an EMC value in EE3. It does
>>>> it ridiculously fast.
>>>
>>> I understand absolutely nothing about it.
>>
>> I'll try my best to explain it.
>>
>> - There could be 200k-400k+ blocks and items per modded instance
>
> I don't understand why there are so many. Once you calculated the EMC
> for each block -or item-type, you have them all, no?

200k-400k does sound a lot, but it really isn't.
There is a 'standard' mod called forge multi part. Basically for every block it adds a rather large amount more. It's at the very least *10 the real number of blocks.
There are other mods that do similar but different things like this.

Here is an old video from Direworld20 that should help you understand[0].

Also keep in mind dependencies between blocks and items for crafting recipes.

For the Agrarian Skies2 mod pack, it has roughly 4*13*499 items/blocks. Based upon what was visible from NEI.

I did have block+item dump here, but ugh too big for NNTP server.

The lists only total 6145 but based upon NEI it would be closer to 25948. So obviously there are many many things not included in the item + block dumps. Things like multiparts are not listed by the looks.
FYI Agrarian Skies is a themed mod pack that was not designed for fanciness so e.g. no extra "cool" blocks. Other packs like Direwolf20 would have much more massive numbers. After all there is a reason why Mojang shifted from a number to identify blocks and items to strings. Mods were using them up a little too much[1].

[0] https://www.youtube.com/watch?v=u9yUr4jmU6s
[1] http://forum.feed-the-beast.com/threads/4096-and-beyond.20774/

On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
> D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games?
>
> For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup?

You should have a look at this engine http://dash.circularstudios.com/

On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
> D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games?

Not an indie game, but Remedy is making Quantum Break using D.

On Tuesday, 4 August 2015 at 18:59:34 UTC, develop32 wrote:
> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>> D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games?
>
> Not an indie game, but Remedy is making Quantum Break using D.

And they are not using the GC.

On 5/08/2015 6:59 a.m., develop32 wrote:
> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>> D is really cool and makes a good candidate for developing a game. Are
>> there any guys out there using D for indie games?
>
> Not an indie game, but Remedy is making Quantum Break using D.

Got a source for that? As I can't find it.

On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
> D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games?
>
> For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup?

After leaving C++ behind for a few years to work in some higher-level languages for job-related coding, I was excited when I stumbled upon D and how it seemed to make for a perfect balance of higher-level language features while still being compilable down to machine code and able to directly interface with the vast sea of awesome open-source game-oriented development libraries that offer up a C/C++ API.

I spent several weeks tearing through the language reference and standard APIs to gain a solid grasp on what was possible with D.  The existence of DUB and the Derelict bindings further made D seem like the perfect solution.

Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D.  Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger.  I should say upfront that this seems to be more gravely affecting OSX than other platforms, but scouring forums and wikis has made it apparent that no platform is completely devoid of obstacles when it comes to functionally debugging D programs.  To a certain extent, one can alternatively diagnose and fix bugs with verbose logging, assertions, and exceptions; but memory related bugs become exponentially more difficult to work through without being able to properly breakpoint, step through execution, and observe all variables in the current scope.

Hopefully the ecosystem of supporting D tools will continue to grow and mature enough to be practical for large scale projects; but until then be prepared to face hurdle after hurdle trying to use D as a complete solution for game development.