On 2012-10-16 17:19, Manu wrote:

> What about alsa/pulse/oss, linux input?
> I presume OSX has it's own variants of each of these things.

Yes, it has it's own variants. Although I have no experience with these frameworks.

> Indeed, but does that involve .m files? :)

Yes, it's possible do it in D as well. I see that Fuji is written in C++, so your choices are: Objective-C, D or Objective-C++. Objective-C++ is basically Objective-C and C++ in the same source file. But it's not possible to mix the object models, i.e. a C++ class cannot inherit from an Objective-C class, or the other way around.

Here's an Objective-C - D bridge I've made, it has some documentation of how to interact with Objective-C from another language:

http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals

> I'll do it with you/do most of it myself, I just need someone to test
> it, and give me OSX advice.

Ok, I'll see. Then it shouldn't be any problems.

-- 
/Jacob Carlborg

On 2012-10-16 18:39, Manu wrote:

> Wanna jump on IRC, or some IM? googletalk?

Sure, I'll be in the D IRC channel with the alias "doob".

-- 
/Jacob Carlborg

On 16 October 2012 20:13, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-16 18:39, Manu wrote:
>
>  Wanna jump on IRC, or some IM? googletalk?
>>
>
> Sure, I'll be in the D IRC channel with the alias "doob".


Cool, I'm idling in there.

I'm just going to throw it out there that you don't actually need to touch Objective-C at all. Cocoa/Foundation/all those Objective-C interfaces sit on top of something known as Core Foundation, which are C APIs. The pointers used by Core Foundation can generally be used as Objective-C objects of the same type as well.

I don't actually have my Mac over from Australia yet to whip up some code examples, or even port Fuji myself. But needless to say this is the (free download) book I've been using as reference:

http://www.pangeasoft.net/book/buy.html

It would be handy to have a D binding to all the Core- libraries on OSX. I might do that myself when I get my Mac if such a binding doesn't already exist. The book should be equally applicable for iOS as well, but last time I was in iOS land I was still a newbie to the whole OSX programming thing.

On 2012-10-16 19:57, Ethan wrote:
> I'm just going to throw it out there that you don't actually need to
> touch Objective-C at all. Cocoa/Foundation/all those Objective-C
> interfaces sit on top of something known as Core Foundation, which are C
> APIs. The pointers used by Core Foundation can generally be used as
> Objective-C objects of the same type as well.

That's not entirely correct. Most of the types in Core Foundation are a toll free bridge to the corresponding Objective-C types in the Foundation framework. But all the GUI related classes, i.e. AppKit, are not available in the same way.

> It would be handy to have a D binding to all the Core- libraries on OSX.
> I might do that myself when I get my Mac if such a binding doesn't
> already exist. The book should be equally applicable for iOS as well,
> but last time I was in iOS land I was still a newbie to the whole OSX
> programming thing.

If you're going to write GUI applications on Mac OS X you need to interact with the Objective-C frameworks. The reason for this is that, as stated above, AppKit is only available from Objective-C and you really need to be able to create your own Objective-C classes and subclasses.

There are two ways to interact with Objective-C

* Create an Objective-C/D bridge
* Make D binary compilable with Objective-C

The Objective-C/D bridge would use the Objective-C runtime functions defined in C to interact with Objective-C. Every time an object is passed over the bridge it needs to be encapsulated or de-encapsulated. Another problem is the code/template bloat. A Hello World application will be around 60MB in size. This has already been done:

http://www.dsource.org/projects/dstep

The other approach would be to make D binary compaitable with Objective-C, that is, provide extern (Objective-C) declarations. This would generate basically the same code as the Objective-C compiler would, but with the nice syntax of D instead of the horrible syntax that Objective-C is. This would also allow you do create bindings to Objective-C classes, methods and functions just as with C.

The problem with this approach, it's a lot of work to modify the compiler. But that has already been done as well:

http://michelf.ca/projects/d-objc/

This fork of DMD isn't ready yet (there's an alpha available) and there hasn't been any changes made in over a year. If I recall correctly, Michel Fortin said he hasn't got the time now to work on this. It also the problem with always playing catchup with the upstream version of DMD.

-- 
/Jacob Carlborg

On 17 October 2012 09:35, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-16 19:57, Ethan wrote:
>
>> I'm just going to throw it out there that you don't actually need to touch Objective-C at all. Cocoa/Foundation/all those Objective-C interfaces sit on top of something known as Core Foundation, which are C APIs. The pointers used by Core Foundation can generally be used as Objective-C objects of the same type as well.
>>
>
> That's not entirely correct. Most of the types in Core Foundation are a toll free bridge to the corresponding Objective-C types in the Foundation framework. But all the GUI related classes, i.e. AppKit, are not available in the same way.
>
>
>  It would be handy to have a D binding to all the Core- libraries on OSX.
>> I might do that myself when I get my Mac if such a binding doesn't already exist. The book should be equally applicable for iOS as well, but last time I was in iOS land I was still a newbie to the whole OSX programming thing.
>>
>
> If you're going to write GUI applications on Mac OS X you need to interact with the Objective-C frameworks. The reason for this is that, as stated above, AppKit is only available from Objective-C and you really need to be able to create your own Objective-C classes and subclasses.
>
> There are two ways to interact with Objective-C
>
> * Create an Objective-C/D bridge
> * Make D binary compilable with Objective-C
>
> The Objective-C/D bridge would use the Objective-C runtime functions defined in C to interact with Objective-C. Every time an object is passed over the bridge it needs to be encapsulated or de-encapsulated. Another problem is the code/template bloat. A Hello World application will be around 60MB in size. This has already been done:
>
> http://www.dsource.org/**projects/dstep<http://www.dsource.org/projects/dstep>
>
> The other approach would be to make D binary compaitable with Objective-C, that is, provide extern (Objective-C) declarations. This would generate basically the same code as the Objective-C compiler would, but with the nice syntax of D instead of the horrible syntax that Objective-C is. This would also allow you do create bindings to Objective-C classes, methods and functions just as with C.
>
> The problem with this approach, it's a lot of work to modify the compiler. But that has already been done as well:
>
> http://michelf.ca/projects/d-**objc/ <http://michelf.ca/projects/d-objc/>
>
> This fork of DMD isn't ready yet (there's an alpha available) and there hasn't been any changes made in over a year. If I recall correctly, Michel Fortin said he hasn't got the time now to work on this. It also the problem with always playing catchup with the upstream version of DMD.


It occurred to me last night, I think almost all the work to get OSX running is actually already done in the iPhone drivers. You might be better off to copy the iPhone files, and adapt that to OSX. Ethan seems to think iPhone and OSX are almost identical.

On 2012-10-17 13:57, Manu wrote:

> It occurred to me last night, I think almost all the work to get OSX
> running is actually already done in the iPhone drivers. You might be
> better off to copy the iPhone files, and adapt that to OSX. Ethan seems
> to think iPhone and OSX are almost identical.

They are fairly similar. I'll have a look at the iPhone driver when I get home tonight. If you want the game to look as a proper Mac OS X application there are some additional code that is required. That is for creating the main menu and the dock icon.

Anyway, I know how to handle this now.

-- 
/Jacob Carlborg

On 17 October 2012 17:08, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-17 13:57, Manu wrote:
>
>  It occurred to me last night, I think almost all the work to get OSX
>> running is actually already done in the iPhone drivers. You might be better off to copy the iPhone files, and adapt that to OSX. Ethan seems to think iPhone and OSX are almost identical.
>>
>
> They are fairly similar. I'll have a look at the iPhone driver when I get home tonight. If you want the game to look as a proper Mac OS X application there are some additional code that is required. That is for creating the main menu and the dock icon.
>
> Anyway, I know how to handle this now.


Okay, awesome. Cheers.
I got it running on Linux-x64 last night, so I think that's the only thing
holding OSX back.

On Monday, 15 October 2012 at 14:47:06 UTC, Manu wrote:

> Ah, nicely spotted, I should stick that DLL in the zip now that you mention it.

I've just tried running this version:
https://github.com/downloads/RemedyGameJam/stache/Stache-Windows-0.1d.zip

It cannot run asking for d3dx9_43.dll and then says "failed to load Fuji_Debug.dll".

On 17 October 2012 18:30, thedeemon <dlang@thedeemon.com> wrote:

> On Monday, 15 October 2012 at 14:47:06 UTC, Manu wrote:
>
>  Ah, nicely spotted, I should stick that DLL in the zip now that you
>> mention it.
>>
>
> I've just tried running this version: https://github.com/downloads/**RemedyGameJam/stache/Stache-** Windows-0.1d.zip<https://github.com/downloads/RemedyGameJam/stache/Stache-Windows-0.1d.zip>
>
> It cannot run asking for d3dx9_43.dll and then says "failed to load Fuji_Debug.dll".
>

Hmmm, that's strange.. It's clearly a release build.
Use the 'c' version's exe, but paired with the dll's from 'd'.

I'll fix it later tonight. Thanks for mentioning that! :)