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