www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmedia library

reply "luminousone" <rd.hunt gmail.com> writes:
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,
Nov 06 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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 
first lastname.co.nz

[0] https://github.com/rikkimax/DWC
Nov 06 2014
parent reply "luminousone" <rd.hunt gmail.com> writes:
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 first 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.
Nov 06 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
 first 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.
Nov 06 2014
parent reply "luminousone" <rd.hunt gmail.com> writes:
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
 first 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!
Nov 06 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
 first 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?
Nov 06 2014
parent reply "luminousone" <rd.hunt gmail.com> writes:
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
 first 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.
Nov 06 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
 first 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
Nov 06 2014
parent "luminousone" <rd.hunt gmail.com> writes:
On Friday, 7 November 2014 at 07:32:53 UTC, Rikki Cattermole 
wrote:

 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
 first 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


dwc has been an interesting read, using the dub configurations 
option, and separate directories for the different platforms 
seems much cleaner then my approach with version statements.

Your win32 code will be helpful when I get to that as well. 
Luckily win32 doesn't suffer the threading problems of xlib, nor 
does mac.

I will drop an email later tonight after work, I am sure their 
are a few area's where we can save time by sharing code, in so 
far as a larger framework is concerned.
Nov 08 2014