On Monday, 1 June 2015 at 05:37:39 UTC, weaselcat wrote:
> On Monday, 1 June 2015 at 05:20:27 UTC, Paulo Pinto wrote:
>> On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote:
>>> On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>> On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:
>>>>>
>>>>> On 1 June 2015 at 10:56, ketmar via Digitalmars-d
>>>>> <digitalmars-d@puremagic.com> wrote:
>>>>>>
>>>>>> On Sun, 31 May 2015 09:08:27 +0000, Joakim wrote:
>>>>>>
>>>>>>> Most mobile games are written in C/C++/OpenGL
>>>>>>
>>>>>>
>>>>>> that will fade away soon. it's safe to ignore that in long-time plan.
>>>>>
>>>>>
>>>>> How so? Game dev's aren't moving away from native code any time soon...
>>>>
>>>>
>>>> a large portion of ios, android, and steam games use unity, which outside of
>>>> the core engine uses mono for programming.
>>>
>>> Ah, yeah, but Unity itself is all C code. Every modern game has a
>>> scripting solution, just that Unity has made that interface
>>> front-and-center. Lots of meaty Unity plugins are native too.
>>
>> Since last Unity version, C# is also compiled to native code via IL2CPP.
>
> Only because of mono's license update, it's why they've been using a nearly decade old mono for so long.

No, only because they are too cheap to pay for the work of Xamarin.

I doubt that the amount of money wasted in Danish salaries for writing a .NET native compiler is cheaper than paying for the licenses.

However riding the fame wave is easy to forget how unknown they were before they firstly added Mono to their JavaScript and Boo offerings, followed by porting the engine to Windows.

So I don't really get why Xamarin gets the blame and Unity is portraid as the good guys.

For me they are just a company that got lucky using open source and now doesn't want to pay back.

Xamarin is doing great without their money.

On Monday, 1 June 2015 at 05:45:56 UTC, Paulo Pinto wrote:
> On Monday, 1 June 2015 at 05:37:39 UTC, weaselcat wrote:
>> On Monday, 1 June 2015 at 05:20:27 UTC, Paulo Pinto wrote:
>>> On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote:
>>>> On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
>>>> <digitalmars-d@puremagic.com> wrote:
>>>>> On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:
>>>>>>
>>>>>> On 1 June 2015 at 10:56, ketmar via Digitalmars-d
>>>>>> <digitalmars-d@puremagic.com> wrote:
>>>>>>>
>>>>>>> On Sun, 31 May 2015 09:08:27 +0000, Joakim wrote:
>>>>>>>
>>>>>>>> Most mobile games are written in C/C++/OpenGL
>>>>>>>
>>>>>>>
>>>>>>> that will fade away soon. it's safe to ignore that in long-time plan.
>>>>>>
>>>>>>
>>>>>> How so? Game dev's aren't moving away from native code any time soon...
>>>>>
>>>>>
>>>>> a large portion of ios, android, and steam games use unity, which outside of
>>>>> the core engine uses mono for programming.
>>>>
>>>> Ah, yeah, but Unity itself is all C code. Every modern game has a
>>>> scripting solution, just that Unity has made that interface
>>>> front-and-center. Lots of meaty Unity plugins are native too.
>>>
>>> Since last Unity version, C# is also compiled to native code via IL2CPP.
>>
>> Only because of mono's license update, it's why they've been using a nearly decade old mono for so long.
>
> No, only because they are too cheap to pay for the work of Xamarin.
>
> I doubt that the amount of money wasted in Danish salaries for writing a .NET native compiler is cheaper than paying for the licenses.
AFAIK It's heavily based off of mono 2.0 code, it actually directly links against a lot of mono libraries to supply the CLR(or did, anyways.)
>
> However riding the fame wave is easy to forget how unknown they were before they firstly added Mono to their JavaScript and Boo offerings, followed by porting the engine to Windows.
Boo requires mono ;)
>
> So I don't really get why Xamarin gets the blame and Unity is portraid as the good guys.
>
> For me they are just a company that got lucky using open source and now doesn't want to pay back.
>
> Xamarin is doing great without their money.

I wasn't blaming Xamarin, unity owes a lot of their success to them - mono helped them greatly reduce the barriers of indie gamedev.

On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
>> While C++ programmers should try and avoid the preprocessor as much as possible, sometimes it just isn't possible to do so. There's just no other way to generate code sometimes. I know, I've tried.
>
> In what case is this true? If it is only to avoid some boiler plate then it is not a good excuse, IMO. You can usually avoid macros by restructuring composition (using multiple layers of templates).

I'll take a macro over boilerplate any day of the week and twice on Sundays.

Atila

On Mon, 01 Jun 2015 13:38:28 +1000, Manu via Digitalmars-d wrote:

> On 1 June 2015 at 10:56, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Sun, 31 May 2015 09:08:27 +0000, Joakim wrote:
>>
>>> Most mobile games are written in C/C++/OpenGL
>>
>> that will fade away soon. it's safe to ignore that in long-time plan.
> 
> How so? Game dev's aren't moving away from native code any time soon...

even PC games tend to migrate to Unity. mobile games will stop using home- made engines very soon, as porting it to each platform is simply wasting of time. so there will be old codebases which nobody will convert anyway, and new codebases that using Unity, Cocos or something like it.

so "generating native code for mobile platforms" target can be ignored, it's investement that will take alot of time and efforts with very little benefit.

On Monday, 1 June 2015 at 10:37:31 UTC, ketmar wrote:
> even PC games tend to migrate to Unity. mobile games will stop using home-
> made engines very soon, as porting it to each platform is simply wasting
> of time. so there will be old codebases which nobody will convert anyway,
> and new codebases that using Unity, Cocos or something like it.

I don't know, it is hard to stand out if you build on Unity or Cocos unmodified.

But I think web browsers are slowly moving towards a situation where you soon can make sensible games in webgl + asm.js using home-made engines using "native javascript" (basically javascript targetting LLVM IR) or pnacl (LLVM IR).  So the distinction between native and non-native is getting blurred.

Just take a look at shadertoy and see what people can do in GL shaders that work on the web. And shaders are written to the current hardware if they are to perform well (so "native").

Realtime javascript programming + WebGL quality is going to become more important than native binaries for games if the payment model issues find a solution.

I'd say the payment model that the app-stores provide are more important than distributing native code.

A web-based game has a distinct significant marketing advantage. Click on a web ad and instantly find yourself in a game world (free trial). Anything that takes installation is at a disadvantage. Unfortunately, anything that requires entering credit card info is at a disadvantage too...

> so "generating native code for mobile platforms" target can be ignored,
> it's investement that will take alot of time and efforts with very little
> benefit.

I think the focus will shift from "generating native code for specific hardware" to "generating code that effectively translates to native code for specific hardware". Which roughly is the same deal.

(Most games are scripty, yes, "paper doll", "cartoony 2D" etc…)

"Atila Neves" <atila.neves@gmail.com> writes:

> On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote:
>> On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
>>> While C++ programmers should try and avoid the preprocessor as much as possible, sometimes it just isn't possible to do so. There's just no other way to generate code sometimes. I know, I've tried.
>>
>> In what case is this true? If it is only to avoid some boiler plate then it is not a good excuse, IMO. You can usually avoid macros by restructuring composition (using multiple layers of templates).
>
> I'll take a macro over boilerplate any day of the week and twice on Sundays.

Timely!  I and stack overflow struggled for a couple hours to find an equivalent C++ template for something that was straightforward with a couple macros.

On Monday, 1 June 2015 at 16:09:34 UTC, Dan Olson wrote:
> "Atila Neves" <atila.neves@gmail.com> writes:
>
>> On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote:
>>> On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
>>>> While C++ programmers should try and avoid the preprocessor as much
>>>> as possible, sometimes it just isn't possible to do so. There's
>>>> just no other way to generate code sometimes. I know, I've tried.
>>>
>>> In what case is this true? If it is only to avoid some boiler plate
>>> then it is not a good excuse, IMO. You can usually avoid macros by
>>> restructuring composition (using multiple layers of templates).
>>
>> I'll take a macro over boilerplate any day of the week and twice on
>> Sundays.
>
> Timely!  I and stack overflow struggled for a couple hours to find an
> equivalent C++ template for something that was straightforward with a
> couple macros.

I use macros for stuff like exceptions all the time - e.g.

THROW(MyException, ("This value is wrong: %d", foo));

The macro handles logging the exception, getting and setting the stacktrace on the exception, setting the file and line number of the exception, as well as constructing the string for the exception's message given the arguments - and of course finally throwing it. You _are_ still forced to call format in D (whereas that macro does it for you), but aside from that, the built-in exception stuff does all of that for you by simply throwing a new exception with a message, whereas C++ doesn't even come close. Without a macro, getting all of the information in C++ - and doing it consistently and correctly - would be a big problem.

Yes, macros should be avoided in general, but there are areas where you really don't have much choice, and saying that all macros are unequivocably bad is quite short-sighted. It's when macros are used when they aren't needed that it's a problem.

Coming out of college, I actually believed the dogma that all macros are bad, but experience has shown me that that's just not true. Sure, it would be nice if we had a better solution in C++, but sometimes we just don't.

- Jonathan M Davis

On Monday, 1 June 2015 at 16:09:34 UTC, Dan Olson wrote:
> Timely!  I and stack overflow struggled for a couple hours to find an
> equivalent C++ template for something that was straightforward with a
> couple macros.

…but without an example it is hard to figure out what macros are needed for.

On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:
> I use macros for stuff like exceptions all the time - e.g.
>
> THROW(MyException, ("This value is wrong: %d", foo));

ick! Yes,  if you want stack-trace like information in release-builds you need to use the macro system, but that's because __FILE__ and __LINE__ are macros! That's a C deficiency.   Usually your debugger gets you what you are looking for without this in debug builds, right?

And your THROW macro does not help when you receive exceptions from libraries.

(I don't use exceptions in C++)

> even come close. Without a macro, getting all of the information in C++ - and doing it consistently and correctly - would be a big problem.

You would need a core dump ;^), but consistently… well, if you don't use libraries.

> Yes, macros should be avoided in general, but there are areas where you really don't have much choice, and saying that all macros are unequivocably bad is quite short-sighted. It's when macros are used when they aren't needed that it's a problem.

It's a problem if you need it. It is almost always used to address language design flaws or other structural flaws.

> Coming out of college, I actually believed the dogma that all macros are bad, but experience has shown me that that's just not true. Sure, it would be nice if we had a better solution in C++, but sometimes we just don't.

Yet, some of programmers don't actually use it anymore. In C you need it, it is an integral part of the language design. In C++ you can avoid it for the most part or replace it with external code-gen ( + makefile ).

(I sometimes use macros for constants like π out of habit, but I consider it a bad habit :-P.)

On Monday, 1 June 2015 at 17:17:18 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:
>> I use macros for stuff like exceptions all the time - e.g.
>>
>> THROW(MyException, ("This value is wrong: %d", foo));
>
> ick! Yes,  if you want stack-trace like information in release-builds you need to use the macro system, but that's because __FILE__ and __LINE__ are macros! That's a C deficiency.

The SAD thing here is that C++ actually do expensive stack introspection to unwind the stack based on return address, so the C++ runtime _could_ have been designed to look up call site information down the stack at runtime for "low additional cost" even with separate compilation, just like a high level language with stack introspection (in Python: "inspect.stack()[1][0].f_lineno").

Not saying it is a good idea for a  system level language, but there is no technical reason to have macro warts like __LINE__ since the full C++ runtime already is bloated. And they could have gotten around it with by adding compile time introspection to the language too.

I'd say C has embraced macros for good reasons, as a minimalistic language design strategy  (newest C version using it for generics), but C++ has no longer an excuse for providing it.