Difference between revisions of "Code structure"
Tow dragon (talk | contribs) (Created page with 'The code of VCMI is divided into several main parts: client, server, lib and AIs, each one in a separate binary file. = Structure of client = == Main purposes of client == Cli…') |
Tow dragon (talk | contribs) |
||
| Line 12: | Line 12: | ||
== Rendering of graphics == | == Rendering of graphics == | ||
| − | + | Rendering of graphics relies heavily on SDL. Currently we do not have any wrapper for SDL internal structures and most of rendering is about blitting surfaces using SDL_BlitSurface. We have a few function that make rendering easier or make specific parts of rendering (like printing text). They are places in client/SDL_Extensions and client/SDL_Framerate (the second one contains code responsible for keeping appropriate framerate, it should work more smart than just SDL_Delay(miliseconds)). In rendering, Interface object system is quite helpful. Its base is CIntObject class that is basically a base class for our library of GUI components and other objects. | |
== Adventure map == | == Adventure map == | ||
| Line 26: | Line 26: | ||
=== Animations of creatures === | === Animations of creatures === | ||
All animations of creatures in a battle are handled by storing currently displayed animations in pendingAnims vector. When server tells that an event requiring animation happens, info about it is added to pendingAnims. Every animation needs to be initialized (what indicates that this animation has started). show() function tries to initialize all not initialized animations every frame until it succeeds. Then nextFrame call-ins are called until animation removes itself from pendingAnims. During initialization it is checked if this animation can be played now or we must wait. | All animations of creatures in a battle are handled by storing currently displayed animations in pendingAnims vector. When server tells that an event requiring animation happens, info about it is added to pendingAnims. Every animation needs to be initialized (what indicates that this animation has started). show() function tries to initialize all not initialized animations every frame until it succeeds. Then nextFrame call-ins are called until animation removes itself from pendingAnims. During initialization it is checked if this animation can be played now or we must wait. | ||
| + | |||
| + | === Showing sequence of stacks, obstacles and wall pieces === | ||
| + | Firstly, all dead stacks are printed on the screen. Then alive stacks, obstacles and wall pieces are printed in order of appearance (number of hex they are placed on). This algorithm works fairly well if no creatures move, but due to the fact that while a creature is moving, its position is the destination, not the hex they are walking on, sometimes it makes some graphical glitches that are not easy to fix. | ||
= Structure of server = | = Structure of server = | ||
| Line 42: | Line 45: | ||
Lib is responsible for: | Lib is responsible for: | ||
* handling Heroes III's files (.lod, txt setting files) | * handling Heroes III's files (.lod, txt setting files) | ||
| − | * storing information common to server and client | + | * storing information common to server and client like state of the game |
= Structure of AI (GeniusAI) = | = Structure of AI (GeniusAI) = | ||
Revision as of 16:10, 22 April 2010
The code of VCMI is divided into several main parts: client, server, lib and AIs, each one in a separate binary file.
Contents
Structure of client
Main purposes of client
Client is responsible for:
- displaying state of game to human player
- capturing player's actions and sending requests to server
- displaying changes in state of game indicated by server
Rendering of graphics
Rendering of graphics relies heavily on SDL. Currently we do not have any wrapper for SDL internal structures and most of rendering is about blitting surfaces using SDL_BlitSurface. We have a few function that make rendering easier or make specific parts of rendering (like printing text). They are places in client/SDL_Extensions and client/SDL_Framerate (the second one contains code responsible for keeping appropriate framerate, it should work more smart than just SDL_Delay(miliseconds)). In rendering, Interface object system is quite helpful. Its base is CIntObject class that is basically a base class for our library of GUI components and other objects.
Adventure map
TBD
Town
TBD
Battle
Animations of creatures
All animations of creatures in a battle are handled by storing currently displayed animations in pendingAnims vector. When server tells that an event requiring animation happens, info about it is added to pendingAnims. Every animation needs to be initialized (what indicates that this animation has started). show() function tries to initialize all not initialized animations every frame until it succeeds. Then nextFrame call-ins are called until animation removes itself from pendingAnims. During initialization it is checked if this animation can be played now or we must wait.
Showing sequence of stacks, obstacles and wall pieces
Firstly, all dead stacks are printed on the screen. Then alive stacks, obstacles and wall pieces are printed in order of appearance (number of hex they are placed on). This algorithm works fairly well if no creatures move, but due to the fact that while a creature is moving, its position is the destination, not the hex they are walking on, sometimes it makes some graphical glitches that are not easy to fix.
Structure of server
Main purposes of server
Server is responsible for:
- maintaining state of the game
- handling requests from all clients participating in game
- informing all clients about changes in state of the game that are visible to them
Structure of lib
Main purposes of lib
Lib is responsible for:
- handling Heroes III's files (.lod, txt setting files)
- storing information common to server and client like state of the game
Structure of AI (GeniusAI)
TBD
How these parts are connected
TBD
