You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Olivier D. <oli...@ca...> - 2002-07-19 14:57:43
|
In trying to work out some design for Gopher, I wrote the following requirement: - An effect has 0 or more input buffers and 1 or more output buffers. As an example, a plasma that is drawn from intersections of cosine lookups need no input buffers and will (usually) produce output for one output buffer. You control the plasma with a few parameters. There are also effects that manipulate/distort one input and produce one output. (ie: raindrop effect, overlaying a logo, etc..) Then there are effects that take two input buffers, blend them together somehow and produce one output. I've even written an effect that takes three input buffers and uses the first two to decide how to third one will be distorted/rendered in the output buffer. So far, all these effects have only had one output. I'm looking for a case where multiple outputs are necessary and would mean uncomfortable (impossible?) work-arounds if the requirement was re-written as: - An effect has 0 or more input buffers and exactly 1 output buffer ie: an effect that takes a RGB input buffer and produces an output buffer for each of the primary colours. Would it be the case that the three seperate "colour buffers" would be fed to three seperate effects or do they just end up being translated/offset from each other and then blended back, something the effect could have done on its own using only one input and one output buffer? It looks as though it would be easier if effects only had one output, because then we could tie the output to a track, a bit like DemoPaja ties effects to "Layers". This means authoring the output of an effect is implicit and all a user needs to do is wire the inputs, although my mind is blank as to a good/intuitive way of allowing users to do this in the same interface that they author effect parameters. (ie: should it be arrows crossing tracks or you pick numbers or it is based on the order of the channels or what?) ---------------------------------------------------------------------- Olivier A. Dagenais - Software Architect and Developer |
From: Olivier D. <oli...@ca...> - 2002-07-17 20:24:21
|
Hi gang! I'm really keen on doing the right things and doing things right, which is why I'm willing to put the development of the GUI on hold in order to make our lives easier. These are the flaws I have observed in the "GopherSample" release: -> there's a bunch of scattered files - this is partly due to the way the sample effects libraries were programmed (the "Mystic" library only loads images and it requires jpeg.dll, libpng2.dll, SDL_image.dll and zlib.dll to do this) - this is also due to the way the player was programmed: the script file and the music file have to be loose files -> OpenGL support is weak. - I don't even remember if I tested it or if I documented what is necessary to mix 2D and 3D effects along with SDL. Eric has done some tests for mixing 2D and 3D using only OpenGL, however because of the limits of 3D acceleration, it may not be as flexible as 2D effects with respect to how a demo can deal with a set of general-purpose framebuffers (ie: output of one effect as input of the other). Further research is required and then a convention must be designed so that effects libraries can interact with other effects libraries. -> Library meta-data - right now, the main script file holds information (in the "Libraries" section) that should follow a library, not a demo. Eric has done a few experiments on using OO to have the library describe itself, but that still requires that a programmer write it as such. It would be very good if there was a way for the editor to pick up the meta-data automatically by parsing a .h file or the .DLL exports directly -> Not ready to be used with popular players - I'd like to eventually have Winamp, Media Player and Internet Explorer plugins for this. I'm thinking there should be a way to download the demo on its own and have the player plugin fetch the libraries it wants. Maybe that's just a bit too crazy? Unless there's a way to talk to a DLL even if it isn't a file on the disk? (ie: if it's inside a ZIP file?) Or should we go the less elegant route and simply have a "scratch" dir that we uncompress the entire ZIP file to? We might as well start with the basics: defining requirements. 1 - A demo ships in one file (preferably ZIP) with a standard manifest. (if we use libzzip, it would be possible to use a ZIP file and a directory interchangeably) 2 - Effect libraries are reusable and self-describing. 3 - Effects are modular (can pick the inputs and outputs) and reusable (can use them several times in a demo or in many demos - so they have parameters to control their apperance). 4 - Accelerated 2D and 3D graphics don't require overhead. 5 - It is possible to mix 2D and 3D graphics as follows: 5.1 - The output of a 2D effect can be used as a texture in 3D rendering 5.2 - The output of a 3D rendering can be manipulated by a 2D effect 5.3 - The output of a 2D effect can be used as a background or foreground to a 3D scene 6 - Demos can run in any resolution or bit depth, to accomodate slower/faster machines. 7 - The editor provides multiple real-time previews. I'd like to read everybody's thoughts on those matters, no matter how crazy. :) ---------------------------------------------------------------------- Olivier A. Dagenais - Software Architect and Developer |