Untitled

Package com.gameblend.engine Overview.

The com.gameblend.engine package contains all of the classes needed to create a Gameblend application or Applet. These classes combine together to create the shell structure used to manage the visible and logical aspects of a Gameblend application.

GameSystem

The GameSystem class is the master class for an application. It maintains the master references to all of the application's windows, threads, and global assets.

The GameSystem class must be extended to add in specific functionality for the underlying computer system on which the application is being run. The GameSytem then can be used to create compatible versions of all resources needed... eg) Windows, Graphics Contexts, Images, etc.

Each Gameblend application must have one and only one instance of a GameSystem. Once this instance is created, it is used to create and maintain all GBWindows and GameThreads required.

In addition, the GameSystem also provides the following functionality:

A central storage location for all loaded assets (images, text files, etc.) in the application.
Access to the system clock time of the underlying computer system.
GBEvent posting. Events posted to the GameSystem instance will be delivered to all event listeners in the application.
Provides storage for fake static variables. This allows for global values to be used in an Applet without the usage of static variables, which are handled in and inconsistant manner by different Applet environments.
Clean-up of all game data on exit.

If exit() is called on the GameSytem instance, all open windows are closed and the application is terminated. The GameSystem will also terminate if all application windows are closed.

GBWindow

A GBWindow represents a Window that displays data from the application. An application can have multiple GBWindows.

GBWindows are a container for DisplaySurfaces. Each window may have one or more DisplaySurfaces. Once surfaces are created, they cannot be removed or modified. DisplaySurfaces in the same window may not overlap.

When a GBWindow is closed, it's reference is removed from the GameSytem and all attached surfaces are destroyed. If the GameSystem has no more open GBWindows, then it will shut down after the last window is disposed.

Note: In general, each window will have only one DisplaySurface that fills its entire inner area. Multiple surfaces capability is provided for the rare cases when one of the two following scenarios is required.

Multiple GameThreads are required for surfaces displaying in the same window.
Two different surface capabilities are needed within the same window (eg, a GBT rendering surface and a Swing rendering surface).

Java Applet's are automatically created with one GBWindow (the browser window) filled with one DisplaySurface (the Applet area as defined by the Applet tag).

DisplaySurface

A DisplaySurface is a visual rectangle of screen real estate used to display the contents of the application. A DisplaySurface is always contained inside of a GBWindow.

The DisplaySurface class provides many methods for creating application objects, such as images, colors, and fonts. These objects must be created by the surface because they rely on the specific underlying native format of the actual surface. For example, a Swing DisplaySurface and a DirectX DisplaySurface would require different image formats in order to render an image to itself. In order to ensure compatibility, these objects are created and returned by the surface as needed.

Other than rendering to the screen, the DisplaySurface also provides a container for the logic and game loop elements in a game. Each DisplaySurface can have 1 GameThread, which controls the speed of the GameLoop for all GameModules displayed on the surface. A surface can have multiple GameModules, which are containers for application logic. For example, a surface could have a GameModule that represents the logic of a loading screen. Once the game is loaded, the loading module could shut down and start a GameModule that contains the actual game code. Multiple GameModules can run on the same surface at the same time. Any visual elements from multiple modules will overlap on the surface. The drawing order of sprites from multiple modules on a surface is determined by the order of attachment of the modules to the surface.

GameThread

A GameThread sets up a loop that will run no faster than the a set frame rate. This thread executes a GameLoop, which controls the timed logic path of a GameModule.

Once a GameThread is started, it can only be stopped by exiting the GameSytem, or removing all surfaces from it.

GameLoop

A game loop defines the specific order of logic for a GameModule to be run every game cycle (as defined by the GameThread that controlls the loop). For example, the default GameLoop does the following each cycle:

Removes any GameModules killed during the last cycle.

Distributes all cached events to all surfaces using the loop.

Updates all SafeThreads for all surfaces. The SafeThreads can be sorted into runtime orders required by any specific application.

Updates the dirty rectangle list for all surfaces controlled by this loop.

Causes the surfaces to be painted.

GameModule

A GameModule represents a basic logic block for an application. For example, one game module may be created for a loading screen. This module could create and load other modules, tracking their loading process. These other modules could represent input selection screens, toolbars, game screens, etc.

Each surface can have as many modules as needed. Multiple modules can be executed at the same time.

Each module maintains a list of sprites it needs to draw to the screen. This list determines the z-order of the drawing process. Modules also maintain a list of listeners for GBEvents.