dmedia library

Sat Nov 8 13:13:32 PST 2014

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 at 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.