SState aggregates all the state variables of OpenMortal that do not belong
to the backend. This includes transient variables such as the current
game mode (e.g. SStade::IN_DEMO) and configuration variables (such as the
keyboard layout).
-The SState variables are manipulated by the CMenu.
+SState is a singlular object, and is accessed with a global pointer,
+g_oState. All other frontend modules access the state through this object.
+The state is made persistent through it's methods, Load() and Save().
+Load() is called on program start, Save() is called when the program exits.
+
+
+The State is the way the CMenu communicate with the rest of the system.
+For example, if the user chooses "Quit" from the menu, the m_bQuitFlag is
+set to true, and the program will react accordingly.
+
+
+The state's most important properties are:
+
+\li m_enGameMode: The mode changes when a game is started or the game ends
+(either in the GameOver screen, or via the "Surrender Game" menu option).
+\li m_bQuitFlag: This is set if the program receives a quit event from the operating system (e.g. KILL signal, window close event, etc), or the user chooses "Quit" from the menu. Once the quit flag is set, the program will abort. All main loops check the value of the quit flag, and will break as soon as it is true.
+\li m_bFullScreen: Quite simply, it is true in fullscreen mode, and false in windowed mode. The user can change this via the menu. The State's ToggleFullscreen() method will switch between fullscreen and windowed mode. Maybe this functionality doesn't belong to the State? ...
+\li Sound properties: Mixing rate, number of channels, volume, etc.
+\li m_aiPlayerKeys: A double array of each player's keys. This is used most often in processing SDL key events: if the event's keysym matches a value in m_aiPlayerKeys, that means that a meaningful key was pushed or released.
*/
struct SState
{
enum TGameMode {
- IN_DEMO,
- IN_SINGLE,
- IN_MULTI,
- IN_NETWORK,
- IN_CHAT,
+ IN_DEMO, ///< The game is currently in "demo" mode: displaying the intro screens, etc.
+ IN_SINGLE, ///< The game is in single-player mode.
+ IN_MULTI, ///< The game is in multi-player mode.
+ IN_NETWORK, ///< There is against a network opponent in progress
+ IN_CHAT, ///< The user is on MortalNet
} m_enGameMode;
bool m_bQuitFlag; // true if quit event came
const char* m_pcArgv0; // Set by main to argv[0]
// CONFIGURATION VARIABLES
int m_iNumPlayers; // The number of players =2
enum TTeamModeEnum {
Team_ONE_VS_ONE,
Team_GOOD_VS_EVIL,
Team_CUSTOM,
} m_enTeamMode; // Team mode
int m_iTeamSize; // The size of each team.
int m_bTeamMultiselect; // Can the same player be selected twice?
int m_iGameTime; // Time of rounds in seconds.
int m_iHitPoints; // The initial number of hit points.
int m_iGameSpeed; // The speed of the game (fps = 1000/GameSpeed)
bool m_bFullscreen; // True in fullscreen mode.
int m_iChannels; // 1: mono, 2: stereo
int m_iMixingRate; // The mixing rate, in kHz
int m_iMixingBits; // 1: 8bit, 2: 16bit
int m_iMusicVolume; // Volume of music; 0: off, 100: max
int m_iSoundVolume; // Volume of sound effects; 0: off, 100: max
int m_aiPlayerKeys[MAXPLAYERS][9]; // Player keysyms
char m_acLanguage[10]; // Language ID (en,hu,fr,es,..)
int m_iLanguageCode; // Non-persistend language code (set by backend based on the language)
char m_acLatestServer[256]; // Last server
bool m_bServer; // We were server in the last network game
char m_acNick[128]; // The user name on the last server.
The document you read now describes the design of OpenMortal. This page
serves as a starting point. The documentation is generated with doxygen
(http://doxygen.org).
OpenMortal consists of two main parts: the \b frontend and the \b backend.
\li The frontend is a C++ program, responsible for multimedia
(sounds, music, graphics) and general interaction with the players
(menus, keyboard input), and the demo and intro screens.
\li The backend is written in Perl, and is incorporated into the C++
program with Perl embedding.
-\section s1 Modules
+\section s1 1. Modules
The classes of OpenMortal are organized into the following groups (see Modules above).
\li \ref Media - OpenMortal uses \b SDL (http://libsdl.org) for hardware
access such as screen drawing, music, sound effect and keyboard input. For
information and documentation of SDL, SDL_image, SDL_ttf and SDL_mixer,
please look at the SDL homepage.
-
\li \ref PlayerSelect
\li \ref Network
\li \ref Demo
\li \ref GameLogic
-\section s2 Main Functions
+\section s2 2. Main Functions
These global functions implement important parts of the program. They serve
as entry points into functional parts.
\li DoMenu() - Displays and runs the menu over the current screen
\li GameOver() - Displays the "Final Judgeent" screen
\li DoDemos() - Runs the demos in an endless loop until a game is started or the program ends.
\li DoGame() - Runs the game.
\li DoOnlineChat() - Connects to and runs the MortalNet.
\li CPlayerSelect::DoPlayerSelect() - Runs the player selection screen.
-\section s3 Definitions
+\section s3 3. Definitions
Here are the definitions of terms used in this documentation.
<dl>
<dt>\b Player <dd>
- Player refers to one of the two persons playing the game. A player chooses a fighter. The two players are referred to as "Player 1" and "Player 2", even though the C++ and perl code count arrays from 0.
-
-
+ Player refers to one of the two persons playing the game. A player chooses a fighter. The two players are referred to as "Player 1" and "Player 2", even though the C++ and perl code count arrays from 0.
<dt>\b Fighter <dd>
Fighter is one of the many available characters. Usually there are only two fighters loaded at any time. Fighters are static: their properties never change. Maybe Fighter should be renamed to Character?
<dt>\b Game <dd>
One game is the part of the program in which the players actually compete. The game consists of a number of rounds. The player selection, and gameover screen are not part of this definition.
<dt>\b Round <dd>
One round starts with both players at full health, and ends either with a timeout or with a ko.
<dt>\b Doodad <dd>
A graphical element on the game screen that is not the background or the characters. E.g. the "3x combo" text or a thrown projectile are doodads.
<dt>\b Tint <dd>
A tint is a methodical change in a palette. There are many ways to tint (e.g. grayscaling, darkening, green chroma, etc). Usually when two players choose the same fighter, the fighter of player 2 is tinted.
<dt>\b Scene <dd>
The description of a frozen moment in the course of a game. The Backend is responsible for calculating each consecutive scene. The number of scenes calculated per second is constant (except for the "hurry up mode", or if the computer is too slow).
<dt>\b FPS <dd>
Frames Per Second. The FPS indicator on the screen during a game indicates the number of scenes drawn, not the number of scenes calculated by the backend.
</dl>
-\section s4 C++ Coding conventions
+\section s4 4. C++ Coding conventions
Historically two different coding conventions were mixed in OpenMortal.
Hopefully most of the old conventions are eliminated by now.
Here I will describe the new conventions:
\li <B> Class names: </B> CMixedCaps.
\li <B> Struct names: </B> SMixedCaps.
\li <B> Typedef names: </B> CSomeTypedef (There's some traces of the old TSomeTypedef