Re: D/Objective-C 64bit
Oh, just found out, it seems that currently the extern C
declarations don't work. This comes from the original Chocolat
range.d
extern (C) {
nothrow:
NSRange NSUnionRange(NSRange range1, NSRange range2) ;
NSRange NSIntersectionRange(NSRange range1, NSRange range2) ;
NSStringNSStringFromRange(NSRange range) ;
NSRange NSRangeFromString(NSString aString) ;
NSRange NSMakeRange(NSUInteger loc, NSUInteger len) ;
NSUInteger NSMaxRange(NSRange range) ;
boolNSEqualRanges(NSRange range1, NSRange range2) ;
}
When trying to use NSMakeRange i get:
Undefined symbols for architecture x86_64:
_NSMakeRange, referenced from:
Also when I tried to declare / use extern strings like from
NSApplication.h:
APPKIT_EXTERN NSString *NSApplicationDidHideNotification;
I found no way to get this working. Is this a limitation of the
current 64 bit port?
Thanks again. Christian
Re: D/Objective-C 64bit
On 2014-11-06 17:06, Christian Schneider wrote:
Oh, just found out, it seems that currently the extern C declarations
don't work. This comes from the original Chocolat range.d
extern (C) {
nothrow:
NSRange NSUnionRange(NSRange range1, NSRange range2) ;
NSRange NSIntersectionRange(NSRange range1, NSRange range2) ;
NSString NSStringFromRange(NSRange range) ;
NSRange NSRangeFromString(NSString aString) ;
NSRange NSMakeRange(NSUInteger loc, NSUInteger len) ;
NSUInteger NSMaxRange(NSRange range) ;
bool NSEqualRanges(NSRange range1, NSRange range2) ;
}
When trying to use NSMakeRange i get:
Undefined symbols for architecture x86_64:
_NSMakeRange, referenced from:
I wasn't able to link with the symbol either. But when I tried in
Objective-C it worked, but only when I imported Foundation.h, not when I
declared NSMakeRange myself. That got me thinking and I had a look in
the Foundation NSRange.h header file. NSMakeRange and friends are
implement directly in the header file to allow inlining. D cannot access
inlined functions if they don't exist in a library.
In general you need to reimplement these functions in D. In this
particular case, with NSMakeRange, you can just do this in D instead:
auto range = NSRange(1, 2);
The above is a syntax that is allowed for all structs. If you really
want to type NSMakeRange you need implement the function yourself or
make an alias and use the above syntax:
alias NSMakeRange = NSRange;
The downside with the alias is that it allows to use NSMakeRange as a
struct as well:
NSMakeRange range;
Also when I tried to declare / use extern strings like from
NSApplication.h:
APPKIT_EXTERN NSString *NSApplicationDidHideNotification;
I found no way to get this working. Is this a limitation of the current
64 bit port?
I think that should work. How did you declare it? It should be declared
like this:
extern (C) extern NSString NSApplicationDidHideNotification;
I tried with a standard D compiler and void* instead of NSString and
that worked.
extern (C) tells the compiler to use C linkage, the second extern
tells the compiler this symbols is defined somewhere else, i.e. in some
library.
--
/Jacob Carlborg
dmedia library
I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license,
Re: dmedia library
On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC
Re: dmedia library
On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs.
Re: dmedia library
On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's.
Re: dmedia library
On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote: On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's. I eventually want to build a entity system, and make use of parallel_foreach, or fibers/routines, and have a loading thread that can get assets in an async fashion. Large voxel/cube-voxel systems and mega texturing interest me, I feel like a small team could develop a big game with tools built around a voxel system. XCB mostly solves the threading issues that XLIB suffers from, However XCB has poor support for the input extensions, as of yet nothing that replaces xlookupstring, I hope to find a good work around at some point, but it seems good enough for my needs. Also I am not sure of how well XXf86vm extension is supported for full screen access, As I have yet to implement full screen windows. Its a learning experience, however so I can't complain to much!
Re: dmedia library
On 7/11/2014 7:58 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote: On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's. I eventually want to build a entity system, and make use of parallel_foreach, or fibers/routines, and have a loading thread that can get assets in an async fashion. Large voxel/cube-voxel systems and mega texturing interest me, I feel like a small team could develop a big game with tools built around a voxel system. XCB mostly solves the threading issues that XLIB suffers from, However XCB has poor support for the input extensions, as of yet nothing that replaces xlookupstring, I hope to find a good work around at some point, but it seems good enough for my needs. Also I am not sure of how well XXf86vm extension is supported for full screen access, As I have yet to implement full screen windows. Its a learning experience, however so I can't complain to much! Interesting, just out of interest have you thought about separating it out and work independently of GUI's for e.g. game servers? Or would that abstract it to the point of non-usefulness?
Re: dmedia library
On Friday, 7 November 2014 at 07:08:02 UTC, Rikki Cattermole wrote: On 7/11/2014 7:58 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote: On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's. I eventually want to build a entity system, and make use of parallel_foreach, or fibers/routines, and have a loading thread that can get assets in an async fashion. Large voxel/cube-voxel systems and mega texturing interest me, I feel like a small team could develop a big game with tools built around a voxel system. XCB mostly solves the threading issues that XLIB suffers from, However XCB has poor support for the input extensions, as of yet nothing that replaces xlookupstring, I hope to find a good work around at some point, but it seems good enough for my needs. Also I am not sure of how well XXf86vm extension is supported for full screen access, As I have yet to implement full screen windows. Its a learning experience, however so I can't complain to much! Interesting, just out of interest have you thought about separating it out and work independently of GUI's for e.g. game servers? Or would that abstract it to the point of non-usefulness? Yes, tho I have yet to put much thought into how that will all be put together. Working towards something that I could use in vibe.d, without any dependence on the windowing system would be important for a good gameserver.
Re: dmedia library
On 7/11/2014 8:22 p.m., luminousone wrote: On Friday, 7 November 2014 at 07:08:02 UTC, Rikki Cattermole wrote: On 7/11/2014 7:58 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote: On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's. I eventually want to build a entity system, and make use of parallel_foreach, or fibers/routines, and have a loading thread that can get assets in an async fashion. Large voxel/cube-voxel systems and mega texturing interest me, I feel like a small team could develop a big game with tools built around a voxel system. XCB mostly solves the threading issues that XLIB suffers from, However XCB has poor support for the input extensions, as of yet nothing that replaces xlookupstring, I hope to find a good work around at some point, but it seems good enough for my needs. Also I am not sure of how well XXf86vm extension is supported for full screen access, As I have yet to implement full screen windows. Its a learning experience, however so I can't complain to much! Interesting, just out of interest have you thought about separating it out and work independently of GUI's for e.g. game servers? Or would that abstract it to the point of non-usefulness? Yes, tho I have yet to put much thought into how that will all be put together. Working towards something that I could use in vibe.d, without any dependence on the windowing system would be important for a good gameserver. Depending on the needs of the game server, I would keep it apart from the web server aspect from vibe.d all together. By in large interacting with e.g. a task, shouldn't be hard but that's not quite why. The idea behind my actor framework Dakka [0] (although would need a bit of work for this sort of thing). Share the data (including data models) between the web server and game server over sockets with method calling support. But keep its functions separate. Although the original context was all about having front end nodes for web development and backend nodes for interacting with e.g. VM's. But that's just me rambling with not much reason. [0] https://github.com/rikkimax/dakka
