On Monday, 6 January 2014 at 21:06:11 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 6 January 2014 at 20:43:22 UTC, Ross Hays wrote:
Unrelated: If this project is going to add things such as
mathematical vectors and such into the standard library for D,
that perhaps they should be included in the math package
(std.math) rather than some new package (std.aurora).
Yes, and it would be nice to have rich builtin swizzle support,
which probably requires compiler support… So you can do:
pos.xyzw
pos.xyz1
pos.xyz0
pos.xxyy
pos.xy
color.rgba
color.rgb1
color.rgb0
color.argb
etc
With some templating and opDispatch I imagine this can be done, I
already have something basic for this in a vector implementation
I wrote a while back after asking about it
http://forum.dlang.org/thread/[email protected]
What about having a OSApplication facade to a system-specific
runtime with GPU capabilities. It could be SDL in the
beginning. I think you can get a long way with just:
1. a single window 3D GPU context that can switch between
fullscreen/not fullscreen
2. standard GPU stuff
3. memory handler (os telling you to back down, or that GPU
resources have been lost)
4. native file requester
5. system specific main menubar
The single window 3D GPU context can later be just a special
case for the real window system abstraction. That way you can
delay the task of creating a window system abstraction.
That's basically what I have been doing as well. I have a
platform.window object that basically just wraps some SDL into a
nice interface using properties, but I only allow the one object
accessed with platform.window rather than allowing users to
create more windows (platform.window (game.platform.window
technically) is just created when a game is created.
I really do need to clean that code up and maybe just release it
all...