Windowing(DirectX/OpenGL)

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

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

Well, wording like that does seem to be a little pedantic Phil... They
weren't 'slapped together' and they're not 'unrelated.' They're all related
to game development, they just solve different aspects of the overall 'game
development' issue.

> To compare apples to apples, you need to
> compare OpenGL to Direct3D, and Direct3D knows nothing about input or
> windowing any more than OpenGL.

OpenGL compares to DirectX Graphics, there is no longer a "Direct 3D"
component of DirectX.

WTH

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

Well, wording like that does seem to be a little pedantic Phil... They
weren't 'slapped together' and they're not 'unrelated.' They're all related
to game development, they just solve different aspects of the overall 'game
development' issue.

> To compare apples to apples, you need to
> compare OpenGL to Direct3D, and Direct3D knows nothing about input or
> windowing any more than OpenGL.

OpenGL compares to DirectX Graphics, there is no longer a "Direct 3D"
component of DirectX.

WTH

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

Well, wording like that does seem to be a little pedantic Phil... They
weren't 'slapped together' and they're not 'unrelated.' They're all related
to game development, they just solve different aspects of the overall 'game
development' issue.

> To compare apples to apples, you need to
> compare OpenGL to Direct3D, and Direct3D knows nothing about input or
> windowing any more than OpenGL.

OpenGL compares to DirectX Graphics, there is no longer a "Direct 3D"
component of DirectX.

WTH

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

You can very easily program the mouse by handling
the WM_LBUTTONDOWN, WM_MOUSEMOVE, ... messages.

Likewise for every other non-display I/O device.

Thus, the combination of OpenGL(for display) & Win32
mouse, keyboard works.

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

You can very easily program the mouse by handling
the WM_LBUTTONDOWN, WM_MOUSEMOVE, ... messages.

Likewise for every other non-display I/O device.

Thus, the combination of OpenGL(for display) & Win32
mouse, keyboard works.

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

You can very easily program the mouse by handling
the WM_LBUTTONDOWN, WM_MOUSEMOVE, ... messages.

Likewise for every other non-display I/O device.

Thus, the combination of OpenGL(for display) & Win32
mouse, keyboard works.

stafygrahics@yahoo.com wrote:

>> The problem is: You won't be able to get access to the I/O
>> because the operating systems drivers have locked it.
>
> You can very easily program the mouse by handling
> the WM_LBUTTONDOWN, WM_MOUSEMOVE, ... messages.

That is not I/O, that is called event processing. I/O would be if
you'd use raw access to the hardware (i.e. writing a driver).
Ok, in Linux you _can_ access /dev/input/mouse* but that is
already an abstracted interface, where the whole I/O process
already has been done for you.

--
Wolfgang Draxinger

stafygrahics@yahoo.com wrote:

>> The problem is: You won't be able to get access to the I/O
>> because the operating systems drivers have locked it.
>
> You can very easily program the mouse by handling
> the WM_LBUTTONDOWN, WM_MOUSEMOVE, ... messages.

That is not I/O, that is called event processing. I/O would be if
you'd use raw access to the hardware (i.e. writing a driver).
Ok, in Linux you _can_ access /dev/input/mouse* but that is
already an abstracted interface, where the whole I/O process
already has been done for you.

--
Wolfgang Draxinger

stafygrahics@yahoo.com wrote:

>> The problem is: You won't be able to get access to the I/O
>> because the operating systems drivers have locked it.
>
> You can very easily program the mouse by handling
> the WM_LBUTTONDOWN, WM_MOUSEMOVE, ... messages.

That is not I/O, that is called event processing. I/O would be if
you'd use raw access to the hardware (i.e. writing a driver).
Ok, in Linux you _can_ access /dev/input/mouse* but that is
already an abstracted interface, where the whole I/O process
already has been done for you.

--
Wolfgang Draxinger