On Monday, 6 January 2014 at 21:14:16 UTC, Ross Hays wrote:
> 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.

Yes, and you don't really need all that many properties or event listeners for a basic canvas window: width, height, onResize, onClose, onPreRedraw, onRedraw (realtime), fullscreen…?

If the filerequester/menubar is optional then it should work out for most platforms too with some opportunities for code sharing between them:

iOS: runtime in Objective-C++

Android NDK: runtime in C++
http://developer.android.com/tools/sdk/ndk/index.html

Windows Phone 8 Native Code: runtime in C++
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681687(v=vs.105).aspx

Chrome/Pepper Native Client/webGL: runtime in C++
https://developers.google.com/native-client/dev/

> I really do need to clean that code up and maybe just release it all...

:-)

On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> [...]
> So with the above framework in mind, let's talk!

I think the Azure project from Mozilla can provide some design perspective for what you are trying to do. To get the performance they needed in composing a web page Mozilla made their own stateless wrapper over Direct2D that avoided the performance issues they were facing as a result of using Cairo.

Here are the relevant links.

https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/
https://wiki.mozilla.org/Platform/Features/AzureD2DCanvas
https://bugzilla.mozilla.org/show_bug.cgi?id=651858

Joseph

On Mon, 06 Jan 2014 03:02:00 -0800, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

> On 06/01/14 08:16, Adam Wilson wrote:
>> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:
>>> * Please don't make a graphics library that is useful only on PCs.
>>>
>>
>> That's the plan. However at this point D only works on x86 so it's a moot point.
>
> Not really -- the GDC/LDC teams seem to be doing excellent work on ARM support which I get the feeling will arrive sooner rather than later.  I think it'll be really important to have multi-device support at the core of your graphics library project, and to factor that into your design from the beginning.
>
> Besides, you planning in that way will give encouragement to those porting efforts :-)
>

The plan is to support ARM systems. And if LDC or GDC can deliver that with full druntime/Phobos support we can look at build a new backends.

> Related to this: I read in the news that C++ is planning on standardizing on Cairo as a graphics library.  Is that something that could be useful to engage with?

It's possible but from what I've gathered Cairo is not the best, just the simplest common denominator. I am actually on the C++ Graphics forum, although I have posted anything because even with my graphics background I feel quite inadequate in there. :-)

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Mon, 06 Jan 2014 07:41:54 -0800, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 06-Jan-2014 19:16, H. S. Teoh пишет:
>> On Sun, Jan 05, 2014 at 11:16:03PM -0800, Adam Wilson wrote:
>>> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:
>> [...]
>>>>> The logical phases as I can see them are as follows, but please
>>>>> suggest changes:
>>>>
>>>> Start with the most primitive and move up from there (If loosely
>>>> coupled, the could be developed in parallel)
>>>> 1. Geometric primitives
>>>> 2. Vector graphics
>>>> 3. Fonts (just a special case of vector graphics)
>>>> 4. Rasterization
>>>> 5. Backend (Direct2D/3D, OpenGL, OpenVG, whatever)
>>>>
>>>
>>> The problem I can see here is that if you want to test the first
>>> four, number five has to be built out to some degree.
>> [...]
>>
>> For initial development, it could be as simple as rendering to a generic
>> framebuffer that then gets blitted to whatever OS primitives you have to
>> display it on the screen. That should be enough to get things going
>> while "real" backends get developed.
>
> It would be better not to or you risk introducing suboptimal software rendering patterns that do not have even remote correspondence to the hardware.
>

I share Dmitry's position.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Mon, 06 Jan 2014 02:38:21 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2014-01-06 05:10, Adam Wilson wrote:
>> Hello Fellow D Heads,
>>
>> Recently, I've been working to evaluate the feasibility and
>> reasonability of building out a binding to Cinder in D. And while it is
>> certainly feasible to wrap Cinder, that a binding would be necessarily
>> complex and feel very unnatural in D.
>>
>> So after talking it over with Walter and Andrei, we feel that, while we
>> like how Cinder is designed and would very much like to have something
>> like it available in D, wrapping Cinder is not the best approach in the
>> long-term.
>>
>> With that in mind, we would like to start a discussion with interested
>> parties about building a graphics library in the same concept as Cinder,
>> but using an idiomatic D implementation from the ground up. Walter has
>> suggested that we call it Aurora, and given the visual connotations
>> associated with that name, I think it is most appropriate for this project.
>>
>> [SNIP]
>> So with the above framework in mind, let's talk!
>
> I like it :).
>
> Every time I read a proposal that has anything to do with graphics I always start to think there will be problems on Mac OS X. Depending on how much interaction with the platform is needed, it always comes back to the same problem: interfacing with Objective-C. It's verbose, cumbersome and annoying to interface with Objective-C without language support. We badly need D/Objective-C [1].
>
> [1] http://wiki.dlang.org/DIP43

That's why I want to keep the dependencies limited and low-level, if we only use OpenGL on OSX when can get away with a C interface.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Mon, 06 Jan 2014 03:22:25 -0800, ponce <contact@gam3sfrommars.fr> wrote:

> On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
>> If you are interested in helping with a Cinder like library for D and/or have code you'd like to contribute, let's start talking and see what happens.
>
> First I must say I dislike the Cinder concept because C++ frameworks like this tend to have an extremely large scope (See_also: JUCE).
>

All graphics API's tend to have a large scope, it's a function of the complexity of the task. I don't see this as an inherently bad thing, just something that we need to think about while designing it.

> I work on GFM since 2012 (https://github.com/p0nce/gfm) which is 100% public domain, feel free to take anything from it. There is some overlap with Cinder's features: http://p0nce.github.io/gfm/
>
> It seems that you want graphics API abstraction, yet Cinder has none of this.

Um, this last statement makes no sense, that's pretty much exactly what Cinder is...

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Mon, 06 Jan 2014 03:46:58 -0800, Dejan Lekic <dejan.lekic@gmail.com> wrote:

>
> So Cinder is basically an OpenCV competition?

Yes, OpenCV is in the same class of tools as Cinder, although the API's are different.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Mon, 06 Jan 2014 07:49:27 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
>> The logical phases as I can see them are as follows, but please suggest changes:
>>
>> - Windowing and System Interaction (Including Keyboard/Mouse/Touch Input)
>> - Basic Drawing (2D Shapes, Lines, Gradients, etc)
>> - Image Rendering (Image Loading, Rendering, Modification, Saving, etc.)
>> - 3D Drawing (By far the most complex stage, so we'll leave it for last)
>
> I suggest you start working the other way. Because if you want performance you will most likely want everything in the render path to be based on shaders:
>
> 1. Fonts and monochrome icons based on distance-fields.

Typically it's easier to use TrueType/OpenType fonts. Although Pathing support for icons is a must.

> 2. All fills based on shaders, with the ability to convert D into GLSL etc.

If possible I want to hand this off to a system library like OpenGL or DirectX.

> 3. Render to texture, with caching mechanism.

My understanding is that it is best to let the GPU drivers handle caching, but somebody with Game Dev experience might be able to shed some light.

> 4. Simplistic mesh rendering from native D arrays.

Good idea.

> 5. The ability to attach native 3D code paths (GL/DX) to the engine for advanced meshes.

Good idea.

>
> Then you build 2D on top of this.
>
> Rendering and input should be completely separate.

While I can't speak for the OpenGL library, from a performance standpoint using 3D drawing for 2D surfaces is actually not an efficient method for anything other than perfect square, as soon as you want curves performance tanks. Microsoft actually built an entire 2D/3D rendering engine using DirectX9 called MilCore. Now, DirectX9 has no native 2D capability and MilCore is the rendering core for WPF. So how did they draw a 2D circle? They draw over 1000 triangles. Needless to say that if you do this a few dozen times you tank GPU performance on anything less than a discrete GPU of some expense.

On Windows, we have access to Direct2D, which does not have those limitations. And Direct2D will inter-operate with Direct3D seamlessly.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Tuesday, 7 January 2014 at 05:50:04 UTC, Adam Wilson wrote:
> On Mon, 06 Jan 2014 03:46:58 -0800, Dejan Lekic <dejan.lekic@gmail.com> wrote:
>
>>
>> So Cinder is basically an OpenCV competition?
>
> Yes, OpenCV is in the same class of tools as Cinder, although the API's are different.

Isn't OpenCV mainly a collection of computer vision algorithms, maybe including some helpers to build an experimental UI around them?

David

On Mon, 06 Jan 2014 09:50:48 -0800, FreeSlave <freeslave93@gmail.com> wrote:

> I'm not familiar with Cinder library yet (seems it does not support Linux, so it's not very interesting for me), but I suppose graphics library should provide at least two approaches to build graphic applications. The first one is something that SDL and SFML offer: user has to manually write cycle loop for event handling. The second one is more complicated: event loop is encapsulated by some Application class which automatically dispatches events to gui elements and provide signal-slot system to ease creation of application logic (like Qt library does). The second approach implementation may be built on the first one, but it should not be the only. Sometimes the first approach is more easy and it has no overhead of all these high-level gui abstractions.

I tend to agree that we need both, but in terms of writing API simplicity the second option is actually better. The first one will require some interesting and probably not idiomatic...

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator