January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | On Tuesday, 7 January 2014 at 06:18:23 UTC, Adam Wilson wrote: >> 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. That is slow or space consumingif you want mipmapping. >> 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. You need a common syntax. >> 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. GPU drivers don't. How could they? You mean to pregenerate everything? > 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 DX9 targets slow fragmentshaders. You should target fast fragmentshaders. And you should choose the common subset of GL/DX. You create perfect solid circles by using 2 fragmentshaders and z-buffering. First you draw all the inner triangles, for all objects in the scene, then you draw all the border triangles, back to front. > you do this a few dozen times you tank GPU performance on anything less than a discrete GPU of some expense. Next batch of Intel CPUs will provide solid shader performance, according to Intel IIRC. You should design for what is available in your average CPU in 3 years. > On Windows, we have access to Direct2D, which does not have those limitations. And Direct2D will inter-operate with Direct3D seamlessly. And double implement everything? It would be a solid mistake to make the engine Microsoft centric. You should target OpenGL 2/3 ES / WebGL. That is the common denominator. |
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On Mon, 06 Jan 2014 22:22:07 -0800, David Nadlinger <code@klickverbot.at> wrote: > 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 Indeed it is, although the way the front page talks about it is misleading... I stand corrected. :-) -- Adam Wilson IRC: LightBender Aurora Project Coordinator |
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | On Tuesday, 7 January 2014 at 05:48:38 UTC, Adam Wilson wrote:
>> 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...
What I meant is "Cinder does not seem to dispatch to different graphics API" (OpenGL vs DirectX vs ...). It targets OpenGL exclusively from what I read on the feature list. So I was wondering about the discussion on different graphics API backends.
|
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | On 2014-01-07 06:45, Adam Wilson wrote: > 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. Unfortunately you cannot. You need Objective-C just to bring up a basic window. If you also want all the rest (application menu, dock icon and so on) which is expect from every application on Mac OS X it requires surprisingly a lot of code just to get the basics up and running. This assumes if you want to avoid app bundles and plist config files. Just have a look what was required to get the standard menus and dock icons for a Derelict application using SDL: http://www.dsource.org/projects/derelict/browser/branches/Derelict2/DerelictSDL/derelict/sdl/macinit Most of those files are bindings, here are the actual code: http://www.dsource.org/projects/derelict/browser/branches/Derelict2/DerelictSDL/derelict/sdl/macinit/SDLMain.d -- /Jacob Carlborg |
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Tuesday, 7 January 2014 at 07:12:13 UTC, Ola Fosheim Grøstad wrote:
> make the engine Microsoft centric. You should target OpenGL 2/3 ES / WebGL. That is the common denominator.
Actually, you should use a DX compatible subset of OpenGL ES 3/WebGL 2, it is supposed to be fully compatible with OpenGL 4.3.
Though, if you only want vectorgraphics then the sane thing to do would be to rip out the SVG engine in Chrome or FF and create a full SVG DOM in D.
|
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Tuesday, 7 January 2014 at 08:01:44 UTC, Jacob Carlborg wrote:
> Unfortunately you cannot. You need Objective-C just to bring up a basic window. If you also want all the rest (application menu, dock icon and so on) which is expect from every application on Mac OS X it requires surprisingly a lot of code just to get the basics up and running.
Yes, but you can call D as a library from an Objective-C runtime.
1. Objective-C main() calls D main().
2. D main creates OSApplication facade and calls run(someDfunc) on it.
3. Objective-C event loop call back to someDfunc
|
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to ponce | On Tue, 07 Jan 2014 00:00:14 -0800, ponce <contact@gam3sfrommars.fr> wrote: > On Tuesday, 7 January 2014 at 05:48:38 UTC, Adam Wilson wrote: >>> 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... > > What I meant is "Cinder does not seem to dispatch to different graphics API" (OpenGL vs DirectX vs ...). It targets OpenGL exclusively from what I read on the feature list. So I was wondering about the discussion on different graphics API backends. > Ahh I see, my experience with Cinder caused me to short-circuit some useful info. Cinder has a DirectX backend in the latest dev branches. My apologies for the confusion. -- Adam Wilson IRC: LightBender Aurora Project Coordinator |
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Tue, 07 Jan 2014 00:05:35 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote: > On Tuesday, 7 January 2014 at 07:12:13 UTC, Ola Fosheim Grøstad wrote: >> make the engine Microsoft centric. You should target OpenGL 2/3 ES / WebGL. That is the common denominator. > > Actually, you should use a DX compatible subset of OpenGL ES 3/WebGL 2, it is supposed to be fully compatible with OpenGL 4.3. > > Though, if you only want vectorgraphics then the sane thing to do would be to rip out the SVG engine in Chrome or FF and create a full SVG DOM in D. > I would like to reiterate that Aurora will not specify the back-end, so it will not OpenGL or DirectX, or any API centric. The intention is a high-level API that can use any renderer that meets some basic requirements. There is nothing technically wrong with DirectX on Windows and unlike OpenGL which requires manufacturer provided drivers, it's guaranteed to be available. -- Adam Wilson IRC: LightBender Aurora Project Coordinator |
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | On Tuesday, 7 January 2014 at 08:31:07 UTC, Adam Wilson wrote: > I would like to reiterate that Aurora will not specify the back-end, so it will not OpenGL or DirectX, or any API centric. You need a reference graphics pipeline or performance will suffer. > The intention is a high-level API that can use any renderer that meets some basic requirements. There is nothing technically wrong with DirectX on Windows and unlike OpenGL which requires manufacturer provided drivers, it's guaranteed to be available. Not sure why you wrote that, but you come through as Microsoft biased, If you want cross platform performance your only choice is to pick a DX compatible subset of OpenGL ES 2/3 and use that as your reference graphics pipeline, which is quite easy to do. If your reference implementation is based on a proprietary 2D engine then all other platform implementations will suffer. |
January 07, 2014 Re: Graphics Library for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | 07-Jan-2014 12:30, Adam Wilson пишет: > On Tue, 07 Jan 2014 00:05:35 -0800, Ola Fosheim Grøstad > <ola.fosheim.grostad+dlang@gmail.com> wrote: > There is nothing technically wrong with DirectX on Windows > and unlike OpenGL which requires manufacturer provided drivers, it's > guaranteed to be available. Pardon, but this reads like citation of some old crap to me. And how would you use a GPU w/o manufacturer provided drivers? DX also builds on top of vendor specific drivers. -- Dmitry Olshansky |
Copyright © 1999-2021 by the D Language Foundation