Re: opengl and gephex

> - There is one Core class. This class wraps every call there is (or
> every call that is used) of opengl (Note: this could be any rendering
> system). 

There is always just one object of that gl_core class. That object is a
wrapper to all hardware rendering devices in the systems. There is only
one module(0.4) or unit(0.5) that can access that singleton instance.
(create_gl_core_module)

> This core is handed over to every module that is a "GLModule".

We need a new type(0.4) or link type(0.5) that hold a reference to that
core. (gl_core_type) All modules (gl_*_module) that need access to the
hardware rendering subsystem need a input with that type. All inputs of
that type need to be connected to the create_gl_core_module. These
connections can be made automatic by the user interface.

> Hence, the module can use gl with no effort soever by just calling the
> corresponding functions from the core.

> - GL modules will have an arbitrary number of inputs/ouputs, each of the
> type Texture, which will be RenderTexture for outputs and generic
> Texture for inputs (RenderTexture subclasses Texture). 

Resources like textures are transfered via id types. E.g a mixer module
gets two texture buffer inputs and one texture buffer output. The
resource ids of the output texture can be used to set the render target
via the gl_core object.

inputs: gl_core, gl_texture, gl_texture, numbertype
outputs: gl_texture

> Thus easy
> rendering via Input_texture->Set(); and Output_texture->SetActive();
> will be possible (this would in the case of opengl bind a texture to a
> certain stage and set Output_texture as an active rendertarget). (this
> is still just a draft, so thoughts are welcome). 

gl_core->texture_input_set(in_tex_1)
gl_core->texture_output_set(out_tex_1)

> Every Module can expect
> their inputs/outputs to be initalized (Texture(Core*)). (Note: this has
> to go into 0.5 since this is heavily concerning  the implementation of
> links).

Only the gl_core object know the implementation of the resource types.
It can and must initialize them lacy with the first access.

> - The engine will handle the auto-connection of core to every mdule that
> requires it...or the module writer has to take care of that theirself
> (this discussion vaporized somehow, but since 0.5 doesn't hold any
> states...should be not too hard to work this out though)

This can be solved at a higher level like the gui in 0.4 and the
schemelayer in 0.5.

> - OS-specific things go into IRenderWindow. This class takes care about
> things like rendering contextes, pixelformats, devices and whatsoever.
> This will be passed to the Core class mandatory (initialized) and will
> take care of system specific implementations of how to set up a window
> which opengl can render to. An output module will merely be a wrapper
> around an IRenderWindow able to query/modify all essential parameters
> and issue a blit call.

E.g. the "outputmodule" that copies a hidden texture in a visible window
  needs access to that subsystem.

> - If this isn't clear by now: All rendering input will be rendered into
> a rendertarget output (texture). The core will query extensions and
> determine the fastest way to do this.

The gl_*_modules manipulate data in the GPU. The framebuffer data is
transfered to the GPU with a modules that creates a new texture buffer
in the GPU and returns the texture id.

Martin

_______________________________________________
gephex-devel mailing list
[email protected]
http://lists.gephex.org/mailman/listinfo/gephex-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCqsXeCm3i57PRsbsRAgOSAJ0cr+jUcrFfJPJwFRpfzUnvDqUJNgCgsz8l
HtxdBouCOdbvUa32ucJedbs=
=NKMr
-----END PGP SIGNATURE-----