The Datafile PD-CD 4/DATAFILE_PDCD4.iso/utilities/utilst/texturgdn/!TexturGdn/Docs/Technical

Text File | 1996-09-28 | 17.9 KB | 352 lines

                         Technical details
                         =================

Topics : 01 Alternative animation viewers
         02 Exporting textures as JPEGs
         03 Creating 16 and 24 bpp files
         04 Menu tree conventions
         05 Animation Types - details
         06 Animation Types - file format
         07 The Mutator
         08 Breeding
         09 Three dimensional sculpting
         10 Dithering
         11 Resizing
         12 Batch processing
         13 Using !ChangeFSI

01 Alternative animation viewers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A word about alternatives to the animation viewing facilities provided.

Among the available Freeware on the platform are "!Picture" (written by mz
Sophie Wilson and available from Acorn's FTP site) and "!Player" (Version
1.00 by Emmet Spier in 1990).  "!Picture" does not cache sprites, but is
simple and neat.

"!Player" works well.  It is slightly faster than my own player due to its
use of optimised plotting routines, it can scale plotted sprites and it has
several other nifty widgets.  It needs to be fed a single sprite file, and it
takes its palette from the first sprite in the file.  This means you will
probably need to load the first sprite of an animation into !Paint, give it a
palette, and then drag in all the other sprites, before saving the result.

"!Picture" too uses the default mode palette if none is specified by the
sprite files.  One way of getting around this is to use the !ChangeFSI
post-processing provided by Texture Garden which automatically adds the
current desktop palette to the file.  Simpler, perhaps is to edit
"!Picture"'s !RunImage program as follows:

3250 spx%=-1:FOR Q%=0TO255:IFpixtrans%?Q%<>Q% spx%=pixtrans%

needs to be changed to:

3250 spx%=-1:FOR Q%=0TO255:REMIFpixtrans%?Q%<>Q% spx%=pixtrans%

or similar (spx% should wind up as -1).

02 Exporting textures as JPEGs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The fact that the program has a back-end interface to !ChangeFSI enables
textures to be exported as JPEGs.  This is useful for use with World Wide Web
pages.  JPEGs are usually to be preferred to GIFs for backgrounds as they
have excellent colour depth and can be compressed very well.  Browsers
lacking JPEG support are now rare.  Some synergy between the Fourier
Transforms used by Textures Garden and the Discrete Cosine Transform used by
JPEG may be partly responsible for this.  Compression is especially important
for backgrounds as they are usually drawn first and must be downloaded before
any navigation of the page can occur.  This is not true of other images as long
as "width=" and "height=" are specified in the <img> tags.

There is explicit support for exporting JPEGs in the program.  Usually the user
can just set the !ChangeFSI option and then select which JPEG options are
required.  These options are overridden by any JPEG output commands specified
in the options string.  For further documentation on the "JPEG" and "JPEGMONO"
options, information is available inside !ChangeFSI.

Unfortunately, although the Computer Concepts "Colour Card Gold" graphics
hardware is fully supported by Texture Garden, !ChangeFSI (v.1.15) does not
recognise the CC-style 16bpp sprites and consequently fails to convert them
to JPEGs correctly.  It seems to be confused about the aspect-ratio and the
colour-depth.  The aspect-ratio problem can be overcome using some of
!ChangeFSI's resizing options, but colour-depth problem seems insoluble and
the resulting washed out images are of little use.  Fortunately, a solution is
at hand.  Texture Garden has options for forcing output to be in 16 or 24 bit
colour.  When using these options, the output format follows Acorn's format,
and consequently, !ChangeFSI can deal with the sprites.

When outputting images as JPEGs, it is important to make sure that you generate
them at a high colour depth in the first place.  Using the force 24bpp option is
recommended.  This is because JPEGs are 24 bit images, and using less than 24
bits in the source image actually generates larger files because the colour
quantization is seen as sharp edges which do not compress well.

03 Creating 16 and 24 bpp files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Texture Garden allows the export of 16 or 24 bit colour sprites from any display
mode.  Old machines will have difficulty displaying these sprites, but they are
recognised by !ChangeFSI.  Versions of RISC OS prior to version 3.5 are too
primitive to display these "deep" sprites.  Fortunately, a patch for the
operating system is available to allow them to be viewed as dithered images on
older hardware.  This is called "Deeper" and is written by Sanjay Pattni.
This patch is a module, and it was distributed recently on September's Acorn
User cover disc.

The versions of the DragASprite module currently in existence do not seem to
operate correctly on these deep images.  If this does not look as though it
will be rectified, reverting to dash boxes may be implemented.

Note that palette images are always created in the current mode, and are always
displayed without any dithering.  In modes with low colour depths they may
often look like broad bands of colour.  This is deliberate, so that the may be
distinguished from palettes with dithering or high-frequency noise in them.

04 Menu tree conventions
~~~~~~~~~~~~~~~~~~~~~~~~
When navigating through the palettes directory or the directory of animation
types using the menu structures provided, some conventions are used for the
sprites that are displayed on the left-hand side of the menus.

Normally the sprite naming conventions are as follows:

         File(S)    File(L)   Directory(S) Directory(L) App(S)  App(L)
Plain   :small_abc  file_abc  *name        #name        sm!xyz  !xyz
Selected:small_abc² file_abc² *name²       #name        sm!xyz² !xyz²
NoName  :small_xxx  file_xxx  small_dir    directory    sm_app  application
NoNameS :small_xxx² file_xxx² small_diro   directoryo   sm_appo applicationo

Small sprites are used when they are available; otherwise the large sprite is
scaled.  If the selected version of the sprite is not available then the base
sprite is inverted.  Conventions taken from !FilerPtch are also used.  In
particular, "hidden" files are not displayed, to support the local directory
display options of that program.

When selecting items from the menus, pressing SHIFT or ALT will alter the
effect produced.  Generally SHIFT-clicking will load the file into a text
editor, and ALT-clicking will open a Filer window onto the directory
containing the selected item.  In the case of directories, clicking usually
opens the parent of the directory clicked on.  SHIFT-clicking instead will
open the selected directory itself.

05 Animation Types - details
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Animations are generated mainly by altering the phase of the pseudo-random
noise which is used in conjunction with filters when performing
fast-fourier-transforms.  Different frequencies are affected differently and
the "Animation Type" specifies the way in which different frequencies are
affected.  Animation Types consist of a series of 1024 signed 4-bit values
which are used as multipliers of the "animation phase" of different
frequencies.  The animation phase is considered as coung from &0 - &FFFF, ie
through one complete cycle in any animation.  If the phase multipliers are
large then the animation will be violent and rapid.  If the multipliers are
zero for all low frequencies then the animation will appear as a series of
small ripples distorting a largely static display.  If the multipliers are
zero for all high frequencies then the animation may look like big waves
distorting an intricately patterned tapestry.  Many different types of
animation are possible using this method.

The "Texture Programmer" may design his own type of animation by using the
"AnimationFrameNumber" variable which changes from &0 to &FFFF during the
animation's course.

Two textures which look exactly the same may animate in different ways even
if the same animation type is chosen; how they animate depends on their
constitution, not on their appearance.

06 Animation Types - file format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Animation Types are stored as 512 byte files in the "Animatons" directory
within Texture Garden.  Source for an example file is contained in the
"Library.Source.Animations" directory.

The files are made up of 1024 signed 4-bit values.  Low frequency multipliers
are stored first within each byte the lower frequency is in the lower bits
(little endian).

07 The Mutator
~~~~~~~~~~~~~~
When texture Garden mutates a texture into another one, its operation is
quite simple.  It goes through the file and alters some of the numbers in the
texture generation file.  The numbers are chosen according to the "mutation
options" of the last command or function of the program.  These mutation
options are specified by the programmer of the function.  Their possible
values are listed in the "Extensions" file.

08 Breeding
~~~~~~~~~~~
When two textures are mated with one another the program examines the code of
the two textures for the "CreateTwoDimensionalTransform" and
"CreateOneDimensionalTransform" commands.  Breeding mainly affects this type
of command.  If one of the textures lacks both of these commands, then the
two textures will be unable to breed.  For a texture to be fertile, it
follows that it should always contain some such command.

For each occurrence of one of these commands in the "Mother" texture (paying
heed to the "Mutate Colours" and "Mutate Textures" options) a random
parameter of the command is chosen and deleted.  If this parameter is a
function, then all its arguments are also deleted.  A chunk of code is taken
at random from a "Create...Transform" in the "father" code.  This is then
spliced along with any relevant parameters into the mother code at the chosen
point.

The above mechanism allows textures to be of both sexes.  Note that almost
the entire code comes from the "mother" texture, with the father donating a
tiny quantity of code.  At the end of the breeding, the offspring is always
given a new seed (for the pseudo-random number generator).

09 Three dimensional sculpting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Support is provided for the production of three dimensional textures.  These
are of use when textures need to be moulded to the surfaces of solid objects.
The most frequent application of this is when a texture is required that can
be moulded around the surface of a sphere.

The two commands "DefineSolidBlock(Block_Description)" and
"Sculpture(Path_of_X,Path_of_Y,Path_of_Z)" are used to perform this type of
action.

The "DefineSolidBlock" command defines a solid block of texture in three
dimensions.  "Block_Description" is a function of X,Y, and Z which usually
refers to various buffers using the "Point"-type commands.

The "Sculpture(Path_of_X,Path_of_Y,Path_of_Z)" command sculpts a solid shape
from the solid block of texture described in the last "DefineSolidBlock"
command encountered.  The parameters, "Path_of_X", "Path_of_Y", "Path_of_Z",
define a mapping between X and Y and the three dimensional space.  They are
functions of X and Y.  The resulting shape is stored in the main two
dimensional buffer.  It is usually best to enclose these commands inside the
"StopMutating" and "StartMutating" pair.

One version of the command that defines a sphere is:

Sculpture(
ScaledSignedMultiply(SignedCos(X),Absolute(SignedCos(LogicalShiftRight(Y,&1)))),
SignedCos(LogicalShiftRight(Y,&1)),
ScaledSignedMultiply(SignedSin(X),Absolute(SignedCos(LogicalShiftRight(Y,&1)))))

This is written on three lines to reveal its structure.  It is still quite a
mouthful.  The advantage of specifying the shape explicitly is one of
flexibility.  Smaller and larger spheres are possible, as are different
shapes.

10 Dithering
~~~~~~~~~~~~
The dithering patterns used by the program involve a number of types of
simple random dithering.  The dithering used means that the same degree of
dithering is used in all screen modes.  It you use a lot of dithering to make
a grey image look good in a sixteen colour mode, then it will not look much
better when changing to a sixteen million colour mode.  A command such as:
"If IsLessThanOrEqualTo(LogBitsPerPixel,&2) Then Dithering(&4000) Else If
IsEqualTo(LogBitsPerPixel,&3) Then Dithering(&2000) Else Dithering(&0)" may
be used where this is inappropriate.  I may implement a "ScaledDithering()"
command to replace the above contraption, but for the moment, it provides
maximum flexibility.

The dithering technique used also means things can appear with slightly
different tints in 16 and 256 colour modes.  Using the command
"Dithering(FloydSteinberg)" should make the program use Floyd-Steinberg
dithering, but this is a feature that does not yet work.

For users who must have Floyd-Steinberg dithering, it is currently possible
to implement this by generating the texture using no dithering in a mode with
deep colour and then using the interface to !ChangeFSI to do post-processing
in a mode with limited colour depth.

11 Resizing
~~~~~~~~~~~
There is something fundamentally square (literally) about the way in which
Texture Garden produces its extures.  The reason for this is the technical one
that it is often faster to calculate FFTs at a size which is a power of two and
then resize the result, than to do a FFT at the desired size.  If you want
textures that are not square then there are several options available:

If the resized image needs to be displayed for selection in the Texture Garden,
then using the built in resizing commands is strongly recommended.  This is
most easily performed by using the "Resize" command an conjunction with the
"ResizeSprite" command which are provided specifically for the purpose of
resizing textures.  This is the recommended method of resizing textures, and it
is the one used by the front-end provided for this purpose.

If a resize by XFactor and YFactor is required where
(0 < XFactor < &10000, 0 < YFactor < &10000) then a...
"Resize(XFactor, YFactor)" may be issued immediately before any "MakeSprite"
commands are encountered, and a...
"ResizeSprite(XFactor, YFactor)" needs to occur just before the texture program
terminates.

For the very technically minded the "ResizeSprite" command merely calls the
"TruncateSpriteVertically(Y1,Y2)" and "TruncateSpriteHorizontally(X1,X2)"
commands with their first parameter as zero.  These commands operate on the
sprite generated by the program, chopping off its edges.  Note that although
X1, X2, Y1 and Y2 range from 0 to &FFFF, X = 0, Y = 0 is at the bottom
left-hand corner of the sprite and not, as usual, in the middle of the texture.

Equally technical: when the "Resize" command is issued three commands are built
and issued.  They are roughly as follows
"TwoDimensionalShift(&8000,&8000,Overwrite)"
"TwoDimensionalProcess(0,0,XFactor,YFactor,TwoDimensionalPoint(
   Combine(Multiplication,&40000 DIV XFactor,LogicalShiftRight(X,&6)),
   Combine(Multiplication,&40000 DIV YFactor,LogicalShiftRight(Y,&6))),
   Overwrite)".
"TwoDimensionalShift(&8000,&8000,Overwrite)"
This is close to what is actually used to resize the texture.
When corresponding  "TruncateSpriteHorizontally(&0,XFactor)" and
"TruncateSpriteVertically(&0,YFactor)" are issued, the resulting image should
tessellate, be the right shape and size and breed properly.  It will also
be faster than if the resizing was done using !ChangeFSI, and will have had
anti-aliasing techniques applied to it before translation to the current
colour depth (better).

There are alternative methods available for resizing textures.  It is possible
to resize manually by loading the generated sprite into a bitmap package and
then trim it or resize it to the required size.  Trimming will clearly
prevent seamless tesselation.  Resizing will preserve this, but may introduce
some distortion.  One of the better ways to resize a resulting image is to
use the scaling options of the !ChangeFSI post-processing available.  Using
something like: "**#r 13:16 11:16 -nomode" would produce the desired effect.


12 Batch processing
~~~~~~~~~~~~~~~~~~~
Batch processing is supported by Texture Garden.  If a textfile is dragged to
the icon bar with the appropriate syntax, then it is used as a list of
textures to be processed.  The syntax required for each line is as follows:

<infile> <outfile> <size>

where infile is the path of a texture generation file, outfile is where the
resulting sprite should be written to, and size is the desired size of the
texture to be output.  This should always be a power of two.  Comments are
allowed in batch files and they are taken to be any line starting with a "|".

The reason this has been supported is to allow maximum flexibility for those
wishing to animate their textures.  It is in principle possible for users to
machine generate a whole series of textures and then process them in bulk.
Users who want to animate their textures in time with music (for example) may
take a series of parameters from a MIDI source, a tracker file, or directly
from the frequency spectrum of music sample and then use these as parameters
when generating an appropriate texture.  If you are engaged in this type of
activity, the author would be very pleased to hear from you.

13 Using !ChangeFSI
~~~~~~~~~~~~~~~~~~~
Post-processing of saved sprites and animations may be controlled by ticking
the "Use !ChangeFSI" option.
Two system variables are defined when using !ChangeFSI post processing of saved
sprites: "<TextureGdn$File>" which contains the path of the existing sprite
file and "<TextureGdn$Leaf>" which contains the leaf name from the same file.

The !ChangeFSI-associated string provided contains the command line options
required by this program.  Two special characters are used: "*" and "#".
Using "*" inserts "<TextureGdn$File> " into the command line string at that
point and "#" inserts a string corresponding to the current mode.

The default setting for the string is "**#r -nomode".  This means that the
existing sprite is overwritten and that processing is performed in the current
screen mode.

For further documentation on the options available, information is available
from inside !ChangeFSI.