Graphics Library for D

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Mon Jan 6 13:06:08 PST 2014


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

> Just a thought, since they will be useful everywhere. 
> Furthermore, the window system in general could be useful as a 
> std.window (not std.windows) library, but I am not really sure 
> about that one now that I think about it...

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.

Abstracting the window system is currently very difficult to do 
well because Apple, Microsoft and Google are trying to 
differentiate themselves by constantly morphing their feature 
set. It might be more stable in a few years… GTK/QT look outdated 
already.


More information about the Digitalmars-d mailing list