From 425decdf7e9284d15aa726e3ae96b9942fb0e3ea Mon Sep 17 00:00:00 2001 From: IronClawTrem Date: Sun, 16 Feb 2020 03:40:06 +0000 Subject: create tremded branch --- docs/Features.md | 93 ++++++++ docs/LuaScripting.md | 13 ++ docs/ParticleSystem.md | 160 +++++++++++++ docs/PlayerVars.md | 15 ++ docs/TrailSystem.md | 44 ++++ docs/VoiceCommands.md | 40 ++++ docs/opengl2-readme.md | 604 +++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 969 insertions(+) create mode 100644 docs/Features.md create mode 100644 docs/LuaScripting.md create mode 100644 docs/ParticleSystem.md create mode 100644 docs/PlayerVars.md create mode 100644 docs/TrailSystem.md create mode 100644 docs/VoiceCommands.md create mode 100644 docs/opengl2-readme.md (limited to 'docs') diff --git a/docs/Features.md b/docs/Features.md new file mode 100644 index 0000000..1c228da --- /dev/null +++ b/docs/Features.md @@ -0,0 +1,93 @@ +# Windows, Linux and OSX + +The GrangerHub Tremulous engine is supported on Windows, Linux and OSX. Builds +are automaticly produced by our CI/CD system. + +# CI/CD + +The Tremulous engine is supported by a CI/CD (Continuous Integration/Continous +Delivery) using TravisCI and Github. Each time commits are pushed to the github +repository, TravisCI will verify that each of the MacOSX, Linux and Windows builds +are successful. Releases are generated automatically anytime a tag is pushed to +the repository; TravisCI will then package the build with the assets and push +the build artifacts to the Github releases page. Upon completion a notification +is sent to the GrangerHub Slack. + +Hilights: +* TravisCI +* Automated builds +* Automated release generation + +TODO: +* Add Appveyor +* Reenable Coverity scans + +# CMake support + +A CMake system exists to build Tremulous on Linux and OSX. The CMake setup also +supports building QVM's using the in-tree QVM toolchain. + +TODO: +* Windows +* Appveyor Windows builds + + +# C++14 + +The engine has been modernized to compile at the C++14 standard. This was originally +done to simplify supporting Lua using the SOL2 Library, however this conversion has +also resulted in a significantly improved stability due to better memory initialization. +It's worth noting that the renderer's have not been converted to C++14 as we currently +piggyback off ioquake3's renderer's (maintained by SmileTheory). + +# Lua + +The engine has an embedded Lua runtime and several API's are exposed from the engine, +including: + +* Cvars +* Binds +* Passing commands to server +* Nettle (Crypto library) +* HTTP Client/Restful +* JSON (rapidjson) + +# Multi-protocol + +Support for Tremulous 1.1.0, Tremulous 1.2.0 (GPP) and the never released version from +DarkLegion's master branch are supported. A client can connect to any of those protocols. +A server can simultaneously serve to all those protocols. QVM version detection on the client +which magically determines the correct interface required for a QVM. + +This work is thanks to `/dev/humancontroller`. + +# Auto-update + +Autoupdates are not fully functional, problems with the minizip implementation require additional +work to work. + +Users can however check the latests updates from the main menu in the client, which queries the +GrangerHub github for the latest release. + +TODO: + * Lua library for ZIP files that preserves executable permissions + +# Restful HTTP Client + +An HTTP Rest API is provided to both C++ and Lua interfaces. + + +# JSON Support + +JSON support is provided via the lovely RapidJSON project. An interfaces is provided for both +C++ and Lua. + +# Filesystem Stability + +The filesystem has been refactored to be stable from startup. It is not possible for a server to +clobber the default QVM/UI. + +FIXME: + * Currently breaks mod loading support from the client main menu. + + diff --git a/docs/LuaScripting.md b/docs/LuaScripting.md new file mode 100644 index 0000000..4bde0d8 --- /dev/null +++ b/docs/LuaScripting.md @@ -0,0 +1,13 @@ +# Lua Scripting + +Purpose: +Documentation regarding the Lua API's in depth. lua/README.md is for jumpping +in _head first!_. What is possible, and maybe some "Shipping" scripts that might be +released. + +This file should be the reference/bible to the Lua runtime API. More boring, answers +questions, doesn't tell many jokes etc.. + + +TODO: All of it + diff --git a/docs/ParticleSystem.md b/docs/ParticleSystem.md new file mode 100644 index 0000000..e93843f --- /dev/null +++ b/docs/ParticleSystem.md @@ -0,0 +1,160 @@ + +# Tremulous Particle System + +Files matching the pattern `scripts/*.particle` are loaded as particle system description files. +Each `.particle` file can contain an arbitrary number of discrete particle systems, much like a `.shader` file can house many shaders. +A particle system is declared by a name followed by curly braces within which the functionality of the particle system is defined. + +For example: + +``` +aShinyNewParticleSystem { } +``` + +Inside the particle system declaration are placed UP TO *four* particle ejectors. +Ejectors are identified by the keyword ejector and curly braces: + +``` +aShinyNewParticleSystem +{ + ejector { } + + ejector { } + + thirdPersonOnly +} +``` + +The `thirdPersonOnly` keyword may be used to specify that the particle system is not visible from the first person if it relates to that client. + +The role of the particle ejector is to create some number of new particles at a defined rate. + These attributes are controlled by the following parameters: + +- count `|infinite` - the number of particles this ejector will spawn. +- delay `` - the delay in msec before the ejector starts spawning. +- period ` ` - the period between particle ejections. + +It is perfectly acceptable to have an initial period of zero. +In this case the number of particles specified by the count keyword will be ejected at once. +It is not permissible to have count infinite and a period of zero for obvious reasons. + +At ejection time each ejector creates up to four new particles based on templates. +These are specified in the ejector section using the particle keyword: + +``` +aShinyNewParticleSystem +{ + ejector + { + particle { } + + particle { } + + count 50 + delay 0 + period 0 - 0 + } +} +``` + +Each particle template has a number of attributes: + +- `shader |sync ... ` - this specifies the shaders to use for the particle. The frame rate can be set to a static rate or the sync parameter can be used in which case the frame rate will be synchronised to the lifetime of the particle such that the first frame is displayed on birth and the last frame is displayed immediately before death. +- `model ... ` - use one of the specified models as the particle. This cannot be used in conjunction with the shader keyword. +- `modelAnmation |sync` - animation parameters to use when model particles are employed. +- `displacement ` - a static displacement about the attachment point. The variance parameter specifies a random displacement in all axes. +- `normalDisplacement ` - for particle systems that have their normal set (impact particle systems for example) this specifies the magnitude of a displacement along the normal. +- `velocityType static|static_transform|tag|cent|normal` - this specifies how the particle will compute its initial velocity. `static` means it is specified statically in the `.particle` file, `static_transform` means the same, except that it is transformed by the orientation matrix of what it is attached to, `tag` means the velocity is in the direction of the tag it is attached to, `cent` means the velocity is in the direction of the cent it is attached to and `normal` means the velocity is in the direction of the particle system normal. +- `velocityDir linear|point` - this specifies whether the initial velocity is computed as a simple direction or as the direction towards a secondary point (defined by `velocityPoint` or dynamically through `velocityType cent`). +- `velocity ` - for when `velocityType static` is present this specifies the direction. The variance here is specified in degrees e.g. `~5` - up to 5 degrees deviation. +- `velocityMagnitude ` - the magnitude of the velocity. +- `velocityPoint ` - for when `velocityType static` and `velocityDir point` are present this specifies the point to move towards. +- `parentVelocityFraction ` - for when the particle system is attached to a cent this specifies the fraction of the cent’s velocity that is added to the particle’s velocity. +- `accelerationType static|static_transform|tag|cent|normal` - this specifies how the particle will compute its acceleration. `static` means it is specified statically in the `.particle` file, `static_transform` means the same, except that it is transformed by the orientation matrix of what it is attached to, `tag` means the acceleration is in the direction of the tag it is attached to, `cent` means the acceleration is in the direction of the cent it is attached to and `normal` means the acceleration is in the direction of the particle system normal. +- `accelerationDir linear|point` - this specifies whether the acceleration is computed as a simple direction or as the direction towards a secondary point (defined by `accelerationPoint` or dynamically through `accelerationType cent`). +- `acceleration ` - for when accelerationType static is present this specifies the direction. The variance here is specified in degrees e.g. `~5` - up to 5 degrees deviation. +- `accelerationMagnitude ` - the magnitude of the acceleration. +- `accelerationPoint ` - for when accelerationType static and accelerationDir point are present this specifies the point to move towards. +- `bounce |cull` - the fraction of velocity that is refiected when a particle collides. If this is set to `0.0` the particle won't collide. When cull is used particles are culled as soon as they collide with objects. +- `bounceMark ` - make a mark at each bounce point for up to `` bounces. +- `bounceSound ` - make a sound at each bounce point for up to `` bounces. +- `dynamicLight { }` - attach a dynamic light to this particle. +- `color { } { }` - color the particle where `` refers to the initial color component and `` refers to the final color component. +- `overdrawProtection` - cull particles that occupy a large amount of screen space. +- `realLight` - light particles using the lightgrid instead of fullbright. +- `cullOnStartSolid` - cull particles that are spawned inside brushes. +- `radius ` - the radius of the particle throughout its lifetime. The delay parameter specifies the time in msec before radius scaling begins. The initial and final parameters specify the radii of the particle in quake units. +- `alpha ` - the alpha of the particle throughout its lifetime. The delay parameter specifies the time in msec before alpha scaling begins. The initial and final parameters specify the alpha of the particle where `1.0` is totally opaque and `0.0` is totally transparent. +- `rotation ` - the rotation of the particle throughout its lifetime. The delay parameter specifies the time in msec before the rotation begins. The initial and final parameters specify the rotation of the particle in degrees. +- `lifeTime