Digital Design
Contact Me
Bookmark & Share: Add to Favorites Share on Facebook Tweet This E-Mail a Friend Print this Page

Custom Software

Modular Software for Use in Applications

I maintain a library of general purpose software modules for use in my projects. There are literally hundreds of thousands of lines of original code that I have developed over the years. It can reduce development times for complex projects literally by years.

The following list gives an overview of some of the modules available.

 

Geometry Library

A general purpose geometric library, covering:
  • fixed point numbers, coordinate data types and arrays

  • geometric calculations:
    • triangle solutions
    • sector solutions
    • circle solutions
    • distance of a point from a line
    • interpolations of curves such as Bezier

  • 2D transformation matrix operations:
    • translation, scaling, rotation, reflection, shearing etc.

  • 3D transformation matrix operations:
    • translation, scaling, rotation, shearing etc.
    • 3D to 2D projections: perspective, axonometric, isometric, and oblique

  • geometric paths and path manipulations:
    • path construction
    • conversion of geometric primitives such as rectangles and ellipses to paths
    • matrix transformations of paths
    • insideness testing and clipping
    • simulating a line style
    • optimization of drawing order

Language: C++.

 

Media Channels

Supports the display and sequencing of images, audio, and video on PCs.

Language: C++
Supported File Types: BMP, GIF, JPEG, PNG, TIFF, MIDI, WAV, MP3, AVI, MPEG-1, MPEG-2

 

Color Conversion Library

Conversion between different color spaces such as RGB and CYMK.
Color to gray scale. Gray scale to bilevel (thresholding). Negative color images, negative gray scale, negative bilevel.

Language: C.

 

TGS

The Tiered Graphical Subsystem is a modular graphics subsystem, designed to dramatically reduce the work involved in developing high level graphics applications. It is the flagship of my development efforts.
Overview of TGS
TGS, the Tiered Graphical Subsystem is a modular, tiered or layered subsystem, designed to dramatically reduce the development work involved in high level graphics applications.

It effectively provides the 'missing link' between software processing data structures representing real world data and the graphical output system, generally some form of Graphical Device Interface (GDI) such as Microsoft Windows.

Most conventional GDIs concentrate on providing the graphical support required. However they generally give insufficient support when it comes to handling data structures that are capable of representing real world data. For example the coastline on a map should be able to be stored and processed as map grid coordinates at a scale of 1:1. The process of converting that data to pixels on the screen or to produce a printed page should not be the responsibility of the application program.

Many commercial CAD packages exist which allow this type of real world data representation and its conversion to displayed or printed output. Some have user programming facilities, and most support some form of file exchange. However the following reasons constitute the requirement for the creation of TGS:

  • Commercial CAD packages are marketed as a complete entity. They are not available as a modular subsystem that can be linked into an application program, or embedded in an item of hardware.

  • No commercial CAD packages support the animation facilities provided by TGS. TGS provides automatic and fast redrawing of graphics as status information is received, with a minimum of involvement by the application program. Real time 2D and 3D animation is supported.

  • No commercial CAD packages support a backward flow of information from the user operating the CAD software to the application program. For example this may be user's selection of a waypoint, or the positioning of a cursor symbol which gives its real world map grid coordinates to the application program.

  • TGS provides a single, consistent interface to the application program which is invariant under operating system and GDI changes. This allows easy porting of software to different platforms, with only some internal TGS modules being changed.

 

TGS - Overall Definition of Layers TGS is defined as an eight layer model.

The application layer describes the application program itself, as well as the TGS API and TGS API translation modules.

The organization and control layer describes organization and control operations within the TGS core, as well as application specific TGS modules and symbol libraries.

The 3D graphics layer describes the storage of 3D graphic primitives, and 3D editing facilities.

The 2D graphics layer describes the storage of 2D graphic primitives, and 2D editing facilities.

The resource layer describes the resources or drawing tools used by 2D primitives to produce graphic output - pens, brushes, fonts etc.

The GDI layer describes the TGS interface to GDIs such as Windows, and import and export modules for special device and file format interfacing. This layer also describes the GDI itself.

Generally the GDI layer, device driver layer, and hardware layer are external to TGS. This would be the case for example if Windows is being used for graphical output. However in some embedded applications all layers may need to be within the scope of TGS.

The power of TGS lies in its modularity. It has been designed to cover all conceivable combinations of environments - different GDIs, different operating systems, static or dynamic linking, embedded applications in special equipment, multitasking/multiprocessor architectures etc.

TGS is composed of a library of modules. Only those modules needed to provide the required functionality need be linked into the required application. This keeps the code size to a minimum.

 

Software Modules within TGS
The following modules are currently available:

2D API
TGS provides a standard Application Program Interface (API). This is a collection of functions providing:
  • session control
  • system control
  • drawing commands
  • information functions
  • dialog with the user

The TGS API is universal. It allows application programs to be written in device independent manner. TGS internally manages the interface to the GDI in use and the required import and export files and devices.

Language: C++, but has a C compatible function call interface.

 

2D Core
The 2D Core module provides all the functional elements central to TGS, and therefore must be present in all TGS configurations:
  • TGS SESSION OBJECT. Provides all of the functions required to start, operate, and close a TGS operating session. Generally one session object is used per application.

  • TGS SYSTEM OBJECT. Provides all of the functions required to start, operate, and close a single TGS image or window. These include: management of primitive and group tables, scaling, file operations etc. There may be multiple system objects per session.

  • RESOURCES. Provides the drawing tools required by the 2D primitives. These include pens for line drawing, brushes for area filling, and fonts for text.

  • 2D PRIMITIVES. These are the basic graphical units such as ellipses and rectangles.

  • GROUPS. Groups provide the mechanism of combining primitives into a larger entity. A group allows moving and editing of a set of primitives as if they were a single entity.

  • SYMBOLS. Symbols are a special kind of group designed for animation. They associate code that performs automatic editing with the group and primitives to be operated on.

Language: C++.

 

TGS Master DLLs
Provides Dynamic Link Library support for TGS under Windows.

Language: C++.

 

2D Windows GDI Interface
This module provides the interface between TGS and the Windows Graphical Device Interface (GDI).

It supports all versions of Windows. Selection between the different versions is accomplished by conditional compilation, controlled by the SYSDEF header.

This module is responsible for providing all Windows functionality associated with the scope of the 'limited editing' implementation of TGS.

Specifically it provides:

  • the ability to draw or redraw graphics in a window as required
  • a ruler and grid system for the displayed page
  • menu, mouse and keyboard processing to zoom and scroll around the page
  • Windows printing support
  • control dialog boxes for setting parameters in the module, such as Windows print mode parameters
  • common dialog boxes for use by the application program, eg. for obtaining page size and orientation information, scale mode and offsets

Language: C++.

 

TGS Windows Application Template
A generic template developed as a starting point for all TGS single document applications under Windows.

Language: C.

 

TGS Windows MDI Template
A generic template developed as a starting point for all TGS multiple document applications under Windows.

Language: C++.

 

The Object Oriented Architecture of TGS
TGS is built up of a collection of objects, with appropriate linkages and control structures between the different objects.

Although TGS is written using C++ and uses an object oriented architecture, it is not necessary for the application program to be written in C++. All API functions are duplicated using standard function calls compatible with languages such as C, Pascal, and Fortran.

 

TGS Session and System Objects:

TGCL_Session - the session object. This stores all the operational parameters for the current session.

Generally one session object is used per application.

TGCL_System - the complete TGS system object. Multiple objects allow multiple windows within an application.

The session and system objects provide the overall organization and control of TGS.

The session object has the job of managing a complete operating environment.

Generally there is one session object per TGS application running on the system. This approach allows dynamic link libraries to handle each separate application program individually. In addition it allows complex TGS environments to exist with multiple configurations running simultaneously, even in embedded equipment.

The system object has the job of managing a single drawing or display window.

 

Resources:

TGCL_Resource - generic TGS resource (drawing tool). (abstract class)

  • TGCL_Pen

  • TGCL_Brush

  • TGCL_Font

The resources used in a drawing are owned and managed by an individual system object. A resource table within the system object stores pointers to the resource objects.

 

2D Primitives:

TGCL_Primitive - Generic TGS primitive. (abstract class)

  • TGCL_CtrlPrimitive
    Control (non-drawing) primitive. (abstract class)

    • TGCL_PlaceHolder
      used to mark a deleted table entry

    • TGCL_SetRealUnits

    • TGCL_SetRealWindow

    • TGCL_SetScale

    • TGCL_SetPagePosition

    • TGCL_SetRotationAngle

    • TGCL_SetGrid

    • TGCL_SetTabRuler

      • Scaling and positional parameters may be changed multiple times on a single drawing sheet.

  • TGCL_GrPrimitive

    Graphic (drawing) primitive. (abstract class)

    • TGCL_Point

    • TGCL_Line

    • TGCL_Polyline

    • TGCL_Arc

    • TGCL_Rectangle

    • TGCL_RoundRect

    • TGCL_Ellipse

    • TGCL_Pie

    • TGCL_Chord

    • TGCL_Polygon

    • TGCL_Path

    • TGCL_Text

    • TGCL_Bitmap

A primitive table within the system object stores pointers to the primitive objects. Each time the drawing or display image is processed, the table is scanned from start to finish. Hence primitives later in the table can overdraw those earlier in the table.

Control primitives are not displayed, but pass commands to the system object. These are generally used for changes to the scaling system. Complex drawings can have multiple groups of control primitives and graphic primitives. This allows different parts of a drawing to be scaled and positioned separately.

Graphic primitives are used to produce the images. All standard geometric elements are provided as well as paths and bitmaps.

A path is a compound curve, generated from series of line segments, arcs, and bezier curves. Paths may be closed, and filled with a brush as required. Multiple sub-paths can exist per path.

A bitmap is a scanned image containing pixel data. The bitmap primitive stores the pixel data, a color lookup table for 1, 2, 4, and 8 bit per pixel formats (not required for the 32 bit full color format), and floating point coordinates storing the corners of the bitmap for scaling and positioning.

 

Groups and Symbols:

TGCL_Group (concrete class)

  • TGCL_Symbol (abstract class)

    • inherited by all symbols

A group is a collection of primitives that can be operated on collectively for editing purposes.

Symbols are a special class of group. They are individually written objects that control the operation of one or more primitives, generally for animation purposes.

One example of a symbol is a special form of text that remains upright, regardless of display rotation. When the display is updated this symbol reads the rotation angle of the display and sends a command to the text primitive it owns to rotate it in the opposite direction.

 

Data Storage and the Scaling System used within TGS
All primitives store their coordinates at two levels:
  • double precision floating point numbers relating to coordinates in the real world
  • integers relating to units on the output device

This approach provides the highest level of flexibility for scaling, coupled with the highest possible display update speed for repaints, panning, and animation.

A regeneration operation is performed as required to calculate the device unit coordinates from the real coordinates. For very complex drawings this can take a few seconds, so special techniques are employed to regenerate what will actually be within the display window first, followed by what will be outside the window.

TGS uses a comprehensive 4 tiered coordinate scaling system, and uses 3x3 matrices to perform the conversions between the different coordinate systems.

This scaling system allows the application program to use one or more real coordinate systems which are in context with the graphics being processed. eg. mapping info can be defined in terms of the map grid in use. The scaling system then allows for page placement, special print operations such as multipage printing, and translation to the coordinate system required by the output device.

Control primitives may be placed throughout the primitive table to dynamically change the scaling and placement of graphics throughout a drawing.

 

Platform Independent Binary Format

The Platform Independent Binary Format is a universal byte-oriented data storage and transfer format.

It was originated by Digital Design Ltd. in February 1994 to provide a 'future-proof' means of storing and exchanging data between different software applications and equipment.

PIB is essentially a standardized wrapping around a family of data formats, which allows the data to be stored or transmitted over any carrier and restored to a known format at the receiving end.

It has been specifically designed for:

  • equipment and software to be developed in a 'future-proof' way, where new developments can be accommodated by the format without making it incompatible with previous formats
  • storage on any byte-oriented media
  • automatic file or data exchange between any two incompatible computer systems
  • transmission over any communications link, including asynchronous serial, synchronous serial, LAN and WAN networks
  • transmission over 7 bit carriers as well as 8 bit
  • files and data to be able to be read and written in a purely text form. Data transmissions can therefore be captured by any communications program and treated as text. The text file can then be read and processed as required.

Use of the PIB format inherently causes the software reading or writing the data to be separated from the transmission or storage method used. The transmission or storage software is likewise separated from the application software as it need have no knowledge of the internal data formats used. This is a valuable aid to software development as libraries supporting different transmission methods can be developed and used for all applications using the PIB format.

PIB is compatible with all known carriers and storage methods, including asynchronous serial, synchronous serial, networks conforming to the OSI, TCP/IP or ATM standards, and storage as a file format or in memory.

Its use can also be easily adapted to currently unknown carriers.

Language: C++, but has a C compatible function call interface.

 

Server Abuse Control

This is a program which runs on web, ftp, and mail servers, and detects abuse such as denial of service (DoS) attacks. All sources of abuse are automatically firewalled without any intervention from a system administrator.

Language: C++

 

System Status Monitoring

Automatically monitors the health of individual machines and subnets, for viruses, connectivity problems etc., or unusual network activity. It alerts the system administrator when a problem is detected.

Language: C++

 

Mailroom

This is a utility program which runs on mail servers to provide SPAM filtering and a challenge/response mechanism to identify genuine senders.

Language: C++

 

Network Library

Provides a range of networking support features for both Linux and Windows machines.

Language: C++

 

CGI Library

Provides support for CGI software on web servers.

Language: C++

 

DDL Installer

This is a set of client-side and server-side modules which provides the ability to download, update, and repair installations of consumer software products on client PCs.

Language: C++

 

Commercial Application Licensing (CAL)

This is a set of client-side and server-side modules which provides the copy protection, licensing, and payment mechanisms for consumer software products.

Language: C++

 

Time Zone Library

Provides time zone and location information and conversion functions for software such as Time Zones for PCs®.

Language: C++

 

Compression Libraries

A range of interchangeable libraries providing data compression and expansion routines for many of the popular formats.

Language: C.

 

Input/Output Communications Module

Interrupt driven, software buffered, serial and parallel communications. Includes LED drivers to indicate data transfer status.

Languages: 80X86 ASM and Z80 ASM.

 

Assembler Macro and Subroutine Libraries

These are general libraries of assembler routines used for embedded control applications.

Specific areas include:

  • multitasking executive
  • error and fault handling
  • CRT and LCD display control
  • keyboard input
  • ASCII to binary, binary to ASCII string conversions

Languages: 80X86 ASM and Z80 ASM.

 

DDL General C Library

This is a general library of C routines used in all Digital Design Ltd. application software.

Specific areas include:

  • delays
  • multitasking support
  • system and internal error handling
  • rounding operations
  • universal unit conversions, including compound units, for example converting rad/sec to deg/hour
  • fractions
  • console and file operations
  • equipment configuration testing
  • memory allocation
  • debugging tools

Language: C.

 

DDL General C++ Library

This module provides C++ extensions to the general C library.

Specific areas include:

  • dynamic arrays
  • string operations
  • matrices and simultaneous equations
  • configuration scripts, allowing config data to be stored in files, RAM, or ROM
  • debugging tools

Language: C++, but has a C compatible function call interface.

 

DDL General Windows Library

Functions common to all Windows programs.

Language: C++.

 

Windows Application Template

A generic template developed as a starting point for all single document applications under Windows.

Language: C.

 

Windows MDI Template

A generic template developed as a starting point for all multiple document applications under Windows.

Language: C.

 

  Back