Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2005:
[Freeciv-Dev] Re: Using opengl in ftwl
Home

[Freeciv-Dev] Re: Using opengl in ftwl

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Using opengl in ftwl
From: Per Inge Mathisen <per@xxxxxxxxxxx>
Date: Thu, 24 Mar 2005 19:07:47 +0000 (GMT)

On Thu, 24 Mar 2005, Raimar Falke wrote:
> > ftwl has a z-dimension for windows, which is nice. However, ftwl uses a
> > 'pixel buffer' method for drawing which is hard to use with OpenGL. The
> > changes necessary to fix this may not be very large, though. All we need
> > is to turn the 'off-screen drawing area' which is blitted onto a final
> > composite in a z-order into an 'on-screen drawing area with a
> > z-dimension'.
>
> Any idea how this can be done?

Yes, in the following paragraph:

> > This means we need a clear separation and abstraction between unchangable
> > graphics sources (textures) and the destination (the OpenGL back buffer).
> > In ftwl this separation is not yet present.

1. We need to separate out the back buffer as a special case, instead of
as any other osda as it is now.

2. We need to add a clear separation between "constant" graphics sources
and the "target" buffer, which is either a number of pixel buffers (ftwl
as of now) or a 3D drawing buffer (OpenGL).

3. Dirty rectangles must be optional. OpenGL has no use of it, since it
redraws everything anyway.

> In general: a window widget has a OSDA as the backing store. All
> elements of the window draw on this. The window than may draw into the
> parent backing store. There is a root window.
>
> No idea how this can be supported with opengl.

Instead of drawing into a pixel buffer backing store, the OpenGL backend
would draw directly into the OpenGL back buffer, with scissors testing so
that anything that falls outside the window dimensions is cut. The given
z-dimension would allow OpenGL to do its own z-ordering of the drawing.

> > The code using be_is_transparent_pixel() needs a different mechanic
> > altogether (it is used to find click-throughs on windows).
>
> How?

I don't know. Is it really necessary? From what I can tell, we could
instead assign click-through-ableness as a property of the window, instead
of each pixel. We are not likely to have large, non-rectangular objects
that need precision clicking.

  - Per




[Prev in Thread] Current Thread [Next in Thread]