For 2D I like Anti Grain Geometry.

http://www.antigrain.com/

When used with the C++ Agg2D wrapper things become super easy.

Here is the online documentation of Agg2D from the Delphi port of AGG
http://www.crossgl.com/aggpas/documentation/index.html

For another view here is an interesting article on how AGG works in Haiku and covers some of the compile time properties of AGG
https://www.haiku-os.org/documents/dev/painter_and_how_agg_works

There is also a c# port.

Zz

One of the things I did with my files was to have a separate event loop module which could be used by anything, in addition to their own event loop things (especially since I never implemented the other module on Windows or even other Poxixes yet; it is Linux only, but that's just due to my implementation.)

The separate event loop is nice because integrating loops is a bit of a pain. What mine does is pass type info for a single argument to a central thing:

import ev = arsd.eventloop;

// two separate libraries that can use the same loop
import simpledisplay;
import terminal;

struct MyEvent { } // a custom event

void main() {
    auto window = new SimpleWindow();
    auto terminal = Terminal(ConsoleOutputMode.linear);
    auto terminalInput = RealTimeconsoleInput(&terminal,
        ConsoleInputFlags.raw | ConsoleInputFlags.allInputEvents);

    addListener((InputEvent event) {
         // input from the terminal
    });
    addListener((KeyEvent event) {
         // key info from the gui window
         send(MyEvent()); // send the custom event
    });
    addListener(MyEvent event) {
        // a custom event
    });

    ev.loop();
}

and so on. Then the higher level things can build on this to do whatever - minigui.d for example uses a javascript style item.addEventListener thingy.

On Monday, 6 January 2014 at 19:44:07 UTC, Adam D. Ruppe wrote:
> The separate event loop is nice because integrating loops is a bit of a pain.

Yes, and you might want to have multiplayer or peer-to-peer over bluetooth/network also. So if all interaction i/o provide the same interface you might be able to get cleaner code.

> and so on. Then the higher level things can build on this to do whatever - minigui.d for example uses a javascript style item.addEventListener thingy.

Interestingly, Dart made that more uniform by using a stream abstraction:

abstract StreamSubscription<T> listen(void onData(T event), {Function onError, void onDone(), bool cancelOnError})

So you can do "item.onClick.listen( (e){dosomething(e);} )"

This is all a fantastic idea and seems like the kind of project that D really needs to keep improving (something new and large scale that will be in the standard library).

I do agree with everyone else that the order of implementation should be changed to something more along the lines of Window System -> 3D Graphics -> 2D Graphics, with other bits along the way. It seems natural to build the window system first so the other parts can be tested, and it also allows the API to be a bit more established before getting into the nitty-gritty of it all.

I have been working on making a OpenGL game engine of sorts in D since I started with it, and while I know this is not the same goal for this project, I would be glad to help as well. I must admit though, I am not entirely sure I understand the entire aim of Cinder if performance is not most important. I will have to read more about the library, but I would still like to help if it means improving the phobos library and D.

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

-Ross

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.

On Monday, 6 January 2014 at 21:06:11 UTC, Ola Fosheim Grøstad wrote:
> Yes, and it would be nice to have rich builtin swizzle support, which probably requires compiler support…

Probably not. Did you have a look at the existing D math libraries yet? IIRC even some of the D1 libraries already had solid swizzling support.

David

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/udkzrlwrvpgngelbvtlz@forum.dlang.org

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

On Monday, 6 January 2014 at 21:14:12 UTC, David Nadlinger wrote:
> On Monday, 6 January 2014 at 21:06:11 UTC, Ola Fosheim Grøstad wrote:
>> Yes, and it would be nice to have rich builtin swizzle support, which probably requires compiler support…
>
> Probably not. Did you have a look at the existing D math libraries yet? IIRC even some of the D1 libraries already had solid swizzling support.
>
> David

You can even do swizzling assignement nowadays: https://github.com/p0nce/gfm/blob/master/math/gfm/math/vector.d#L305

On Monday, 6 January 2014 at 21:19:08 UTC, ponce wrote:
> On Monday, 6 January 2014 at 21:14:12 UTC, David Nadlinger wrote:
>> On Monday, 6 January 2014 at 21:06:11 UTC, Ola Fosheim Grøstad wrote:
>>> Yes, and it would be nice to have rich builtin swizzle support, which probably requires compiler support…
>>
>> Probably not. Did you have a look at the existing D math libraries yet? IIRC even some of the D1 libraries already had solid swizzling support.
>>
>> David
>
> You can even do swizzling assignement nowadays: https://github.com/p0nce/gfm/blob/master/math/gfm/math/vector.d#L305

I hadn't ever looked at the D GFM library. That is really nice and pretty much how I'd expect it to be done, but nice that it is done.

On Monday, 6 January 2014 at 21:14:12 UTC, David Nadlinger wrote:
> On Monday, 6 January 2014 at 21:06:11 UTC, Ola Fosheim Grøstad wrote:
>> Yes, and it would be nice to have rich builtin swizzle support, which probably requires compiler support…
>
> Probably not. Did you have a look at the existing D math libraries yet?

I've only looked at what is available in the phobos documentation so I wasn't aware of that, but it is nice to see that it is supported in libraries that are available today! :-)  You still need compiler support though, if you want performance (memory layout+backend)…

I also would like to have '1' and '0' swizzle for convenience. I never understood why that was left out from other languages.