Windowing(DirectX/OpenGL)

> You're forgetting input handling, processing events from the
> windowing system, etc. You can of course make a full screen
> window and therein draw windows yourself (actually that is what
> I'm doing in my engine's modeller) - but that is only 10% OpenGL
> and the rest is implementing the whole windowing (user
> interactin, input, events) stuff.

Input, events are anyway not provided by OpenGL if I
am not mistaken.

User Interaction is about mapping I/O "events"
to coordinate positions on the Window, so I presume this
is as straight forward as I/O.
As you have mentioned, DirectX does seem to understand
input. The standard events such as maximize, minimize,
hitting the close button(or whatever it is called) are pretty
much universal if someone is looking for portability(I
am more interested in writing to as few different target
APIs on Windows as it is possible to do so).

> Still you need the Win32 API (or DirectInput) to process the
> actual input events. You can't circumvent this.

Agreed to the extent that OpenGL does not by itself
understand display-unrelated stuff, DirectX does.

> But the window
> your application is running in can only be created with the
> functions of the windowing system (Win32, Xlib etc.)

The Window that the Windowing system (Win32) would be relied
upon for creating can be an absolutely minimalistic Window
whose sole purpose is to establish a bounds for the
application which created that Window(resizing of Window
and all that goes through the native API).

>
> Also remember, that the Win32 windowing is done with high
> priority in the operating system. Doing such stuff in the
> application will be less performant in Win32 conditions (in X11
> it doesn't matter, as it's done in userspace anyway).

I/O performance is very difficult to measure. I presume
high-performance Game development is pretty much feasible
through OpenGL(QuakeIII is damn good), take away the universally
recognized events from the Toolkit and the remainder that
gets "routed" through OpenGL/DirectX wouldnt be in performance
terms, slower then Win32. What do you think?

> In my
> modeller I'm doing it all myself, because it's _portable_ and
> always looks the same, regardless of the used environment. And
> as I'm using a own, uncommon UI scheme - with a very steep
> learning curve (parts of the UI are inspired by blender, SGI's
> Motif variant and a few other toolkits - I just took the best of
> every concept and merged it) - this doesn't matter.

Is your modeller available as a free download :-) ?
Regards.

> You're forgetting input handling, processing events from the
> windowing system, etc. You can of course make a full screen
> window and therein draw windows yourself (actually that is what
> I'm doing in my engine's modeller) - but that is only 10% OpenGL
> and the rest is implementing the whole windowing (user
> interactin, input, events) stuff.

Input, events are anyway not provided by OpenGL if I
am not mistaken.

User Interaction is about mapping I/O "events"
to coordinate positions on the Window, so I presume this
is as straight forward as I/O.
As you have mentioned, DirectX does seem to understand
input. The standard events such as maximize, minimize,
hitting the close button(or whatever it is called) are pretty
much universal if someone is looking for portability(I
am more interested in writing to as few different target
APIs on Windows as it is possible to do so).

> Still you need the Win32 API (or DirectInput) to process the
> actual input events. You can't circumvent this.

Agreed to the extent that OpenGL does not by itself
understand display-unrelated stuff, DirectX does.

> But the window
> your application is running in can only be created with the
> functions of the windowing system (Win32, Xlib etc.)

The Window that the Windowing system (Win32) would be relied
upon for creating can be an absolutely minimalistic Window
whose sole purpose is to establish a bounds for the
application which created that Window(resizing of Window
and all that goes through the native API).

>
> Also remember, that the Win32 windowing is done with high
> priority in the operating system. Doing such stuff in the
> application will be less performant in Win32 conditions (in X11
> it doesn't matter, as it's done in userspace anyway).

I/O performance is very difficult to measure. I presume
high-performance Game development is pretty much feasible
through OpenGL(QuakeIII is damn good), take away the universally
recognized events from the Toolkit and the remainder that
gets "routed" through OpenGL/DirectX wouldnt be in performance
terms, slower then Win32. What do you think?

> In my
> modeller I'm doing it all myself, because it's _portable_ and
> always looks the same, regardless of the used environment. And
> as I'm using a own, uncommon UI scheme - with a very steep
> learning curve (parts of the UI are inspired by blender, SGI's
> Motif variant and a few other toolkits - I just took the best of
> every concept and merged it) - this doesn't matter.

Is your modeller available as a free download :-) ?
Regards.

mp2sleep@hotmail.com wrote:
>
> Just so that syntactic sugar is differentiated from feature
> availability, I want to know if a Toolkit designer would be
> able to provide a Windowing facility by just using OpenGL
> internally.
>

You can render the window contents, yes.

Opening windows and reading the mouse? No.

> What kind of performance hit or saving would one incur when
> compared to using the Win32 API?
>

Impossible to say. It depends on too many factors.

> I would be happy with any one of OpenGL or DirectX.
>

If you learn what an abstract interface is you
can make it API-independent. You can switch
GDI/OpenGL/DirectX with each redraw and nobody
will notice.

--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

Governments, like diapers, should be changed often,
and for the same reason.

mp2sleep@hotmail.com wrote:
>
> Just so that syntactic sugar is differentiated from feature
> availability, I want to know if a Toolkit designer would be
> able to provide a Windowing facility by just using OpenGL
> internally.
>

You can render the window contents, yes.

Opening windows and reading the mouse? No.

> What kind of performance hit or saving would one incur when
> compared to using the Win32 API?
>

Impossible to say. It depends on too many factors.

> I would be happy with any one of OpenGL or DirectX.
>

If you learn what an abstract interface is you
can make it API-independent. You can switch
GDI/OpenGL/DirectX with each redraw and nobody
will notice.

--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

Governments, like diapers, should be changed often,
and for the same reason.

mp2sleep@hotmail.com wrote:
>
> Just so that syntactic sugar is differentiated from feature
> availability, I want to know if a Toolkit designer would be
> able to provide a Windowing facility by just using OpenGL
> internally.
>

You can render the window contents, yes.

Opening windows and reading the mouse? No.

> What kind of performance hit or saving would one incur when
> compared to using the Win32 API?
>

Impossible to say. It depends on too many factors.

> I would be happy with any one of OpenGL or DirectX.
>

If you learn what an abstract interface is you
can make it API-independent. You can switch
GDI/OpenGL/DirectX with each redraw and nobody
will notice.

--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

Governments, like diapers, should be changed often,
and for the same reason.

mp2sleep@hotmail.com wrote:

<snip>
>>Still you need the Win32 API (or DirectInput) to process the
>>actual input events. You can't circumvent this.
>
> Agreed to the extent that OpenGL does not by itself
> understand display-unrelated stuff, DirectX does.

I don't want to seem pedantic, but DirectX is NOT a single API like OpenGL, it
is a group of unrelated APIs that Microsoft slapped together under one heading.
To compare apples to apples, you need to compare OpenGL to Direct3D, and
Direct3D knows nothing about input or windowing any more than OpenGL.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

mp2sleep@hotmail.com wrote:

<snip>
>>Still you need the Win32 API (or DirectInput) to process the
>>actual input events. You can't circumvent this.
>
> Agreed to the extent that OpenGL does not by itself
> understand display-unrelated stuff, DirectX does.

I don't want to seem pedantic, but DirectX is NOT a single API like OpenGL, it
is a group of unrelated APIs that Microsoft slapped together under one heading.
To compare apples to apples, you need to compare OpenGL to Direct3D, and
Direct3D knows nothing about input or windowing any more than OpenGL.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

mp2sleep@hotmail.com wrote:

<snip>
>>Still you need the Win32 API (or DirectInput) to process the
>>actual input events. You can't circumvent this.
>
> Agreed to the extent that OpenGL does not by itself
> understand display-unrelated stuff, DirectX does.

I don't want to seem pedantic, but DirectX is NOT a single API like OpenGL, it
is a group of unrelated APIs that Microsoft slapped together under one heading.
To compare apples to apples, you need to compare OpenGL to Direct3D, and
Direct3D knows nothing about input or windowing any more than OpenGL.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

mp2sleep@hotmail.com wrote:


> User Interaction is about mapping I/O "events"
> to coordinate positions on the Window, so I presume this
> is as straight forward as I/O.

The problem is: You won't be able to get access to the I/O
because the operating systems drivers have locked it.

> much universal if someone is looking for portability(I
> am more interested in writing to as few different target
> APIs on Windows as it is possible to do so).

Then use a wrapper. SDL and GLUT are very minimalistic.

>> Still you need the Win32 API (or DirectInput) to process the
>> actual input events. You can't circumvent this.
>
> Agreed to the extent that OpenGL does not by itself
> understand display-unrelated stuff, DirectX does.

DirectInput, but that is something completely different than
Direct3D. BTW: Many OpenGL games use DirectInput, as it provides
those kinds of input processing, that is important for games.

> The Window that the Windowing system (Win32) would be relied
> upon for creating can be an absolutely minimalistic Window
> whose sole purpose is to establish a bounds for the
> application which created that Window(resizing of Window
> and all that goes through the native API).

That's possible, but it requires more quirks, than letting the
operating system doing the whole stuff (you must process 4 more
events so that the windowing system knows, that the window has
been minimized/maximized/resized/hidden/revealed.

> I/O performance is very difficult to measure. I presume

User input is more than I/O, because on a modern operating system
you have multiple processes accessing user input at once.

> Is your modeller available as a free download :-) ?

It will be when we release our engine (actually the modeller is
using the engine's infrastrucure), but as the engine will later
be licenced we cannot release it yet. (Our licence is, that you
can freely download the engine's sources. As long as it is only
used in OpenSource and Freeware projects you don't have to pay
licence fees. For commercial use you will need a licence.
However at the current stage a release of the engines code not
allow for licencing as it is still incomplete. But OTOH some
people might try to harvest it because, what we have now is very
hardly to getting compiled (hundreds of yet undocumented
dependencies and other problems). Give us another year and we
will be ready to release).

--
Wolfgang Draxinger

mp2sleep@hotmail.com wrote:


> User Interaction is about mapping I/O "events"
> to coordinate positions on the Window, so I presume this
> is as straight forward as I/O.

The problem is: You won't be able to get access to the I/O
because the operating systems drivers have locked it.

> much universal if someone is looking for portability(I
> am more interested in writing to as few different target
> APIs on Windows as it is possible to do so).

Then use a wrapper. SDL and GLUT are very minimalistic.

>> Still you need the Win32 API (or DirectInput) to process the
>> actual input events. You can't circumvent this.
>
> Agreed to the extent that OpenGL does not by itself
> understand display-unrelated stuff, DirectX does.

DirectInput, but that is something completely different than
Direct3D. BTW: Many OpenGL games use DirectInput, as it provides
those kinds of input processing, that is important for games.

> The Window that the Windowing system (Win32) would be relied
> upon for creating can be an absolutely minimalistic Window
> whose sole purpose is to establish a bounds for the
> application which created that Window(resizing of Window
> and all that goes through the native API).

That's possible, but it requires more quirks, than letting the
operating system doing the whole stuff (you must process 4 more
events so that the windowing system knows, that the window has
been minimized/maximized/resized/hidden/revealed.

> I/O performance is very difficult to measure. I presume

User input is more than I/O, because on a modern operating system
you have multiple processes accessing user input at once.

> Is your modeller available as a free download :-) ?

It will be when we release our engine (actually the modeller is
using the engine's infrastrucure), but as the engine will later
be licenced we cannot release it yet. (Our licence is, that you
can freely download the engine's sources. As long as it is only
used in OpenSource and Freeware projects you don't have to pay
licence fees. For commercial use you will need a licence.
However at the current stage a release of the engines code not
allow for licencing as it is still incomplete. But OTOH some
people might try to harvest it because, what we have now is very
hardly to getting compiled (hundreds of yet undocumented
dependencies and other problems). Give us another year and we
will be ready to release).

--
Wolfgang Draxinger