On 01/06/2014 01:52 PM, bearophile wrote:
> Mike:
>
>> * Break the library into loosely coupled pieces that can be used
>> individually or aggregated by other projects to build things that we
>> haven't even thought of
>>   *  Geometric primitives should be their own library/package
>>   *  Vector graphics (paths, line caps, etc...) should be their own
>> library/package
>>   *  Raster graphics should be their own library/package
>>   *  Window management should be its own library/package
>>   *  Font's are just data.  Don't couple them to the rendering
>> engine.  (e.g  Convert them to a vector/raster representation and then
>> let those libraries handle the rest.
>>   *  The rendering engine should be its own library/package, that
>> should be easily replaced with whatever is suitable for the given
>> platform.
>
> An independent color system module could be useful, even in Phobos.
>
> Part of the Geometric primitives (2D/3D vectors, rotation matrices, the
> most commonly useful geometry algorithms and formulas) could go in a
> Phobos module. And the graphics library could import and use this
> standard module.
>
I wrote a vector graphics library quite a while ago.
https://github.com/MartinNowak/graphics
It contains a lot of Path and Bezier curve algorithms and
uses a novel rasterization technique http://josiahmanson.com/research/wavelet_rasterization/.
It's a little outdated and probably won't compile any longer.

It also depends on a small GUI primitives library which contains Color, Point, Size and Rect.
https://github.com/MartinNowak/guip

On Thu, 16 Jan 2014 07:51:26 -0800, Martin Nowak <code@dawg.eu> wrote:

> On 01/06/2014 01:52 PM, bearophile wrote:
>> Mike:
>>
>>> * Break the library into loosely coupled pieces that can be used
>>> individually or aggregated by other projects to build things that we
>>> haven't even thought of
>>>   *  Geometric primitives should be their own library/package
>>>   *  Vector graphics (paths, line caps, etc...) should be their own
>>> library/package
>>>   *  Raster graphics should be their own library/package
>>>   *  Window management should be its own library/package
>>>   *  Font's are just data.  Don't couple them to the rendering
>>> engine.  (e.g  Convert them to a vector/raster representation and then
>>> let those libraries handle the rest.
>>>   *  The rendering engine should be its own library/package, that
>>> should be easily replaced with whatever is suitable for the given
>>> platform.
>>
>> An independent color system module could be useful, even in Phobos.
>>
>> Part of the Geometric primitives (2D/3D vectors, rotation matrices, the
>> most commonly useful geometry algorithms and formulas) could go in a
>> Phobos module. And the graphics library could import and use this
>> standard module.
>>
> I wrote a vector graphics library quite a while ago.
> https://github.com/MartinNowak/graphics
> It contains a lot of Path and Bezier curve algorithms and
> uses a novel rasterization technique http://josiahmanson.com/research/wavelet_rasterization/.
> It's a little outdated and probably won't compile any longer.
>
> It also depends on a small GUI primitives library which contains Color, Point, Size and Rect.
> https://github.com/MartinNowak/guip
>

This is awesome! What's the license on it and can we use it in Aurora?

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Thu, 16 Jan 2014 03:22:08 -0800, Russel Winder <russel@winder.org.uk> wrote:

> On Thu, 2014-01-16 at 08:07 +0000, Tofu Ninja wrote:
>> You mentioned keyboard, mouse, and touch. Something that can't be
>> forgot about is pen input. It is becoming more and more common
>> for laptops to not only come with touch, but also a
>> stylus+digitizer for pen input. Just something to think about.
>
> Agreed. I have a Wacom which I use for all of my training courses.
>

We'll try to support as much input as we can, but to some extent we'll be at the mercy of what the Operating System can give us.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

Personally I would be disappointed if this didn't have any support for custom shaders, though I know it would be hard to do in a idiomatic cross platform way.

On Fri, 17 Jan 2014 15:51:29 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:

> Personally I would be disappointed if this didn't have any support for custom shaders, though I know it would be hard to do in a idiomatic cross platform way.
>

Since shaders are GPU dependent and writing a high-level shading language is firmly outside the scope of Aurora, the only thing that makes sense is to have the programmer write their own shaders and have Aurora provide the proper API interfaces.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Saturday, 18 January 2014 at 01:33:53 UTC, Adam Wilson wrote:
> On Fri, 17 Jan 2014 15:51:29 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:
>
>> Personally I would be disappointed if this didn't have any support for custom shaders, though I know it would be hard to do in a idiomatic cross platform way.
>>
>
> Since shaders are GPU dependent and writing a high-level shading language is firmly outside the scope of Aurora, the only thing that makes sense is to have the programmer write their own shaders and have Aurora provide the proper API interfaces.

As long as some kind of interface was exposed, then something more advanced and portable can be added later down the road.