distribution cleanups
--HG-- rename : src/engine/lightmap.cpp => src/engine/light.cpp rename : src/engine/lightmap.h => src/engine/light.h rename : src/readme_source.txt => src/readme_sauerbraten.txt rename : sauerbraten.bat => tesseract.bat rename : cubed/packages/base/refract-test.cfg => tesseract/packages/base/refract-test.cfg rename : cubed/packages/base/refract-test.ogz => tesseract/packages/base/refract-test.ogz rename : cubed/packages/textures/glassn.png => tesseract/packages/textures/glassn.png rename : cubed/packages/textures/watern.jpg => tesseract/packages/textures/watern.jpgmaster
lsalzman
parent
02e51f15be
commit
67aaff849a
375
README.html
375
README.html
|
|
@ -1,375 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html
|
||||
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
|
||||
<head>
|
||||
<title>Cube 2: Sauerbraten</title>
|
||||
<link rel="stylesheet" type="text/css" href="docs/style.css" />
|
||||
<link rel="shortcut icon" href="docs/favicon.ico" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
||||
<div align="center"><a href="http://sauerbraten.org/"><img src="docs/cube2logo.png" alt="Cube 2: Sauerbraten" style="border: none" /></a></div>
|
||||
|
||||
<h1>Cube 2: Sauerbraten</h1>
|
||||
|
||||
<div class="contents">
|
||||
<ul class="contents">
|
||||
<li>
|
||||
<a href="#links"><b>Links</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#documentation"><b>Documentation</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#the_wiki"><b>The Wiki</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#current_features"><b>Current Features</b></a>
|
||||
<ul class="contents2">
|
||||
<li>
|
||||
<a href="#game_features">Game Features</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#engine_features">Engine Features</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#credits_slash_authors"><b>Credits / Authors</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#license"><b>License</b></a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<h2 id="links">Links</h2>
|
||||
|
||||
<p>
|
||||
First of all, welcome to Cube 2: Sauerbraten! To start off, if you are looking for help with the game itself, refer to the
|
||||
<a href="#documentation"><b>Documentation</b></a> below. Here are some places of interest on the internet, which are related to
|
||||
<i>Cube / Cube 2: Sauerbraten</i>.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<a href="http://cubeengine.com/">Cube and Cube 2 Engines</a>: Start Page for the Cube Engine series.
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://sauerbraten.org/">Cube 2: Sauerbraten</a>: The Sauerbraten FPS (First Person Shooter) Homepage.
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://quadropolis.us/">Quadropolis</a>: Online Cube Engine community, with user made maps, mods, and scripts.
|
||||
</li>
|
||||
<li>
|
||||
<a href="irc://irc.quakenet.org/sauerbraten">Sauerbraten IRC Channel</a>: Online public chat with Cube developers, supporters and fans, via the <a href="http://www.quakenet.org/">QuakeNet IRC Network</a>.
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://cubeengine.com/forum.php4">Cube Forums</a>: If after reading the documentation and wiki you
|
||||
still have any questions, you can try <i>searching</i> the forums. If your question isn't answered there,
|
||||
you can try posting to a relevant thread, or creating your own, being sure to supply a good description
|
||||
of your problem, and your operating system/hardware/software setup, while refraining from wild accusations.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="documentation">Documentation</h2>
|
||||
|
||||
<p>
|
||||
Cube 2: Sauerbraten is a multiplayer/singleplayer FPS freeware game project.
|
||||
The source code for the engine used in these games is Open Source (ZLIB licence, read the "License"
|
||||
section below carefully before starting ANY kind of project based on this engine).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You will want to read (roughly this order):
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<a href="docs/game.html">Game</a>: Information on gameplay.
|
||||
</li>
|
||||
<li>
|
||||
<a href="docs/config.html">Config</a>: How to run the game, configure it for your machine, and extend it with scripts.
|
||||
</li>
|
||||
<li>
|
||||
<a href="docs/editing.html">Editing Tutorial</a>: A guide to making maps.
|
||||
</li>
|
||||
<li>
|
||||
<a href="docs/editref.html">Editing Reference</a>: Map making reference.
|
||||
</li>
|
||||
<li>
|
||||
<a href="docs/models.html">Models</a>: How to put models into the game.
|
||||
</li>
|
||||
<li>
|
||||
<a href="docs/history.html">History</a>: For seeing latest changes.
|
||||
</li>
|
||||
<li>
|
||||
<a href="docs/rpg.html">Example RPG Game Information</a>: Information on running, building, or scripting the example RPG game.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="the_wiki">The Wiki</h2>
|
||||
|
||||
<p>
|
||||
In addition to the documentation provided, the wiki has a lot of useful information for working
|
||||
with the game and engine, contributed by the community which elaborates and breaks alot of the information
|
||||
down into more digestable chunks. This is just provided a short rundown of the most useful topics to new players,
|
||||
and those looking for quick readable information. For more go visit the
|
||||
<a href="http://cube.wikispaces.com/">Cube Wiki</a>.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<a href="http://cube.wikispaces.com/Beginners+Guide">Beginners Guide</a>: Go through the steps to get up and running.
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://cube.wikispaces.com/FAQ">Frequently Asked Questions</a>: Get the answers to some commonly asked
|
||||
questions, like; "<i>The game runs very slowly, how can I fix it?</i>",
|
||||
"<i>Why is the game behaving strangely?</i>", and "<i>How do I fix the 'Hall of Mirrors' effect?</i>".
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://cube.wikispaces.com/Performance+Guide">Performance Guide</a>: Things you can try to make the game
|
||||
either run faster or look better on your machine.
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://quadropolis.us/taxonomy/term/21">Older Stuff</a>: From Quadropolis.
|
||||
</li>
|
||||
<li>
|
||||
Some <a href="docs/dev/wikistuff.html">old</a> random documentation bits from our previous wiki that don't
|
||||
have a place yet.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="current_features">Current Features</h2>
|
||||
|
||||
<p>
|
||||
Cube 2: Sauerbraten is an open source project, and maintains constant development, yet it is very feature-rich and playable as a game. What follows is a list of the most prominent features.
|
||||
</p>
|
||||
|
||||
<h3 id="game_features">Game Features</h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Oldskool fast & intense gameplay (read: similar to Doom 2 / Quake 1).
|
||||
</li>
|
||||
<li>Many multiplayer gameplay modes, most in teamplay variants as well: deathmatch, instagib, efficiency,
|
||||
tactics, capture (domination/battlefield style), CTF (capture the flag), coop edit (!).
|
||||
</li>
|
||||
<li>
|
||||
Masterserver & ingame server browser.
|
||||
</li>
|
||||
<li>
|
||||
Lag-free gameplay experience.
|
||||
</li>
|
||||
<li>
|
||||
Two singleplayer modes: DMSP (fight a monster invasion on any DM map), classic SP
|
||||
(progression driven SP like other games)
|
||||
</li>
|
||||
<li>
|
||||
7 weapons tuned for maximum satisfaction: double barrelled shogun, rocket launcher,
|
||||
machine gun, rifle, grenade launcher, pistol, fist.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="engine_features">Engine Features</h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
6 directional heightfield in octree world structure allowing for instant easy in-game geometry editing (even
|
||||
in multiplayer, coop edit).
|
||||
</li>
|
||||
<li>
|
||||
Rendering engine optimized for high geometry throughput, supporting hardware occlusion culling and software precomputed conservative PVS with occluder fusion.
|
||||
</li>
|
||||
<li>
|
||||
Lightmap based lighting with accurate shadows from everything including mapmodels,
|
||||
smooth lighting for faceted geometry, and fast compiles. Soft shadowmap based shadows for dynamic entities.
|
||||
</li>
|
||||
<li>
|
||||
Pixel and vertex shader support, each model and world texture can have its own shader assigned. Supports normal and parallax mapping, specular and dynamic lighting with bloom and glow, environment-mapped and planar reflections/refractions, and post-process effects.
|
||||
</li>
|
||||
<li>
|
||||
Robust physics written specifically for this world structure.
|
||||
</li>
|
||||
<li>
|
||||
Loading of md2/md3/md5/obj/smd/iqm models for skeletal and vertex animated characters, weapons, items, and world objects. Supports animation blending, procedural pitch animation, and ragdoll physics for skeletally-animated characters.
|
||||
</li>
|
||||
<li>
|
||||
Network library designed for high speed games, client/server network system.
|
||||
</li>
|
||||
<li>
|
||||
Small but complete configuration/scripting language.
|
||||
</li>
|
||||
<li>
|
||||
Simple stereo positional sound system.
|
||||
</li>
|
||||
<li>
|
||||
Particle engine, supporting text particles, volumetric explosions, soft particles, and decals.
|
||||
</li>
|
||||
<li>
|
||||
3d menu/gui system, for in-world representation of choices.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="credits_slash_authors">Credits / Authors</h2>
|
||||
|
||||
<div class="credits">Programming</div>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<i>Wouter "Aardappel" van Oortmerssen</i>: A lot of the general code, and the original concept and design. (<a href="http://strlen.com/">website</a>)
|
||||
</li>
|
||||
<li>
|
||||
<i>Lee "eihrul" Salzman</i>: ENet networking library, *nix ports, and a lot of the general code, especially rendering/lightmaps/physics related. (<a href="http://lee.fov120.com/">website</a>)
|
||||
</li>
|
||||
<li>
|
||||
<i>Mike "Gilt" Dysart</i>: General programming, especially editing/physics related.
|
||||
</li>
|
||||
<li>
|
||||
<i>Robert "baby-rabbit" Pointon</i>: GUI, particle rendering, and movie recording code, MacOSX porting. (<a href="http://www.fernlightning.com/">website</a>)
|
||||
</li>
|
||||
<li>
|
||||
<i>Quinton "quin" Reeves</i>: Bots/AI code. Asissts with community management, documentation/wiki, and development. (<a href="http://www.redeclipse.net/">website</a>)
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div class="credits">Additional Code</div>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<i>Julian Mayer</i>: MacOSX ports.
|
||||
</li>
|
||||
<li>
|
||||
<i>Adrian "driAn" Henke</i>: MD3 code.
|
||||
</li>
|
||||
<li>
|
||||
<i>Jerry Siebe</i>: Geometry rendering optimisations.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div class="credits">Level Design</div>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<i>Kurt "kdoom" Kessler</i>: A bunch of DM/capture maps, k_rpg1.
|
||||
</li>
|
||||
<li>
|
||||
<i>Shane Nieb</i>: academy, authentic, bt_falls, c_valley, complex, curvy_castle, flagstone, garden, hallo, island, justice, nevil_c, nmp4, nmp8, nmp9, ot, park, shipwreck, turbine
|
||||
</li>
|
||||
<li>
|
||||
<i>John "metlslime" fitzgibbons</i>: metl* maps.
|
||||
</li>
|
||||
<li>MitaMan: singleplayer episodes</li>
|
||||
<li>
|
||||
With additional maps by: Aardappel, driAn, Gilt, voot, Bryan "KillHour" Shalke, staffy, sparr, JCDPC, ZappaZ, RatBoy, Fanatic, rocknrol, KaiserTodretter, BlikjeBier, wurfel, aftasardem, Lazy [HUN], Gregor Koch, Junebug, Gabriele "Blindabuser" Magurno, MeatROme, TUX, Mayhem, mIscreant, schmutzwurst, Kal, DairyKing, Hero, WahnFred, and others.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div class="credits">Art / Content</div>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<i>
|
||||
John "Geartrooper" Siar</i>: Mr. Fixit, Ironsnout, RPG characters, monsters, new hudguns and vweps.
|
||||
</li>
|
||||
<li>
|
||||
<i>Gabriele "Blindabuser" Magurno</i>: Logos, loading screen, announcer voices.
|
||||
</li>
|
||||
<li>
|
||||
<i>MakkE</i>: Mapmodels, old hudguns, items.
|
||||
</li>
|
||||
<li>
|
||||
<i>Dietmar "dcp" Pier</i>: Mapmodels, old hudguns.
|
||||
</li>
|
||||
<li>
|
||||
<i>DarthVim</i>: Old hudguns.
|
||||
</li>
|
||||
<li>
|
||||
<i>Shane Nieb</i>: Textures, Mapmodels, Skyboxes.
|
||||
</li>
|
||||
<li>
|
||||
<i>Sock</i>: The egyptian & tech texture sets (<a href="http://www.planetquake.com/simland">website</a>).
|
||||
</li>
|
||||
<li>
|
||||
<i>Iikka "Fingers" Keranen</i>: The ikbase ik2k texture sets (<a href="http://www.digital-eel.com/surface">website</a>).
|
||||
</li>
|
||||
<li>
|
||||
<i>Lunaran, Gibbie, Gregor Koch, Jésus "aftasardem" Maia, MitaMan, and philipk</i>: Normalmapped texture sets.
|
||||
</li>
|
||||
<li>
|
||||
Additional art by: metlslime (textures), Than (textures), Remedy Entertainment Ltd (textures), Seth & Ulrich Galbraith (GPL models), Brian "EvilBastard" Collins, Conrad, Magarnigal, Psionic, James Green, Andreas Möller, Ryan Butts & Jeramy Cooke (md2 models), KaiserTodretter (items), Tentus (mapmodels), Kurt Kessler (mapmodels), Philip Klevestav (textures), leileilol/OpenArena (GPL bullet hole decal).
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div class="credits">Sound / Music</div>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<i>Marc "Fanatic" A. Pullen</i>: Soundtrack.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div class="credits">Other</div>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<i>Kristian "sleepwalkr" Duske</i>: website / messageboard, hosting, master server.
|
||||
</li>
|
||||
<li>
|
||||
<i>Pushplay</i>: Documentation help.
|
||||
</li>
|
||||
<li>
|
||||
<i>The SDL team</i>: For their libraries (<a href="http://www.libsdl.org/">website</a>).
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="license">License</h2>
|
||||
|
||||
<p>
|
||||
The game is freeware, you may freely distribute the archive and/or installer <i>unmodified</i> on any media.
|
||||
You may re-compress using different archival formats suitable for your OS (i.e. zip/tgz/rpm/deb/dmg), any changes beyond that require explicit permission from the developers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You may play Cube 2: Sauerbraten for any purpose as long as you don't blame the authors for any damages incurred.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you want to produce new content with the Cube 2 Engine, you have to be aware that the source code may be Open Source, but the game and the media it consist of have their individual licenses and copyrights.
|
||||
This means that you have roughly 3 options:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
You may produce new content for the "Sauerbraten" game, for example as a <i>custom map</i> (.ogz/.cfg/textures etc).
|
||||
Contributing <i>content</i> to the original game is most welcome, and the most productive way of working with the community.
|
||||
</li>
|
||||
<li>
|
||||
If you want to create your own gameplay beyond what you can do with a map, the best way to do this is as a "mod" (same as above, but with new executable that
|
||||
incorporates your gameplay), that <i>requires an existing install</i>, and <i>installs only the new files</i> you created in parallel to the existing files.
|
||||
</li>
|
||||
<li>
|
||||
If you insist on making a standalone game based on Cube 2, do realize that <i>only the sourcecode</i> is yours to use freely (if you abide by the ZLIB license, see below),
|
||||
while the media is <i>not</i>. You can't simply redistribute the entire package with your modified files, as the majority of game media is not yours to use freely (it is made
|
||||
by many authors with a variety of licences and copyright restrictions). Unless you have explicit permission from the authors, or the readme says explicitly "may be used
|
||||
for any purpose" or similar language, it will be illegal to include in your standalone game based on the engine (you may not assume that just because a file
|
||||
has no explicit license, that it is free of copyright). Therefore, if you wish to produce a standalone game, be prepared to make many of the maps, models, textures, sounds etc from scratch
|
||||
yourself.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
In this sense Cube 2: Sauerbraten is similar to games like Quake (its code is Open Source, but its media is not), it is a game that is meant
|
||||
to be added to, not copied and used as a template. Sauerbraten is not meant to be a quick game creation kit, it is a game.
|
||||
</p>
|
||||
<p>
|
||||
If you wish to use the source code (ZLIB license) in any way, read the src/readme_source.txt file carefully.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -125,8 +125,7 @@ bind G [ togglezoom ]
|
|||
bind Z [ togglezoom ]
|
||||
|
||||
//////////////////////////////////
|
||||
// Sauerbraten Editing related bindings
|
||||
// found in autoexec.cfg in your sauerbraten directory
|
||||
// Editing related bindings
|
||||
|
||||
editbind SPACE [ cancelsel ]
|
||||
editbind MOUSE1 [ if $blendpaintmode [paintblendmap] [editdrag] ]
|
||||
|
|
|
|||
|
|
@ -1,240 +0,0 @@
|
|||
// rpg specific cfg stuff goes here -- see rpg.html for more clarity
|
||||
|
||||
// for the rpg, almost all gameplay is defined _per map_ as opposed to globally for the game
|
||||
// but for now a lot of stuff goes here for testing
|
||||
|
||||
playasong = []
|
||||
|
||||
// these are the log curve settings for computing efficiency based on points. do not modify if you don't know what these do.
|
||||
|
||||
r_def_logscale_x = 10
|
||||
r_def_logscale_y = 25
|
||||
|
||||
r_def_melee $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_ranged $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_magic $r_def_logscale_x $r_def_logscale_y
|
||||
|
||||
r_def_hpregen $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_manaregen $r_def_logscale_x $r_def_logscale_y
|
||||
|
||||
r_def_maxhp $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_maxmana $r_def_logscale_x $r_def_logscale_y
|
||||
|
||||
r_def_attackspeed $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_movespeed $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_jumpheight $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_tradeskill $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_feared $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_stealth $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_hostility $r_def_logscale_x $r_def_logscale_y
|
||||
|
||||
r_def_stata $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_statb $r_def_logscale_x $r_def_logscale_y
|
||||
r_def_statc $r_def_logscale_x $r_def_logscale_y
|
||||
|
||||
//showcharacterboundingbox 1
|
||||
|
||||
|
||||
// some useful functions...
|
||||
|
||||
newrpgspawn = [ newent spawn; spawnname $arg1; ]
|
||||
|
||||
r_inventory = [ r_spawn $arg1; r_contain 1; r_pop ]
|
||||
r_loot = [ r_spawn $arg1; r_contain 2; r_pop ]
|
||||
r_fortrade = [ r_spawn $arg1; r_contain 4; r_pop ]
|
||||
|
||||
r_sound = [ r_usesound (registersound $arg1) ]
|
||||
|
||||
|
||||
// all the objects in the game:
|
||||
|
||||
// that's us
|
||||
spawn_player = [
|
||||
r_inventory apple
|
||||
r_inventory power_gem
|
||||
r_inventory fist // starting weapon
|
||||
r_inventory sword
|
||||
r_inventory fireball
|
||||
r_inventory iceball
|
||||
r_inventory healing
|
||||
r_inventory crossbow
|
||||
r_gold 10 // give us some starting money, woo
|
||||
r_ai 1 // just so it is in the same group as the npcs for attacks etc
|
||||
]
|
||||
|
||||
r_meleeweapon = [
|
||||
r_usetype 1
|
||||
r_damage $arg1
|
||||
r_attackrate $arg2
|
||||
r_maxrange $arg3
|
||||
r_maxangle $arg4
|
||||
r_action_use [ r_dodamage (r_eff_melee) ]
|
||||
]
|
||||
|
||||
r_rangedweapon = [
|
||||
r_usetype 2
|
||||
r_damage $arg1
|
||||
r_attackrate $arg2
|
||||
r_maxrange $arg3
|
||||
r_useamount 10 // comes with arrows included
|
||||
r_action_use [ r_dodamage (r_eff_ranged) ]
|
||||
r_sound "free/tick"
|
||||
]
|
||||
|
||||
r_spell = [
|
||||
r_usetype 3
|
||||
r_damage $arg1
|
||||
r_attackrate $arg2
|
||||
r_manacost $arg3
|
||||
r_maxrange $arg4
|
||||
r_effectparticle (at $arg5 0)
|
||||
r_effectcolor (at $arg5 1)
|
||||
r_effectsize (at $arg5 2)
|
||||
r_sound $arg6
|
||||
r_action_use $arg7
|
||||
]
|
||||
|
||||
// weapons
|
||||
spawn_fist = [ r_meleeweapon 10 500 20 30; r_sound "free/punch1"; r_use ] // this will be equipped when we start
|
||||
spawn_sword = [ r_meleeweapon 15 750 30 30; r_sound "free/tick" ]
|
||||
spawn_hammer = [ r_meleeweapon 5 250 20 20; r_sound "free/tick"; r_model "tentus/hammer" ]
|
||||
spawn_bomb = [ r_meleeweapon 30 1000 90 90; r_sound "free/tick"; r_model "tentus/bombs" ]
|
||||
spawn_spear = [ r_meleeweapon 10 1000 60 60; r_sound "free/tick"; r_model "tentus/spear" ]
|
||||
|
||||
spawn_crossbow = [ r_rangedweapon 5 1000 256 ]
|
||||
|
||||
r_dodamage = [
|
||||
damage = (r_get_damage)
|
||||
r_pop
|
||||
r_applydamage (div (* $damage $arg1) 100)
|
||||
]
|
||||
|
||||
r_givehealth = [
|
||||
r_pop
|
||||
r_hp (+ (r_get_hp) $arg1) // temp, needs to be capped
|
||||
]
|
||||
|
||||
r_givemana = [
|
||||
r_pop
|
||||
r_mana (+ (r_get_mana) $arg1)
|
||||
]
|
||||
|
||||
// spells, can be used as weapons
|
||||
|
||||
spawn_fireball = [ r_spell 7 500 10 256 [0 0xFFC8C8 480] "awesund/flaunch" [ r_dodamage (r_eff_magic) ] ]
|
||||
spawn_iceball = [ r_spell 10 400 20 256 [1 0xFFFFFF 480] "awesund/flaunch" [ r_dodamage (r_eff_magic) ] ]
|
||||
spawn_healing = [ r_spell 0 1000 25 0 [] "free/itempick" [ r_givehealth 20 ] ]
|
||||
|
||||
// single-use spells, activated in inventory, or in the gameworld:
|
||||
|
||||
spawn_healthpotion = [ r_useamount 1; r_action_use [ r_givehealth 20 ]; r_sound "free/itempick"; r_model "tentus/food-drink/winebottle" ]
|
||||
spawn_manapotion = [ r_useamount 1; r_action_use [ r_givemana 20 ]; r_sound "free/itempick"; r_model "tentus/food-drink/winebottle" ]
|
||||
|
||||
|
||||
// defensive
|
||||
spawn_green_shield = [ r_worth 500; r_hpregen 20; r_model "tentus/greenshield" ]
|
||||
spawn_red_shield = [ r_worth 1000; r_hpregen 50; r_model "tentus/redshield" ]
|
||||
|
||||
// food/drink
|
||||
spawn_apple = [ r_worth 10; r_model "tentus/food-drink/apple" ]
|
||||
spawn_apple_slice = [ r_worth 1; r_model "tentus/food-drink/appleslice" ]
|
||||
spawn_carrot = [ r_worth 1; r_model "carrot" ]
|
||||
spawn_pear = [ r_worth 15; r_model "tentus/food-drink/pear" ]
|
||||
spawn_pie = [ r_worth 20; r_model "tentus/food-drink/pie" ]
|
||||
spawn_pie_slice = [ r_worth 5; r_model "tentus/food-drink/pieslice" ]
|
||||
spawn_mushroom = [ r_worth 5; r_model "dcp/mushroom" ]
|
||||
spawn_wolfmeat = [ r_worth 4; r_model "tentus/food-drink/meat" ]
|
||||
spawn_wine = [ r_worth 30; r_model "tentus/food-drink/winebottle" ]
|
||||
|
||||
// valuables
|
||||
spawn_power_gem = [ r_worth 100; r_melee 100; r_model "checkpoint" ]
|
||||
spawn_coin = [ r_worth 10; r_model "rpg/objects/coin" ]
|
||||
spawn_key = [ r_worth 10; r_model "tentus/key" ]
|
||||
spawn_loot = [ r_worth 100; r_model "tentus/moneybag" ]
|
||||
|
||||
// misc
|
||||
spawn_anvil = [ r_worth 20; r_model "tentus/anvil" ]
|
||||
spawn_books = [ r_worth 5; r_model "tentus/books" ]
|
||||
spawn_bowl = [ r_worth 5; r_model "tentus/food-drink/bowl" ]
|
||||
spawn_goblet = [ r_worth 10; r_model "tentus/food-drink/goblet" ]
|
||||
spawn_mug = [ r_worth 5; r_model "tentus/food-drink/mug" ]
|
||||
spawn_candle = [ r_worth 2; r_model "dcp/candle" ]
|
||||
spawn_cask = [ r_worth 30; r_model "dcp/cask" ]
|
||||
spawn_rope = [ r_worth 10; r_model "dcp/rope" ]
|
||||
spawn_sack = [ r_worth 10; r_model "dcp/sack" ]
|
||||
spawn_wolfskin = [ r_worth 15 ]
|
||||
spawn_vase = [ r_worth 20; r_model "dcp/vase" ]
|
||||
|
||||
// stats
|
||||
spawn_fountainofmana = [ r_manaregen 10000 ]
|
||||
|
||||
// npcs
|
||||
spawn_mman = [
|
||||
r_friendly_creature "rpg/characters/mman"
|
||||
|
||||
r_gold 1000 // rich bastard
|
||||
|
||||
r_inventory red_shield // he's going to be hard to kill
|
||||
|
||||
r_inventory iceball // better not aggrevate him
|
||||
r_inventory fountainofmana
|
||||
|
||||
r_fortrade apple // ooh the guy carries an apple. Maybe we can trade?
|
||||
r_fortrade apple
|
||||
|
||||
r_action "hi" [ r_say "hey, how are you!" ]
|
||||
r_action "I'm hungry" [
|
||||
r_say "kill a wolf for me, and I will give you an apple"
|
||||
r_quest "I killed a wolf" [
|
||||
r_take wolfskin [
|
||||
r_say "thanks for the wolf's skin, here's your apple"
|
||||
r_give apple
|
||||
] [
|
||||
r_say "go kill a wolf first!"
|
||||
]
|
||||
]
|
||||
]
|
||||
]
|
||||
|
||||
r_friendly_creature = [
|
||||
r_model $arg1
|
||||
r_ai 1
|
||||
]
|
||||
|
||||
r_hostile_creature = [
|
||||
r_model $arg1
|
||||
r_ai 2
|
||||
r_meleeweapon $arg2 1000 $arg3 30 // this creature is itself a melee weapon
|
||||
]
|
||||
|
||||
spawn_npcman = [ r_friendly_creature "rpg/characters/npcman"; r_inventory sword ]
|
||||
spawn_horse = [ r_friendly_creature "rpg/characters/horse" ]
|
||||
|
||||
spawn_dragon = [ r_hostile_creature "rpg/characters/dragon" 80 100 ]
|
||||
spawn_wolf = [ r_hostile_creature "rpg/characters/wolf" 10 30; r_loot wolfskin; r_loot wolfmeat ]
|
||||
spawn_rat = [ r_hostile_creature "rpg/characters/rat" 2 25 ]
|
||||
spawn_grizzly = [ r_hostile_creature "rpg/characters/grizzly" 20 40 ]
|
||||
|
||||
// temp: override main menu for rpg
|
||||
|
||||
bind I "showplayergui 1; cleargui 1"
|
||||
bind TAB "showplayergui 2; cleargui 1"
|
||||
bind L "showplayergui 3; cleargui 1"
|
||||
bind ESCAPE [if (cleargui 1) [] [showgui main; showplayergui 0]]
|
||||
|
||||
newgui main [
|
||||
guibutton "inventory (I)" "showplayergui 1" "chest"
|
||||
guibutton "player stats (TAB)" "showplayergui 2" "info"
|
||||
guibutton "quest log (L)" "showplayergui 3" "info"
|
||||
guibar
|
||||
guibutton "map k_rpg1"
|
||||
guibutton "map rpg_01"
|
||||
guibar
|
||||
guibutton "load fps map.." "showgui maps"
|
||||
guibutton "editing.." "showgui editing"
|
||||
guibutton "options.." "showgui options"
|
||||
guibutton "about.." "showgui about"
|
||||
guibar
|
||||
guibutton "quit" "quit" "exit"
|
||||
]
|
||||
|
||||
|
|
@ -21,10 +21,11 @@ newgui main [
|
|||
]
|
||||
|
||||
newgui about [
|
||||
guitext "Cube 2: Sauerbraten"
|
||||
guitext "Tesseract"
|
||||
guitext [by Wouter "Aardappel" van Oortmerssen, Lee "eihrul" Salzman,]
|
||||
guitext [Mike "Gilt" Dysart, Robert "baby-rabbit" Pointon,]
|
||||
guitext [John "geartrooper" Siar, Quinton "Quin" Reeves, and others]
|
||||
guitext [John "geartrooper" Siar, Quinton "Quin" Reeves,]
|
||||
guitext [Benjamin Segovia, and others]
|
||||
guitext "(for a full list of contributors see the readme)"
|
||||
guitext "http://sauerbraten.org/"
|
||||
]
|
||||
|
|
|
|||
1530
docs/config.html
1530
docs/config.html
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 270 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 71 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.3 KiB |
|
|
@ -1,293 +0,0 @@
|
|||
|
||||
Sauerbraten initial development documentation
|
||||
=============================================
|
||||
|
||||
This document describes the state of sauerbraten at the moment
|
||||
of its initial open source release. Anyone who wants to program
|
||||
as part of the sauerbraten project should read this document VERY
|
||||
carefully.
|
||||
|
||||
|
||||
Sauerbraten History
|
||||
===================
|
||||
Sauerbraten was started as an effort to take the ideas behind Cube
|
||||
further: both allow significantly more geometrical possibilities
|
||||
while at the same time being simplified compared to Cube's internal
|
||||
structure. Read all about this on the Sauerbraten homepage:
|
||||
|
||||
http://wouter.fov120.com/sauerbraten/index.html
|
||||
|
||||
Sauerbraten is based on the cube source code of roughly the november
|
||||
2002 state, and both code bases have diverged significantly since.
|
||||
|
||||
The base Cube code was cleaned up a bit, and all code specific to
|
||||
the cube world structure removed or commented out. Some other
|
||||
parts of cube dependent on this were also commented out, but most
|
||||
code is in the sauerbraten base unmodifed. All gamecode, client/
|
||||
server code, physics (dynamics, not collision), sound, monsters,
|
||||
weapons, console/scripting, entities, menus, md2 / hud / particle
|
||||
rendering is all there pretty much unmodified from cube and either
|
||||
already works, or can be easily be made to work again as sauerbraten
|
||||
progresses.
|
||||
|
||||
This document assumes some familiarity with the original Cube source
|
||||
code.
|
||||
|
||||
The major areas that are new have to do with world structure, like
|
||||
rendering, editing etc. A description of each follows:
|
||||
|
||||
World Structure
|
||||
===============
|
||||
The new world structure is the ultimate in elegance, if I may say so
|
||||
myself ;) "octa.h" contains the definition: the only data structure
|
||||
is the new struct "cube". a "cube" is the central component of Sauerbraten's
|
||||
octree structure (if you don't know octree's, google them and read some
|
||||
documents about them first).
|
||||
|
||||
If a "cube" is a leaf, i.e. the smallest element that has been edited
|
||||
as a single cube at that level in the octree, the edges/faces fields
|
||||
define the shape of the cube using the aforementioned "edge spans".
|
||||
A cube has 12 edges, each having 1 edge span occupying 1 byte.
|
||||
The single byte is split in two 4bit quanties each storing a number
|
||||
between 0 and 8, the lower one being the start of the span, and the
|
||||
higher being the end of the span.
|
||||
|
||||
A maximally exstended cube has all edge spans with value 0x80, by
|
||||
definition. A completely empty cube (space) can be defined in many
|
||||
different ways (all edges of 0x00, 0x11 .. 0x88), but as a convention
|
||||
only the value 0x00 is used to allow for fast testing. All current
|
||||
functions enforce this already.
|
||||
|
||||
if a "cube" is not a leaf but is 8-fold subdivided, it has a pointer
|
||||
to its 8 children allocated as one chunk. The other fields of a non-leaf
|
||||
cube are meant to hold the LOD version of its children, but this is
|
||||
currently not implemented.
|
||||
|
||||
note the lack of a "type" field in the "cube" struct: there is only
|
||||
one type of cube (unlike the 7 different types in the Cube engine).
|
||||
This greatly simplifies the code.
|
||||
|
||||
It may take a while to wrap your head around the idea of edge spans and
|
||||
the way they are stored. Reading the algorithms that handle them
|
||||
should help.
|
||||
|
||||
"octa.cpp" contains some of the basic functions of dealing with this
|
||||
structure. Particularly study lookupcube(), as it is the central function
|
||||
used by all other code to access the octree and to further subdivide it
|
||||
if needed.
|
||||
|
||||
"worldio.cpp" works as before but now with the new world structure,
|
||||
"map" and "savemap" work as expected.
|
||||
|
||||
|
||||
World Rendering
|
||||
===============
|
||||
"octarender.cpp" contains all functions that draw the octree & cubes
|
||||
to the screen. It consists of two parts:
|
||||
|
||||
gencubeverts() and all the code above it takes the octree structure and
|
||||
turns it into a vertex array and index lists ready to be rendered. It currently
|
||||
does this for the entire level at once after a level load or edit, ideally
|
||||
it should be done for small parts of the level at a time (see below). This
|
||||
function cannot be called every frame (as it is in Cube) as it is quite
|
||||
expensive.
|
||||
|
||||
The actual structure of the code is to take each cube, compute the 8 vertices
|
||||
for it by intersecting the 6 faces defined by the 12 edge spans (the intersection
|
||||
functions are in "geom.c"). It also attempts to cull unneeded faces such as
|
||||
those of equal size and touching eachother. The hashtable at the top is used
|
||||
to not put duplicate vertices in the array.
|
||||
|
||||
This code is not easy to follow, but does a lot in very little code, so
|
||||
you will just have to read it to understand the details. As with everything
|
||||
in Cube/Sauerbraten :)
|
||||
|
||||
octarender() and the 2 functions above it render the scene, and as you can
|
||||
see are super simple (after all the work done by gencubeverts()). It renders
|
||||
all quads using any particular texture together, and uses texgen for the
|
||||
texture coordinates (which makes the vertex array very small at just 16
|
||||
bytes per vertex).
|
||||
|
||||
|
||||
World Editing
|
||||
=============
|
||||
This part I was in the middle of programming when I had to suspend work on it,
|
||||
so contains the most bugs/unfinished parts and crappy code.
|
||||
|
||||
How editing works is briefly explained in "readme_player_mapper.txt". Play
|
||||
with the editing functionality to get a feel of how it works.
|
||||
|
||||
cursorupdate() is the main function that gets called every frame in edit mode
|
||||
to update the rectangle, and a dragged selection if there is one.
|
||||
|
||||
editface() then implements the actual geometry modification with the mousewheel
|
||||
and the different key combinations.
|
||||
|
||||
Again, not easy to follow code, but not a lot of it considering that it implements
|
||||
pretty much the entire set of editing operations.
|
||||
|
||||
|
||||
Thing to be implemented
|
||||
=======================
|
||||
What follows is a list of items that would probably need to be implemented to make
|
||||
Sauerbraten into a fully usable engine. I have listed the items below roughly in
|
||||
the order which I think would be useful they would happen.
|
||||
|
||||
Quite a few of the items can be worked on by different people without interfering
|
||||
too much, i.e. one person can work on rendering issues, one on editing, on on
|
||||
collision etc.
|
||||
|
||||
- make the current editing features work in all situations (they currently work in
|
||||
some of the 6 orientations and not in others).
|
||||
|
||||
- add texture selection feature (should be easy). Suggested is a "move to front"
|
||||
texture list much like Cube, that is saved with the map. Texture slots and
|
||||
texture loading is already in the engine just like Cube. Maybe later a fancy
|
||||
texture selection window can be added.
|
||||
|
||||
- once the editing is fully working, remove the redundancy in the various
|
||||
editing related functions
|
||||
|
||||
- currently only NV_VERTEX_ARRAY_RANGE is used to upload vertex arrays to video memory
|
||||
after the level changes. ATI_VERTEX_BUFFER_OBJECT and ARB_VERTEX_BUFFER_OBJECTS
|
||||
should also be supported.
|
||||
|
||||
- collision detection. The physics dynamics sort of work from Cube, but there is no
|
||||
proper collision detection (there is an ad-hoc collision detection which treats the
|
||||
player as a "needle").
|
||||
|
||||
- currently the entire level is rendered into one big vertex array every time the
|
||||
level is loaded or edited. Not only is this very inefficient for editing, it doesn't
|
||||
allow frustrum culling and occlusion culling. The level should be split up at certain
|
||||
levels in the octree, depending on the number of nodes below it (i.e. a high detail
|
||||
area will result in smaller chunks and more split up than a low detail area).
|
||||
The target amount of cubes in a chunk should be tunable: large enough so that there
|
||||
are enough polys in it such that rendering it at once is efficient, and small
|
||||
enough so that culling algorithms are effective.
|
||||
To make this work with VAR and VBO, a simple memory manager should be implemented
|
||||
on top of the VAR or VBO which allocates parts of its memory for these chunks
|
||||
as needed.
|
||||
Once this works, frustrum culling should be implemented. Occlusion culling is more
|
||||
complicated and can be left for later.
|
||||
|
||||
- lighting. Currently there is a provision for vertex lighting in the "cube" structure
|
||||
which is being filled with random values at the moment as you can see in the
|
||||
levels. The lighting model is debatable, but for the kind of engine Cube is,
|
||||
doing things like shadow volumes or shadow maps is probably not feasible yet,
|
||||
meaning that again some form of lightmap or subdivided vertex lighting must be used.
|
||||
I would suggest that for surfaces below a certain size only vertex light be used,
|
||||
and for the larger faces the engine accumulates lightdata in a series of lightmap
|
||||
textures as required (subdivision would probably be unwise given the potential
|
||||
scale sauerbraten worlds can have).
|
||||
|
||||
- fix all those small little issues from the former cube gameplay code which stopped
|
||||
working (should not cost a lot of time). If all the above items are implemented,
|
||||
Sauerbraten should be able to run the old Cube multiplayer and singleplayer game
|
||||
without much problems, in much more impressive worlds!
|
||||
|
||||
- occlusion culling. Will be quite complicated to do well, should be left as last
|
||||
item to do until all other parts of the engine are matured. Once we get to this
|
||||
point I'd be happy to help brainstorm on possible good algorithms.
|
||||
|
||||
- many interesting features can be implemented beyond this point. We'll think of them
|
||||
once we get there :)
|
||||
|
||||
|
||||
Code style and simplicity
|
||||
=========================
|
||||
Many people may work on this code, all with their own coding styles and coding philosophies.
|
||||
If everyone just goes their own way things will become a mess, and noone will be happy.
|
||||
|
||||
Coding style is least problematic. It would be easiest if everyone just followed my style
|
||||
of formatting, identifiers etc. However if everyone agrees that they prefer a different
|
||||
style that would be fine too, as long the style is applied consistently (i.e. all old
|
||||
code is change to reflect the new style). One particular style I will forbid however, and
|
||||
that is the so-called "hungarian notation".
|
||||
|
||||
Coding philosophy is a harder topic. I am however assuming that people working on
|
||||
sauerbraten do so because they like Cube and its minimalistic engine design, and are
|
||||
excited by the possibilities Sauebraten's new world structure brings. That means that
|
||||
they are people that can agree with Cube's coding philosophy and may enjoy working with it.
|
||||
|
||||
Even though Cube's source code is not the prettiest (it is downright ugly in places),
|
||||
it overal VERY easy to read, which almost entirely due to its incredibly small size
|
||||
and simple algorithms. Lets face it, if you have to understand a physics system, there's
|
||||
no way you are going to easily find your way around a physics system that stretches 20
|
||||
.cpp and .h files with several pages of code each (even if its wonderfully designed),
|
||||
compared to Cube's 1 or 2 pages in a single file (even if its ugly).
|
||||
|
||||
Ever wonder why an engine that is simpler than Doom2 still gets so much attention in
|
||||
2004? And why nobody appears to do anything with all those hundreds of advanced engine
|
||||
projects out there? its because of this kind of thing.
|
||||
|
||||
Cube is about doing more with less (a lot less!) and Sauerbraten is no different. Its
|
||||
about elegant tiny algorithms, and using not a single line of code more than needed.
|
||||
I hope the programmers working on Sauerbraten will embrace this, and join in the fun
|
||||
"sport" that is simplicity, even if by their background they prefer to create collosal
|
||||
class hierarchies that include every version of the kitchen sink.
|
||||
|
||||
A misconception is that Cube's code philosphy is "anti-OO". This is not relevant at all.
|
||||
I'd be happy for people to convert all of sauerbraten into a neat bunch of classes.
|
||||
The _form_ of the code does not matter, as long as its the minimal, simplest, least
|
||||
redundant one. The problem with classes as used by most people is that they require
|
||||
to split up a part of the code between .h and .cpp, and also invite people to get
|
||||
serious with data hiding, introducing the dreaded get/set methods. All of this
|
||||
introduces useless clutter that will bloat up the code size of an engine several
|
||||
fold for no gain other than being "correct". And readability for anyone except the
|
||||
original writer will suffer.
|
||||
|
||||
If you want to create a class, I suggest you put it in a .h file in its entirety,
|
||||
improving readability immensely by keeping all code together. Really, the design of
|
||||
classes and the .h/.cpp idea don't work well together at all. Don't worry about executable
|
||||
code bloat by the appearent "inline" nature of this, most linkers have gotten very good
|
||||
at filtering this out nowadays. And unless you do the entire engine this way, you are
|
||||
not going to feel the compilations speed difference. And please forget about get/set.
|
||||
A small example is the "vec" class that is still a bunch of macros in the Cube code base.
|
||||
Important to notice is that it is still exactly the same amount of code as in Cube,
|
||||
however just a bit more readable than before.
|
||||
|
||||
Another think people worry about is the use of global variables in the code, because
|
||||
global variables are certified evil (tm). But think of it: an engine intrinsically has
|
||||
some global data it needs to store. So you put all of this in a class (or classes). But
|
||||
this engine really only uses one instance of this class, so you make it a singleton.
|
||||
Now you need to access this data. You write get() methods, and you litter your code
|
||||
with calls to them. You have just bloated your code, made it less readable, and all
|
||||
for what? for no change in actual structure whatsoever. In cube, a .cpp file is often
|
||||
implicitly a "singleton" already. Don't worry too much about being Politically Correct,
|
||||
worry about the actual structure of the code.
|
||||
|
||||
Doesn't all this hacking reduce maintainability? On the contrary. By keeping the code
|
||||
the simplest possible and accepting no redundancy, most modifications you want to make
|
||||
are simple because the code that is related to it is easy to isolate. Abstractions can
|
||||
be made when they are first really needed, rather than ahead of time and forgotten.
|
||||
|
||||
So when you work on Sauerbraten, try taking these steps:
|
||||
|
||||
- Make it a challenge thinking about the algorithm design before you start coding.
|
||||
What is the simplest thing that could possibly work? How can I make it such it
|
||||
requires less data structures or code, or simpler data structures and code?
|
||||
Don't think in terms of just getting features done. Just because all other engines
|
||||
make a certain feature look complex doesn't mean we have to follow.
|
||||
|
||||
- Once you got a cool base idea, discuss with other Sauerbraten programmers. There
|
||||
will be a thread on the messageboard for this. Maybe they have further simplification
|
||||
ideas.
|
||||
|
||||
- Implement using exactly the code needed to implement the algorithm without redundancy.
|
||||
Refrain from implementing any big "systems" or "managers" to help your cause. Make
|
||||
it a sport to be efficient with the amount of code your algorithm needs.
|
||||
|
||||
- spend as much time refactoring as you can. If things get a bit messy, don't just
|
||||
let it become worse but take some time to restructure things.
|
||||
|
||||
- Be careful to not implement tons of special purpose features that sound neat. Focus
|
||||
on features that have more universal power and can be used for a multitude of things.
|
||||
Once players/mappers start to use Sauerbraten, they will ask for endless features,
|
||||
most of them not very well thought out. Resist the temptation :)
|
||||
|
||||
|
||||
==========
|
||||
Wouter van Oortmerssen
|
||||
wouter@fov120.com
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.6 KiB |
|
|
@ -1,249 +0,0 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>Sauerbraten</title>
|
||||
<style type="text/css">
|
||||
body { margin: 50px 11%; width: 80%; background-color: #302c28; color: #ffffff; font-family: verdana,"trebuchet ms","zurich bt",tahoma,arial,helvetica,sans-serif; font-size: 8pt; }
|
||||
a { text-decoration: underline; color: #ffbb00; }
|
||||
a:visited { color: #ff9900; }
|
||||
a:hover { color: #ff9900; }
|
||||
div { margin: 40px 0px 4px 0px; padding: 1px; background-color: #662222; font-size: 120%; font-weight: bold; }
|
||||
pre { margin: 15pt 0pt 3pt 20pt; font-family: monospace; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div>Wiki remains</div>
|
||||
<p>The original Sauerbraten wiki met with an unfortunate accident when it was targeted by linkfarm bots. The text in this html is the unique information that was in there, in no particular order.</p>
|
||||
<p>Some of this material could be refactored / integrated in the docs if need be, but at least it is preserved for the time being.</p>
|
||||
<p>I'd rather have some serious people work on the official docs than restarting the wiki, it is just too much admin hassle. </p>
|
||||
<div>Portals</div>
|
||||
<p>Sauerbraten Portal Scheme (Occlusion Culling). </p>
|
||||
<p>Right now, Sauerbraten performs no occlusion culling. This is not a big issue right now, as it has very efficient geometry throughput, levels are relatively small, and the average graphics card nowadays seriously overpowers sauer's modest rendering requirements. </p>
|
||||
<p>As we move to the future, 2 things will make this problematic: first, shaders will increase the fillrate & pixelshader load, and in combination with larger levels (causing more overdraw), this will make the engine entirely fillrate/pixelshader bound. </p>
|
||||
<p>LOD will not help much here. Heavy fog can help but is a nasty solution. For many kinds of levels, real occlusion culling will be required. </p>
|
||||
<p>Occlusion culling is not trivial in sauer, because of its highly generic scene structure. One simple scheme that makes most sense on todays hardware is portals. </p>
|
||||
<p>This is how portals will be implemented in Sauerbraten (again, there is no urgent need for it right now, there are other things to be implemented first). </p>
|
||||
<ul>
|
||||
<li> level designers mark a selection of solids, and then execute a "makeportal" command. This will mark all cubes involved as "portal" and also make them nonsolid. Portals generally are placed in visibility bottleneck between larger areas, for example a doorway going into another room. The side of the selection that has the grid on has special meaning: this is the actual portal surface. The engine will keep track of these portal surfaces (the cube refers to the portal number). </li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li> as a preprocess phase it now recomputes all sectors (at some point we will combine "calclight", "remip" and "sectorize" into a single command to make a level suitable for distribution). What this does is very simple: repeat until all cubes are sectorized:
|
||||
<ul>
|
||||
<li> grab a non-solid cube </li>
|
||||
<li> flood fill all cubes reachable from there, not crossing solids or portal cubes. semi-solids have to be treated with care to see where to flood fill. </li>
|
||||
<li> mark all these cube with a sector number. A sector structure this refers to holds a list of all portal numbers found during this traversal </li>
|
||||
<li> portal cubes are made part of the sector which is not on the side of the portal plane </li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li> now when sauer goes through its process of generating vertex arrays for the level, it effectively treats each sector as a seperate level. When a surface gets generated (which, by definition, is because it touches a non solid cube), the sector of that cube gets checked and the surface added to the vertex arrays of that sector. </li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li> This all means the following addition data
|
||||
<ul>
|
||||
<li> two numbers in a "cube" structure: portal and sector. portal==0 means no portal </li>
|
||||
<li> a boolean in the map header that says wether sector information is valid. it gets set after a sectorize, and reset whenever geometry is edited </li>
|
||||
<li> a vector of struct portal, each of which has 2 sector ids, and portal surface dimensions </li>
|
||||
<li> a vector of struct sector, each of which has a vector of portal ids, and a list of vertex arrays </li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li> when rendering, do the usual portal things. For the record: Find the sector the camer is in, and render it. Find the list of portals. Test each with the view frustrum and only retain the visible ones. Render all sectors connected to the visible portals. Collect the list of portals touching those sectors, and intersect them with the first set of portals, rather than the view frustrum. With correct portal placement, this soon reduces the set of visible portals to zero, and thus rendering is done. </li>
|
||||
</ul>
|
||||
<p>Of couse highly effective in indoor, it can still help in outdoor, though fog & LOD may be additionally required to help. Fog + portals can still cull effectively outdoor, i.e. an area can be culled from rendering even though it is within the fog distance, because the portal to it is outside the fog distance. Clever use of mountains and large buildings can help. </p>
|
||||
<p>Placing too many portals can hurt performance, as sectors fragment GPU workloads. Sectors need to be at least an entire detailed "room" or area. </p>
|
||||
<p>Implementation is well defined, but a fair bit of work making it all run smooth.</p>
|
||||
<div>
|
||||
Heighfields</div>
|
||||
<p>Algorithm for creating heighfields in Sauerbraten. </p>
|
||||
<p>The problem is that you can't create a heighfield of more that 1 cube high, as then slanted surfaces would cross cube boundaries, and not all combinations are representable. </p>
|
||||
<p>Solution: create the heighfield (I have a very good noise function). heighfield will be created inside the current 3d selection, taking into account grid size and orientation. Example, a 10x10 heighfield 5 deep has 40 (5x8) possible heighlevels. </p>
|
||||
<p>First pass: go through all X and Y edges and detect the ones that cross a cube boundary (e.g., out of 0 to 40 depth, an edge doing from 2 to 8 doesn't cross a boundary, but one that goes from 2 to 9 does). Snap the height of the corner closest to a cube boundary, in this case make the 9 an 8. After this, there is the possibility that an edge will span 2 cubes still... the higher of the 2 then has to be brought down till that is no longer the case. </p>
|
||||
<p>After this, it is trivial to generate the actual cube data structures. </p>
|
||||
<p>For heighfield editing functions such as applying a raise/lower circular "brush" to terrain, you can have a function to compute heighfield data from the current cube nodes, apply the operation, then apply the above algorithm again. </p>
|
||||
<p>This will do some damage to the heighfields form, but hopefully not that much, and will give the heighfield its own style. </p>
|
||||
<div>New Weapons </div>
|
||||
<h3>Discussion can be followed <a href="http://cubeengine.com/forum.php4?action=display_thread&thread_id=237">here </a></h3>
|
||||
<p>...coding new weapons. </p>
|
||||
<p>So it's my duty to detail step 2. ;) </p>
|
||||
<p>I sure hope that you've guessed you'll need to edit weapons.cpp. Add required stuff in cube.h Modify the weapon selection commands to be able to select it. Then you need to make ammo for it, use the .md2 of any weapon ammo, and edit the skin.jpg with a nice logo for your new shiny weapon. make a items_yourmodname.png with original Cube items, but this one is 256*256 instead of 192 so you can add new nice stuff, and modify renderextras to display your weapon logo on the HUD Then modify something like -don't remember- world.cpp or editing.cpp so that you can do /newent ammoforthisweapon eventually model a hudgun or use an existing one. I think i didn't forgot something. </p>
|
||||
<p>You should eventually wait that i release the modbase, i've added some new weapons in it, and am planning modifying a bit the code to make adding new weapons easier, plus there is a new moveprojectiles function to use weighted projectiles with curve path and bouncing ones (Cube weaponfactory ;) But since that already playing with Cube source to understand and know it well is fun :) </p>
|
||||
<p>-- D.plomat </p>
|
||||
<p>This is the area you can change in weapons.cpp if you desire to just modify an existing weapon. Adding weapons as D.polmat says requires more than one file edit. </p>
|
||||
------8<----cut here----- struct guninfo { short sound, attackdelay, damage, projspeed, part; char *name; }; const int MONSTERDAMAGEFACTOR = 4; const int SGRAYS = 20; const float SGSPREAD = 2; vec sg[SGRAYS]; guninfo guns[NUMGUNS] = { { S_PUNCH1, 250, 50, 0, 0, "fist" }, { S_SG, 1400, 10, 0, 0, "shotgun" }, // *SGRAYS { S_CG, 100, 30, 0, 0, "chaingun" }, { S_RLFIRE, 800, 120, 80, 0, "rocketlauncher" }, { S_RIFLE, 1500, 100, 0, 0, "rifle" }, { S_FLAUNCH, 200, 20, 50, 4, "fireball" }, { S_ICEBALL, 200, 40, 30, 6, "iceball" }, { S_SLIMEBALL, 200, 30, 160, 7, "slimeball" }, { S_PIGR1, 250, 50, 0, 0, "bite" }, }; ----------end cut----------
|
||||
<p>Take note of the structure, the first variable is the sound it makes. And part should be zero unless your weapon has a visible projectile. </p>
|
||||
<p>-- Slipstream </p>
|
||||
<div>Building on windows </div>
|
||||
<p>Below is a short guide for allowing programmers to edit and compile Sauerbraten source code on Windows. <br>
|
||||
Keep in mind that the batch file for this guide is also available <a href="http://cube.snieb.com/node/92">here </a>. </p>
|
||||
First you need msys and mingw. Get them here: <a href="http://www.mingw.org/">http://www.mingw.org/ </a> First install mingw into (recommended) c:\msys\mingw and then install msys into c:\msys. Add C:\msys\mingw\bin (or wherever mingw32-g++.exe is) to your path (Control Panel -> System Properties -> Advanced -> Environment Variables -> Edit System Variables). You'll know you got the path right when you can run "mingw32-gcc -v" from a command window anywhere and not get an unknown command error.
|
||||
<p>Now grab this: (you need to download the cvs program in order to grab the source files) <a href="https://ccvs.cvshome.org/files/documents/19/886/cvs-1-11-20.zip">https://ccvs.cvshome.org/files/documents/19/886/cvs-1-11-20.zip </a><br>
|
||||
or if it's been a long time since I wrote this a newer version from: <br>
|
||||
<a href="https://ccvs.cvshome.org/servlets/ProjectDocumentList?folderID=83&expandFolder=83&folderID=80">https://ccvs.cvshome.org/servlets/ProjectDocumentList?folderID=83&expandFolder=83&folderID=80 </a><br>
|
||||
Place cvs.exe in c:\windows or some other folder in your path. </p>
|
||||
<p>Create a bat file in c:\ and put in there: (or download it from <a href="http://cube.snieb.com/node/92">http://cube.snieb.com/node/92 </a>) <br>
|
||||
cvs -d:pserver: <a href="http://strlen.com/wiki/index.php?id=ProtectedEmail&encoded_email=Sj5gPmJFYFs4NVlTOFo4YFtyWUJXYHJ4Qlo%2BQnA%3D">anonymous»cvs </a>:/cvsroot/sauerbraten login <br>
|
||||
cvs -z3 -d:pserver: <a href="http://strlen.com/wiki/index.php?id=ProtectedEmail&encoded_email=Sj5gPmJFYFs4NVlTOFo4YFtyWUJXYHJ4Qlo%2BQnA%3D">anonymous»cvs </a>:/cvsroot/sauerbraten co -P sauerbraten <br>
|
||||
PAUSE </p>
|
||||
<p>If that worked, you'll now have a c:\sauerbraten. Usually the exe isn't too far behind, but the latest features may only be in source. To get those run c:\sauerbraten\make.mingw.bat. If that errors on your first try you're probably SOL and will need to wait a day for a version that builds. If errors on subsequent builds then the header probably changed and you should run makeclean.mingw.bat and try again. If it built and it most likely did, go to c:\sauerbraten\sauerbraten\ and copy the sauerbraten.bat file and edit it to refer to bin\sauerbraten-mingw.exe instead of bin\sauerbraten.exe. Change the resolution to your liking and enjoy! </p>
|
||||
<p>If you like, you could also download and install Bloodshed's Dev-C++ for a good lightweight IDE to aid in reading all the sourcecode. <a href="http://www.bloodshed.net/devcpp.html">http://www.bloodshed.net/devcpp.html </a></p>
|
||||
<div>Ambient Lighting </div>
|
||||
<p>(From Sauerbraten engine development thread) </p>
|
||||
<p>post#980: Re: ambient lighting </p>
|
||||
<p>by Aardappel_ on 07/03/2005 16:43 </p>
|
||||
Yes there is already ambient light, fixed at about 10%
|
||||
<p>For those of you who think shadows are all black: you either have a very crappy monitor or have weird settings (like super high contrast). </p>
|
||||
<p>The reason <strong>ambient lighting </strong><a href="http://strlen.com/wiki/index.php?id=ambient+lighting">? </a>is fixed is because 99% of the time people want to raise it, they do so is for the wrong reasons. Repeat after me: GOOD LIGHTING SHOWS CONTRAST. Not every polygon needs to be touched entirely by light. Shadows are good (if people hiding in the dark is a problem gameplay wise, we will solve that otherwise... they already show up less dark). </p>
|
||||
<p>Learn to light levels properly. Start with the biggest, most prominent lights first and continue on down as required. For many levels that means the correct placement of a sunlight (newent light 0 255 200 100) somewhere high up. </p>
|
||||
<p>see also </p>
|
||||
<ul>
|
||||
<li><a href="http://cubeengine.com/forum.php4?action=display_thread&thread_id=286&start=986">post 986 </a></li>
|
||||
<li><a href="http://cubeengine.com/forum.php4?action=display_thread&thread_id=286&start=987">post 987 </a></li>
|
||||
</ul>
|
||||
This post is pretty much straight from the sauer dev thread <a href="http://cubeengine.com/forum.php4?action=display_thread&thread_id=286&start=960">here </a>
|
||||
<p>I added some punctuation, fixed capitalization, and added a few words so it would make more sense. </p>
|
||||
<p>edited by mreynolds </p>
|
||||
<div> Sauerbraten future development timeline </div>
|
||||
<table cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td><p> A lot of people are interested in Sauerbraten for different reasons. And even though I still control it, the development of it is more open, and more people influence it than Cube. <br>
|
||||
<br>
|
||||
For an open source project to be successful, there needs to be a balance between the community, and a person with a central vision. A lot of things that are cool about cube, and now sauerbraten again, is because I had a particular design vision. A community without leadership will not produce good designs. So for Sauerbraten I want to continue setting clear goals for whoever works with me on it, but at the same time I want to be more open to make sure it is ideal for a larger community, and I especially want to accommodate the larger contributors, meaning the programmers that may have their own plans, and the more active level designers. <br>
|
||||
<br>
|
||||
So without further blah, here's how I see the development phases of Sauerbraten. <br>
|
||||
<br>
|
||||
1) Get the core engine tech to a stage where the engine is fully usable. <br>
|
||||
STATUS: We just finished this stage! Congrats to all involved! <br>
|
||||
<br>
|
||||
2) Get a basic FPS game along the lines of Cube, but slightly enhanced, up and running. For those of you who are wondering what the point of this step is: the biggest failure of most engines is that they are engines, not games. It is very hard to take an engine an build a game for it without an existing framework. Many people are interested in using sauerbraten as a base for a game. And what is the most basic gameplay you could give a 3D engine? that's right, an FPS. Especially since we already have the base cube gameplay to work from. <br>
|
||||
STATUS: we are 70%-80% done on this one, I estimate. Most of it appears to work, but a lot of refinements can be made. At some point this gameplay will be mostly frozen, much like Cube. Most importantly we need to figure out how we want to do multiplayer, given that currently it is wide open for cheating. <br>
|
||||
<br>
|
||||
3) [this can actually be in parallel with 4 & 5]: improve engine tech. Geometry thruput optimisations, Level of Detail, Occlusion Culling, and a shader system are the most important items on the list here, but there are tons of other features that will keep on enhancing/refining the engine. <br>
|
||||
STATUS: planning/design. Currently we are not in a total hurry with these features as the engine is running rather nicely already. But we can do better and we will. <br>
|
||||
<br>
|
||||
4) Gameplay & Engine seperation. Several people want to do widely different games with Sauerbraten. I don't want us to get in the same situation as most engine (Cube especially) where making a "mod" means forfeiting future engine development, or worse, mods add their own cool features that don't benefit the main branch. That's why I want to organize a system whereby we can have a main, shared engine, and multiple gameplay modules. For this it is also important to have the FPS gameplay polished, that way every gameplay module can be based off the FPS module and have something working to start with. <br>
|
||||
Even better, since this item will require a LOT of reorganisation in the engine, there will be quite a bit of time afterwards where things have to be restructured. To do this most smoothly, I will propose an organisation where all main gameplay projects (serious ones, approved by me) sit together in the same CVS, and initially even in the same program, toggleable by a commandline switch. This means that if you change the engine or the gameplay interface, you get to compile other people's gameplay modules as well, and verify wether you haven't broken their code, or even make simple fixes (such as when adding additional parameters etc.). <br>
|
||||
I am also open to thinking about a better scripting language, if time permits I will create one, such that we can move as much as possible out of the engine and allow non C++ programmers to make mods. <br>
|
||||
STATUS: I will do the initial engine restructuring to allow this to happen, but I'd like to postpone this as long as possible. <br>
|
||||
<br>
|
||||
5) The sauerbraten RPG. This will be the main gameplay module seperate from the FPS module, designed by yours truely. I have particular ideas for this, but since our life will be simpler if we don't have 3 million different gameplay projects ongoing (we also have a limited pool of level designers), I will try to scope this project such with major programmer & level designer contributors such that we can all work on a single project, if possible. It may be that our wishes are non-unifyable, so be it, but I will give it a try. I think it can be done. <br>
|
||||
STATUS: Once we are past (4) and some of (3), I will lay out my plans... but if you dig through old threads on this forums you can find some of it :) <br>
|
||||
</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><img src="wikistuff_spacer.gif" height="20" width="1"></td>
|
||||
</tr>
|
||||
</table>
|
||||
<div>Wiki usage </div>
|
||||
<p>The Cube forum ( <a href="http://www.cubeengine.com/forum.php4">http://www.cubeengine.com/forum.php4 </a> ) contains many large posts containing valuable information, which all too often is very hard to find. </p>
|
||||
<p>From now on, whenever I am explaining something that is a larger text, I will put it on the wiki and link to it on the forum instead. That way it will be easier to build up a knowledge base. </p>
|
||||
<p>The first example is my post about portals. </p>
|
||||
<p>I strongly encourage you to do the same. Let's build this wiki up together and make it a dual to this forum. Knowledge goes in the wiki, temporal stuff and discussion goes in the forum. Things can move from the forum to the wiki once discussion has reached a conclusion. </p>
|
||||
<p>Infact, I would be VERY grateful if someone wants to go through old threads and isolate the most valuable posts, and put them in the wiki in a logical way. </p>
|
||||
<p>What the wiki is for: </p>
|
||||
<p>The main focus for the wiki is Sauerbraten. That means that any wiki page not marked otherwise is about sauer. It also be nice to collect Cube information in the wiki, but it needs to be marked as such, since eventually sauer will take over entirely. So, for example, <strong>EngineFeatures </strong><a href="http://strlen.com/wiki/index.php?id=EngineFeatures">? </a> is about sauer, and <strong>CubeEngineFeatures </strong><a href="http://strlen.com/wiki/index.php?id=CubeEngineFeatures">? </a> is about Cube. </p>
|
||||
<p>I welcome additional pages that are indirectly related to these 2 engines. Examples are pages about engines & engine algorithms in general, about gameplay, level design, tools, art, or even about any of my other projects. </p>
|
||||
<p>There are two main uses however, and that is documentation about sauerbraten for players and mappers on the one hand, and for developers (engine specifics) on the other hand. So those should take the forefront. Make a very clear distinction between something that is *information*, and something that is just your *idea*. I know people have written interesting texts on their ideas for gameplay, or certain engine features. Until I or any of the other main contributers are implementing them, these are not part of the project. So seperate ideas out by making a wikipage for yourself (e.g. <strong>PushPlay </strong><a href="http://strlen.com/wiki/index.php?id=PushPlay">? </a>) and then link your ideas from there (e.g. <strong>PushPlayGameModes </strong><a href="http://strlen.com/wiki/index.php?id=PushPlayGameModes">? </a>), rather than putting them in to the main documentation directly. Ideas are still welcome, but for a random new user that needs help on the engine, it should be easy to distinguish fact from fiction. </p>
|
||||
<p>This wiki comes with a bunch of admin tools, that allow me for example to roll back a page or the entire wiki. That should allow protection against spam bots & griefers. We will see how this goes. If we get too much trouble we may move to a more private wiki. I will also at some points give admin rights to some trusted contributers. Please alert me if you think a major attack on the wiki has been made. For small problems, just fix them yourself. The wiki stores all its content in a bunch of flat files, which allows us to do frequent backups, export to offline html, and easy migration. </p>
|
||||
<div>Edge Spans </div>
|
||||
<p>The method that <a href="http://strlen.com/wiki/index.php?id=Sauerbraten">Sauerbraten </a> uses to describe deformed cubes consists of the start and end location of each edge of the original cube. These start and end locations, along with those of the other 11 edges, define 6 faces. For a complete, normal, solid cube those 6 faces form an actual cube shape, with start and end locations at their maximum distance from each other. Once you begin deforming the cube those planes begin to carve out the sides of the cube, and what is left inside the intersections of the planes is the resulting smaller deformed cube. </p>
|
||||
<p>Here is an illustration of this concept in 2D, using only 4 edges to define a deformed square. Notice that as the edges are pushed in, the remaining portion of the square is whatever is left inside the edges. In this illustration the start of the span for the top and left edges is being pushed in. </p>
|
||||
<p><img src="edgespans.gif" alt="edgespans.gif" width="193" height="193"> (no picture means the wiki is still broken, two pictures means the page should be edited) </p>
|
||||
<p>Notice that while the edge spans always start and end on integer grid marks, the resulting corners of the deformed cube often do not. Also note that the deformed cube tries to avoid becoming concave. This means that in some cases you get prettier corners because of better approximations of curves, and that the rendering code can be very elegant, but it also means that many conceivable shapes inside a cube cannot be realized. </p>
|
||||
<div>Using free tools to produce .md2 models </div>
|
||||
<p>In this small tutorial I will try to explain how to use Blender v2.36 with the Quake 2 modeller to produce and texture a simple mesh for use with Cube. </p>
|
||||
<p>Disclaimer: I can't guarantee that the tutorial will be of any use to anyone. If you arise damages from the tutorial, I don't want to know about it. </p>
|
||||
<p>What we need: </p>
|
||||
<p>=> Blender 2.36 and the Blender md2 import/export scripts by Bob Holcomb (script files must be put in the .blender/scripts folder in order to work) </p>
|
||||
<p>=> The Quake 2 modeller by Phillip Martin and Jaimi <strong>McEntire </strong><a href="http://strlen.com/wiki/index.php?id=McEntire">? </a> (hopefully v0.91b) </p>
|
||||
<p>First let's start by creating a cube in Blender. I assume you have some basic knowledge on how to use this program, otherwise from now on it may be a little hard to follow. Place the cursor in a 3D View window, hit spacebar and select add=>mesh=>cube. In edit mode, press A to select all if needed (not needed in our case because all is selected by default, but good to know anyway), then click the Mesh menu and select faces=>convert quads to triangles. Use keypad 1, 3 and 7 or SHIFT + the latter to change top and side views. Keypad 5 switches between perspective and orthogonal view. Once you've chosen a view enter UV face select mode and press U. Choose Bounds to 1/1 or experiment with other options. When you've made your choice enter the UV/Image editor window, select an image, go back to 3D view, enter Object mode and press ALT+Z to see your model textured. If you have difficulty with all those hotkeys look for corresponding commands in the menus, personally in most cases I find it more convenient to use a hotkey. </p>
|
||||
<p>After you export the mesh, open the .md2 file with Quake 2 modeller. You need to have UV mapped the mesh in Blender even if you didn't select a texture, otherwise it may not load properly. Select, move, scale, manage frames, export to md2 and try with Cube. </p>
|
||||
<p>This way of producing Cube model data is not very reliable. Nonetheless, I think the information presented here or parts of it may be useful to Cube people. </p>
|
||||
<div>Troubleshooting</div>
|
||||
<h4>Rockets explode in your face or bullets do not fly. </h4>
|
||||
<p>This happens due to buggy ATI drivers for unix/linux operating systems. Download the fix from Sourceforge- <a href="http://sourceforge.net/project/showfiles.php?group_id=91993">http://sourceforge.net/project/showfiles.php?group_id=91993 </a> Once you have downloaded the file, unzip it and you will discover a file named linux_client. In your Cube folder, there is a folder called bin_unix, which contains a file with the same name as the one you have just unzipped (linux_client). Simply replace the linux_client file in there with the new one. Cube should now run correctly. </p>
|
||||
<h4>error loading shared libraries </h4>
|
||||
<p>This is quite a common error. Something like - error while loading shared libraries: libSDL_image-1.2.so.0: cannot open shared object file: No such file or directory </p>
|
||||
<p>This means you do not have the SDL libraries installed (or possibly that you are running a 64bit version of Linux) You need to install the SDL libraries for the following SDL types- SDL SDL_gfx SDL_image SDL_mixer SDL_net SDL_sound SDL_ttf Note: For 64 bit Linux, you may be able to run Cube with 32 bit emulation if there is a 32 bit emulated library for SDL in your distro. But Cube is a 32 bit game and I personally have had no success with running it on a 64 bit distro. </p>
|
||||
<h4>ALSA sound errors </h4>
|
||||
<p>ALSA lib pcm_hw.c:1155:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy Fatal signal: Segmentation Fault (SDL Parachute Deployed) Or a similar message means that your ALSA driver is currently in use. Shut down any program which may be using it. Also worth noting - if you run KDE, go to the KDE Control Centre, click it and select the Sound and Multimedia tab. There, select the Sound System tab. This will open the Sound System settings. Near the bottom is a sliding button marked auto-suspend if idle after... Slide this to the lowest setting (1 second) and ensure the tick box is checked next to it. Apply as usual. </p>
|
||||
<h4>couldn't load texture data/newchars.png </h4>
|
||||
<p>If you get this error trying to run Cube, it means you are attempting to run the actual binary in the /bin_unix folder. To run cube, simply navigate to the cube directory and run the cube_linux shell script. See the installation page of the Wiki for further details on how to run Cube in Linux. </p>
|
||||
<h4>Screen goes black and then returns to my desktop </h4>
|
||||
<p>Various errors can cause this problem. To discover exactly which one is causing your issues, try running Cube from a command line. This will give an error message which you can then check against this Troubleshooting guide. </p>
|
||||
<h4>libGL error: open DRM failed (Operation not permitted) <br>
|
||||
libGL error: reverting to (slow) indirect rendering </h4>
|
||||
<p>The DRI interface to your card can't be accessed directly because Linux has set restrictive access permissions on it for security (eg. 660). Fix this by changing the permissions to 666. Exact details vary, but here are some examples: </p>
|
||||
<p>chmod 666 /dev/dri/card0 (Gentoo 2.6.8 x86 with ATI Radeon 7000/VE) <br>
|
||||
chmod 666 /dev/nvidia* (Gentoo 2.4.26 x86 + nVidia 5200, and 2.6.11 x86_64 + nVidia 6600) </p>
|
||||
<p>If you find that your fix keeps getting reset on boot, then edit the file /etc/security/console.perms --- just remove all lines containing "<dri>" if the <dri>= line mentions any of the /dev entries above. Or alternatively, don't delete anything but change the <dri> permissions numbers to 0666. Take a copy of the original file first before you hack it, of course. </p>
|
||||
<h4>Something about old versions in multiplayer online games..... </h4>
|
||||
<h4>Something about compiling from source making your Cube incompatible with online games.... </h4>
|
||||
<p> </p>
|
||||
<div>Installing Cube </div>
|
||||
<p>Firstly, download the latest Cube release from <a href="http://sourceforge.net/project/showfiles.php?group_id=91993">http://sourceforge.net/project/showfiles.php?group_id=91993 </a></p>
|
||||
<p>Now you can unzip it in whatever directory you wish to run the game from - most likely this will be your home directory. How you unzip it is up to you - choose whichever method you are most comfortable with - if you have KDE and have installed the KDEutils package, then Ark will probably be the easiest way - but gunzip or the tar command also work fine. This will create a folder called cube. Thats it - there is no make or other commands to run - cube is ready to roll! </p>
|
||||
<p>Cube needs the SDL libraries to run - so you need to check out your distributions file repository or your CDs to get hold of these. If you cannot locate them,then they can be obtained from <a href="http://freshmeat.net/projects/sdl/">http://freshmeat.net/projects/sdl/ </a> in various formats - though if possible, your distros file repository or CD is a lot easier. </p>
|
||||
<p>To run cube,you do not click the binary file as you may think. You need to use the command line to cd into the cube folder, then once there, you use the command </p>
|
||||
<p>./cube_unix </p>
|
||||
<p>to start the game. You can pass parameters to this command to alter, for instance,the screen size - </p>
|
||||
<p>./cube_unix -w1024 -h768 </p>
|
||||
<p>for instance sets a 1024x768 screen. Passing -t ( with or without the -w and -h settings ) runs cube windowed. There are other options - feel free to explore the documentation which comes with Cube. </p>
|
||||
<p>Tip - If intending to play online, please set a username and team name in the autoexec.cfg file - there are too many Unnamed players on Team Blah ;) </p>
|
||||
<h3> Distribution-specific information </h3>
|
||||
<p>Although there is considerable variation in how different distros manage libraries and dependencies, the list of top-level dependencies specified in the sources tree is fairly constant: </p>
|
||||
<p>libGL.so.1 <br>
|
||||
libGLU.so.1 <br>
|
||||
libz.so.1 <br>
|
||||
libjpeg.so.62 <br>
|
||||
libpng.so.3 <br>
|
||||
libSDL-1.2.so.0 <br>
|
||||
libSDL_image-1.2.so.0 <br>
|
||||
libSDL_mixer-1.2.so.0 </p>
|
||||
<p>The subsections below give some information on how these are satisfied and/or any distribution-specific installation details. If you are having trouble, check out the <a href="http://strlen.com/wiki/index.php?id=Troubleshooting">Troubleshooting </a> page. </p>
|
||||
<h4> Gentoo x86 </h4>
|
||||
<p>NOTE: As of 11/21/05 it appears that the gentoo Portage version described below is out of date. Anyone know who is responsible for maintaining the cube package in gentoo? </p>
|
||||
<p>If you're running Gentoo on x86 hardware, at the time of writing (25 June 2005) there is a Gentoo ebuild (games-fps/cube-20040522) for the latest platform-independent Sourceforge download which is " <strong>2004_05_22 </strong><a href="http://strlen.com/wiki/index.php?id=2004_05_22">? </a>.tar.gz". This makes installation very easy, since dependencies will be resolved automatically and any necessary packages will be brought in first. </p>
|
||||
<p>To install, just login as root and type "emerge cube". Then, as an ordinary user in an xterm window, just type "cube_client-bin" to play in fullscreen, or "cube_client-bin -t" to play in a window. </p>
|
||||
<p>This assumes that you have /usr/games/bin in your path. If you don't, then "export PATH=$PATH:/usr/games/bin" will add that directory to your path. Or do yourself a favour and set up a symlink "ln -s /usr/games/bin/cube_client-bin /usr/local/bin/cube", so that you can run Cube by just typing "cube". </p>
|
||||
<p>For reference, Gentoo x86 on a 2.4 box with nVidia graphics satisfied the install dependencies with these ebuilds automatically: </p>
|
||||
<p>media-video/nvidia-kernel-1.0.6629-r4 <br>
|
||||
media-video/nvidia-glx-1.0.6629-r6 <br>
|
||||
sys-libs/zlib-1.2.2 <br>
|
||||
media-libs/jpeg-6b-r4 <br>
|
||||
media-libs/libpng-1.2.8 <br>
|
||||
media-libs/libsdl-1.2.8-r1 <br>
|
||||
media-libs/sdl-image-1.2.3-r1 <br>
|
||||
media-libs/sdl-mixer-1.2.6 <br>
|
||||
games-fps/cube-20040522 </p>
|
||||
<h4> Yoper 2.x </h4>
|
||||
<p>In the 2.x Yoper repositories, you will find all the SDL libraries needed for Cube. Simply use either the synaptic program and install the SDL libs, or, if you prefer the command line, use the apt-get command. There is a Yoper Cube team thread within the forum on the Yoper site should you wish to chat about the game - or join in with the team games which we run from time to time. Currently, there is no Cube rpm in the repositories - however the Cube installing information at the top of the page will allow you to install Cube easily. </p>
|
||||
<div>TOGoS's Map Linking ideas </div>
|
||||
<p>Map linking in Sauerbraten is completely theoretical at the moment. Development is not yet to that point, and it is not clear that it ever will be. It does seem like a terrific idea, though... </p>
|
||||
<h3> A possible way to implement map linking </h3>
|
||||
<p>First, cubes can be named. This may be as in Cube where a set of map cells are given a tag number, or it may take the form of an actual text name. This is useful for obvious reasons: once a cube is named, you can reference it to script operations like "copy the contents of cube 'doorA-open' to cube 'door1'" for more dynamic maps. </p>
|
||||
<p>Second, cubes can be marked as referencing external maps. For instance, you might select a cube and say to sauer "make this cube an instantiation of 'TOGoS/cool-pillar.ogz'. Similarly, you could make the cube a portal rather than a simple instantiation. The difference being that when the player enters a portal cube, he is seamlessly teleported to the specified section of the referenced map. </p>
|
||||
<p>Now for portals, instead of referencing an entire map, the cube would reference only a named part of a map. This way we avoid the problem of having a link to a map that has a link to us and ending up having an infinite number of our map within the linked to map :) </p>
|
||||
<p>This diagram shows what I am talking about: <img src="sauerlink1b.png" alt="http://i3.photobucket.com/albums/y85/TOGoS/Diagrams/sauerlink1b.png" width="512" height="384"></p>
|
||||
<p>Note that the idea of loading maps off remote web servers is totally unrelated to multiplayer games. </p>
|
||||
<p>Also as proposed by <strong>JerryBean </strong><a href="http://strlen.com/wiki/index.php?id=JerryBean">? </a> a while back, I think having a linked list of name=>value attrivutes for each cube would be very helpful for this kind of thing. ( "id"=>"foo" to set the name of a cube, "object-url"=>"TOGoS/chair1.ogz" to use an ogz-based model, "portal-url"=>"TOGoS/maps/coolio.ogz#main" to link to another map ). </p>
|
||||
<h3> Pseudo-random infinite worlds using a server-side map generator </h3>
|
||||
<p>Say map linking was implemented as described above, allowing links to maps using HTTP. There's a directory (or what appears to be a directory, anyway) on a web server containing an infinite number of sauer maps, like so: <a href="http://mycoolsauermaps.com/world15/+12-8+4.ogz">http://mycoolsauermaps.com/world15/+12-8+4.ogz </a>. When the Sauerbraten engine sees that that map is linked to, it will fetch it from that URL. As far as Sauer is concerned, there is nothing special about that map. </p>
|
||||
<p>But that map might not actually exist. If nobody has uploaded such a map to the server (presumably using a fancy version of savemap, maybe requiring a password, probably implemented with HTTP PUT), a program on the server will automatically generate such a map. In this case the numbers +12-8+4 have a special meaning - those are the coordinates of the map. This map would in turn have links to maps +12-8+5, +12-8+3, +12-7+4, +12-7+5, etc (26 links total - one in each direction, including the diagonal ones). </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,164 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html
|
||||
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
|
||||
<head>
|
||||
<title>Cube 2: Sauerbraten - Map Editing</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css" />
|
||||
<link rel="shortcut icon" href="favicon.ico" />
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<h1>Cube 2: Sauerbraten - Map Editing</h1>
|
||||
|
||||
<div class="contents">
|
||||
<ul class="contents">
|
||||
<li>
|
||||
<a href="#editing_in_cube2"><b>Editing In Cube 2</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#the_basics"><b>The Basics</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#entities"><b>Entities</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#lighting"><b>Lighting</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#materials"><b>Materials</b></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#cheat_sheet"><b>Cheat Sheet</b></a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<h2 id="editing_in_cube2">Editing In Cube 2</h2>
|
||||
|
||||
<p>
|
||||
Editing isn't like editing in any other game/engine; it is done within the program itself, and the
|
||||
structure of the map is comprised of octrees. Octree may sound confusing but it's actually a pretty simple idea.
|
||||
Imagine a cube you can do two things to: push the corners at any angle inwards, or split the cube into 8 smaller cubes
|
||||
(4 cubes in the top half, 4 cubes in the bottom half) which you can do the same things to. That's all there is to it!
|
||||
Below is an example cube where it is split and one cube is removed, and then again for a smaller cube.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="dev/editing1.jpg" alt="Editing Example 1" />
|
||||
<img src="dev/editing2.jpg" alt="Editing Example 2" />
|
||||
<img src="dev/editing3.jpg" alt="Editing Example 2" />
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With that out of the way: fire up the game and press E. This is edit mode. The first thing you'll notice is a faded
|
||||
outline of the face of the cube pointed to by your cross hair. If you click on this face it will be selected, and will
|
||||
be outlined by a solid outline. You can click and drag to select multiple faces of cubes. Press space to deselect all cubes.
|
||||
When you have cubes selected, all editing commands will go to those cubes, otherwise it will go to the cube face you are pointing at.
|
||||
Also notice the blue sparklies in the map. These are entities. They control things such as ammo, player spawns, lights, etc.
|
||||
In the bottom left above your health you'll find text stating what the closest entity is and what properties it has.
|
||||
The effect properties have depend upon the type of entity.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="dev/editing4.jpg" alt="Editing Example 4" />
|
||||
</p>
|
||||
|
||||
<h2 id="the_basics">The Basics</h2>
|
||||
|
||||
<p>
|
||||
Go into edit mode (E) and press ` to open a console (pressing T then / has the same effect) and run the command <i>/newmap 7</i>.
|
||||
This command creates a blank map, where smaller numbers create smaller maps and larger numbers create larger maps.
|
||||
Editing commands are performed on the cube you selected by clicking and dragging, or the face you are pointing at if none are selected.
|
||||
Press space to deselect. Point at the ground near you and roll the mouse wheel towards you. This creates a new cube towards you.
|
||||
New cubes can only be created by "pulling them out of" adjacent cubes. So if you want a cube floating in the middle of the air,
|
||||
you're going to need some temporary cubes going from the ground or a wall to there. Pushing the mouse wheel forward deletes the cube.
|
||||
Either by selecting faces or just pointing at them try to create a structure 3 high and 3 to the right like an upside down L.
|
||||
Now try holding G and move the mouse wheel towards you once. The selection size is now one step smaller. Any space you alter
|
||||
at this grid size will be made up of smaller cubes, which will take more time to render but allow finer detail. The finest
|
||||
grid size is much smaller than this, and the max size much much larger. Try adding a smaller L coming out of your bigger one for practice.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Now, let's edit those corners. To select corners press and hold Middle Mouse Button, much the same as selecting with the Left Mouse Button.
|
||||
Try playing with the mouse wheel. This will push or pull the selected corners. Now make a selction with Left Mouse Button. Hold F and scroll
|
||||
with mouse. This edits all 4 corners at once. These operations may seem simple but they allow for the creation of complex geometry.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By now you should have an idea of how most editing operations work. Hold a modifier button and use the scroll wheel to change the
|
||||
selected cubes or the one you're pointing at. It naturally follows that changing the texture of a face of a cube is as simple as holding
|
||||
Y while using the scroll wheel. Not that there is no way to shift, scale, or rotate textures. While it may feel restrictive it greatly
|
||||
speeds up the process of mapping and the running of the game. Another useful command is rotate, which is done with R and the scroll
|
||||
wheel. Experiment with these operations to get a feel for them and then save your creation with the command <i>/savemap mmapname</i>
|
||||
where mapname is some name of your choosing. This will create a file in packages/base named mapname.ogz. Save your work often!
|
||||
Backups of old saves will be made for you with a .BAK extension. You can later open your map with the command <i>/map mapname</i>.
|
||||
</p>
|
||||
|
||||
<h2 id="entities">Entities</h2>
|
||||
|
||||
<p>
|
||||
Entities all have a blue particles sparkling to indicate their position. Some entities such as ammo boxes and armor will also show
|
||||
their standard in-game model, but these will only be rendered if the entites have existed since the map was loaded. Monsters will only
|
||||
render in single player mode. Make sure you're familiar with the different <a href="editref.html#entitytypes">types on entities</a>.
|
||||
To add an entity select it from the editing section of the built in menu or type <i>/newent entname arg1 arg2 arg3 arg4</i> such as
|
||||
<i>/newent light 32 120 120 120</i>. The location of the entity will be exactly where you are, except dropped straight down if it's
|
||||
not a light. This behavior can be changed through the entdrop variable, but the default is best in most cases. You can delete an
|
||||
entity with the delent command, which is bound to backspace.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For a DM: Place some "playerstart" entities, suggested quite a few of them, i.e. from 5 or so in a really small map up to
|
||||
15 in really big ones. Place some ammo... remember to not just place excessive amounts: ammo spawns VERY quickly (4 to 8 seconds
|
||||
depending on player load), and not having endless ammo forces the player to move around the map more and use different weapons, rather
|
||||
than just using the one she is most effective with all the time. Normal health items... suggested from 3 or 4 for a really small map
|
||||
to 8 or more in really big ones. The items "boost", "yellow armour", "greenarmour" and "quaddamage" all suggested 1 item, or maybe
|
||||
multiple green armours or boosts in bigger maps. Add some teleports sparingly, only if they really make sense for connectivity and gameplay.
|
||||
</p>
|
||||
|
||||
<h2 id="lighting">Lighting</h2>
|
||||
|
||||
<p>
|
||||
See the <a href="editref.html#lighting">lighting commands</a> for an indepth list of all lighting related commands.
|
||||
</p>
|
||||
|
||||
<h2 id="materials">Materials</h2>
|
||||
|
||||
<p>
|
||||
There are various materials available such as water, lava & clip etc. To create a material make a selection then in the console type
|
||||
<i>/water</i>. The area of your selection will have the material applied to it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Hint:</b> You do not have to type the full command you can just type the name of the material. For example <i>/water</i> rather then <i>/editmat water</i>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
See <a href="editref.html#editmat">available materials</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="cheat_sheet">Cheat Sheet</h2>
|
||||
|
||||
<ul>
|
||||
<li>Mouse Left Button: Select Faces</li>
|
||||
<li>Mouse Middle Button: Select Corners</li>
|
||||
<li>Mouse Right Button: Extend selection; Reorient section direction (requires initial selection)</li>
|
||||
<li>Mouse Wheel: Pull cubes into existence and push them out of existence</li>
|
||||
<li>Spacebar: Deselect</li>
|
||||
<li>F+Mouse Wheel: Push and pull all 4 corners at once (in the case of no corner selection)</li>
|
||||
<li>R+Mouse Wheel: Rotate relative to the white box</li>
|
||||
<li>Y+Mouse Wheel: Quick texture change</li>
|
||||
<li>G+Mouse Wheel: change grid size</li>
|
||||
<li>U: undo one step</li>
|
||||
<li>X: Mirror relative to the side of the white box</li>
|
||||
<li>F2: Texture menu</li>
|
||||
<li>Keypad Enter: Selection entities within selection</li>
|
||||
<li><i>/savemap mapname</i> to save your map</li>
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
2938
docs/editref.html
2938
docs/editref.html
File diff suppressed because it is too large
Load Diff
BIN
docs/favicon.ico
BIN
docs/favicon.ico
Binary file not shown.
|
Before Width: | Height: | Size: 4.2 KiB |
1151
docs/game.html
1151
docs/game.html
File diff suppressed because it is too large
Load Diff
1093
docs/history.html
1093
docs/history.html
File diff suppressed because it is too large
Load Diff
883
docs/models.html
883
docs/models.html
|
|
@ -1,883 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html
|
||||
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
|
||||
<head>
|
||||
<title>Cube 2: Sauerbraten - Model Reference</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css" />
|
||||
<link rel="shortcut icon" href="favicon.ico" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
||||
<h1>Cube 2: Sauerbraten - Model Reference</h1>
|
||||
|
||||
<div class="contents">
|
||||
<ul class="contents">
|
||||
<li>
|
||||
<a href="#md2_format"><b>MD2 Format</b></a>
|
||||
<ul class="contents2">
|
||||
<li>
|
||||
<a href="#md2anim"><tt>md2anim</tt></a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3_format"><b>MD3 Format</b></a>
|
||||
<ul class="contents2">
|
||||
<li>
|
||||
<a href="#without_configuration">Without Configuration</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#with_configuration">With Configuration</a>
|
||||
<ul class="contents3">
|
||||
<li>
|
||||
<a href="#md3load"><tt>md3load</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3pitch"><tt>md3pitch</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3skin"><tt>md3skin</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3bumpmap"><tt>md3bumpmap</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3spec"><tt>md3spec</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3alphatest"><tt>md3alphatest</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3alphablend"><tt>md3alphablend</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3shader"><tt>md3shader</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3ambient"><tt>md3ambient</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3envmap"><tt>md3envmap</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3glow"><tt>md3glow</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3glare"><tt>md3glow</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3fullbright"><tt>md3fullbright</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3anim"><tt>md3anim</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md3link"><tt>md3link</tt></a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#sample_configuration">Sample Configuration</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#obj_format"><b>OBJ Format</b></a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#md5_format"><b>MD5 Format</b></a>
|
||||
<ul class="contents2">
|
||||
<li>
|
||||
<a href="#md5load"><tt>md5load</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5pitch"><tt>md5pitch</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5skin"><tt>md5skin</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5bumpmap"><tt>md5bumpmap</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5spec"><tt>md5spec</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5alphatest"><tt>md5alphatest</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5alphablend"><tt>md5alphablend</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5shader"><tt>md5shader</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5ambient"><tt>md5ambient</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5envmap"><tt>md5envmap</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5glow"><tt>md5glow</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5glare"><tt>md5glare</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5fullbright"><tt>md5fullbright</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5anim"><tt>md5anim</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5animpart"><tt>md5animpart</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5tag"><tt>md5tag</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5link"><tt>md5link</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#md5adjust"><tt>md5adjust</tt></a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#smd_format"><b>SMD Format</b></a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#iqm_format"><b>IQM Format</b></a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#common_commands"><b>Common Commands</b></a>
|
||||
<ul class="contents2">
|
||||
<li>
|
||||
<a href="#mdlcollide"><tt>mdlcollide</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlellipsecollide"><tt>mdlellipsecollide</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlbb"><tt>mdlbb</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlcullface"><tt>mdlcullface</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlspec"><tt>mdlspec</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlalphatest"><tt>mdlalphatest</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlalphablend"><tt>mdlalphablend</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlglow"><tt>mdlglow</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlglare"><tt>mdlglare</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlshader"><tt>mdlshader</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlambient"><tt>mdlambient</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlscale"><tt>mdlscale</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdltrans"><tt>mdltrans</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlyaw"><tt>mdlyaw</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlpitch"><tt>mdlpitch</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlspin"><tt>mdlspin</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlenvmap"><tt>mdlenvmap</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlfullbright"><tt>mdlfullbright</tt></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#mdlshadow"><tt>mdlshadow</tt></a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<h2 id="md2_format">MD2 Format</h2>
|
||||
|
||||
<p>
|
||||
MD2 files must be located in a directory in <i>packages/models/</i>, you must provide a skin
|
||||
(either <i>skin.jpg</i> or <i>skin.png</i>) and the md2 itself (<i>tris.md2</i>).
|
||||
Optionally you may provide a <i>masks.jpg</i> that holds a specmap in the R channel, a glowmap
|
||||
in the G channel, and a chrome map in the B channel. The engine will apply it automatically.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If either of these files is not found, the engine will search the parent directory for them.
|
||||
For example, if for the <i>flags/red</i> model, the tris.md2 is not found in
|
||||
<i>packages/models/flags/red/</i>, then it will look for tris.md2 in <i>packages/models/flags/</i>.
|
||||
This allows the sharing of skins and geometry.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It is expected that md2 format files use Quake-compatible scale and animations, unless you configure the model otherwise.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You may also supply a config file (<i>md2.cfg</i>) in your model directory, which allows you to
|
||||
customize the model's animations. The following commands may be used in an <i>md2.cfg</i>:
|
||||
</p>
|
||||
|
||||
<pre id="md2anim">md2anim N F M [S [P]]</pre>
|
||||
<p>
|
||||
N is the name of the animation to define. Any of the following names may be used:
|
||||
</p>
|
||||
<ul>
|
||||
<li>dying</li>
|
||||
<li>dead</li>
|
||||
<li>pain</li>
|
||||
<li>idle</li>
|
||||
<li>forward</li>
|
||||
<li>backward</li>
|
||||
<li>left</li>
|
||||
<li>right</li>
|
||||
<li>hold 1 ... hold 7</li>
|
||||
<li>attack 1 ... attack 7</li>
|
||||
<li>jump</li>
|
||||
<li>sink</li>
|
||||
<li>swim</li>
|
||||
<li>edit</li>
|
||||
<li>lag</li>
|
||||
<li>taunt</li>
|
||||
<li>win</li>
|
||||
<li>lose</li>
|
||||
<li>gun shoot</li>
|
||||
<li>gun idle</li>
|
||||
<li>vwep shoot</li>
|
||||
<li>vwep idle</li>
|
||||
<li>mapmodel</li>
|
||||
<li>trigger</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
F is the frame number the animation starts at. M is the number of frames in the
|
||||
animation. S is the optional frames per second at which to run the anim. If none is specified,
|
||||
10 FPS is the default. P specifies an optional priority for the animation (defaults to P=0).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, defining a "pain" animation starting at frame 50 with 6 frames and running at 30 frames per
|
||||
second would look like: <i>md2anim "pain" 50 6 30</i>
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="md3_format">MD3 Format</h2>
|
||||
<p>
|
||||
MD3 file can be used in one of two ways.
|
||||
</p>
|
||||
|
||||
<h3 id="without_configuration">Without Configuration</h3>
|
||||
|
||||
<p>
|
||||
Go this way if your md3 has no animations (static) and takes only one texture, they must be
|
||||
located in a directory in <i>packages/models/</i>, and provide a skin (either <i>skin.jpg</i>
|
||||
or <i>skin.png</i>) and the md3 itself (<i>tris.md3</i>). Optionally you may provide a
|
||||
<i>masks.jpg</i> that holds a specmap in the R channel, a glowmap in the G channel, and a
|
||||
chrome map in the B channel. The engine will apply it automatically.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If either of these files is not found, the engine will search the parent directory for them.
|
||||
For example, if for the <i>flags/red model</i>, the <i>tris.md3</i> is not found in
|
||||
<i>packages/models/flags/red/</i>, then it will look for <i>tris.md3</i> in
|
||||
<i>packages/models/flags/</i>. This allows the sharing of skins and geometry.
|
||||
</p>
|
||||
|
||||
<h3 id="with_configuration">With Configuration</h3>
|
||||
|
||||
<p>
|
||||
MD3 files with animations multiple skins, or if you want to make use of other configuration
|
||||
possibilities, need to be set up this way. You must place a <i>md3.cfg</i> in a directory in
|
||||
<i>packages/models/</i>. This file specifies which models should be loaded, linked, etc. The
|
||||
following commands may be used in the <i>md3.cfg</i>:
|
||||
</p>
|
||||
|
||||
<pre id="md3load">md3load P</pre>
|
||||
<p>
|
||||
This command loads the first part of your model. As an example, this could be the <i>head.md3</i>
|
||||
of a playermodel. P is the path to the md3 file to load, its relative to the location of the
|
||||
<i>md3.cfg</i>.
|
||||
</p>
|
||||
|
||||
<pre id="md3pitch">md3pitch S O M N</pre>
|
||||
<p>
|
||||
This command controls how a model responds to the model's pitch. The pitch (in degrees) is scaled
|
||||
by S, offset by O, and then clamped to the range M..N, i.e. clamp(pitch*S + O, M, N). By default,
|
||||
all model parts have S=1, O=0, M=-360, and N=360, such that the model part will pitch one-to-one.
|
||||
</p>
|
||||
|
||||
<pre id="md3skin">md3skin H S M [E [F]]</pre>
|
||||
<p>
|
||||
This loads a texture and assigns it to a mesh of the last loaded model (md3load). H is the name
|
||||
of the mesh you want to assign the texture to. S is the path to the texture, its recursive
|
||||
to the location of the <i>md3.cfg</i>. The optional M sets a texture for spec (red channel)/glow
|
||||
(green channel) maps as above. If E is non-zero, then the blue channel of the masks is
|
||||
interpreted as a chrome map. E (maximum envmap intensity) and F (minimum envmap intensity, default: 0) are floating point
|
||||
values in the range of 0 to 1, and specify the range in which the envmapping intensity will vary based on a viewing angle
|
||||
(a Fresnel term that is maximal at glancing angles, minimal when viewed dead-on). The intensity,
|
||||
after scaled into this range, is then multiplied by the chrome map.
|
||||
</p>
|
||||
|
||||
<pre id="md3bumpmap">md3bumpmap H N [S]</pre>
|
||||
<p>
|
||||
This command enables bumpmapping for a given mesh in the last loaded model (md3load). H is the name
|
||||
of the mesh you want to assign bumpmapping textures to. S is the path to a diffuse skin texture which is (if specified)
|
||||
used instead of the skin supplied with the "md3skin" command only if the user's 3D card supports bumpmapping,
|
||||
otherwise the skin supplied with "md3skin" takes precedence and no bumpmapping is done. These
|
||||
two diffuse skins may be the same. However a diffuse skin intended for bumpmapping should generally have
|
||||
little to no directional shading baked into it, whereas flat diffuse skins (no bumpmapping) generally should,
|
||||
and this command allows you to provide a separate skin for the bumpmapping case. N is a normal map texture which is
|
||||
used to shade the supplied diffuse skin texture.
|
||||
</p>
|
||||
|
||||
<pre id="md3spec">md3spec MESH S</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. S is the specular intensity (not given or 0 gives the default of 100, good for metal/plastics and anything shiny, use lower values like 50 for wood etc, -1 means off entirely).</p>
|
||||
|
||||
<pre id="md3alphatest">md3alphatest MESH T</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Controls the cut-off threshold, T, at which alpha-channel skins will discard pixels where alpha is less than T.
|
||||
T is a floating point value in the range of 0 to 1 (Default: 0.9).
|
||||
</p>
|
||||
|
||||
<pre id="md3alphablend">md3alphablend MESH B</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Controls whether a model with an alpha-channel skin will alpha blend (Default: 1).
|
||||
</p>
|
||||
|
||||
<pre id="md3shader">md3shader MESH S</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. S is the name of the shader to use for rendering the model (Default: "stdmodel").
|
||||
</p>
|
||||
|
||||
<pre id="md3glow">md3glow MESH G</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. G is the glowmap scale (not given or 0 gives the default of 300, -1 means off entirely), such that
|
||||
the glow is G percent of the diffuse skin color.
|
||||
</p>
|
||||
|
||||
<pre id="md3glare">md3glare MESH S G</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. S and G are floating point values that scale the amount of glare generated by specular light and glare, respectively (Default: 1 1).
|
||||
</p>
|
||||
|
||||
<pre id="md3envmap">md3envmap MESH P</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Sets the environment map used for the model, where P is a pathname in the same syntax as the
|
||||
"loadsky" command. If this is not specified, the mesh will use the closest "envmap" entity,
|
||||
or skybox, if none is available (unless overridden by "mdlenvmap").
|
||||
</p>
|
||||
|
||||
<pre id="md3ambient">md3ambient MESH A</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. A is the percent of the ambient light that should be used for shading. Not given or 0 gives the
|
||||
default of 30%, -1 means no ambient.
|
||||
</p>
|
||||
|
||||
<pre id="md3fullbright">md3fullbright MESH N</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Uses a constant lighting level of N instead of the normal lighting. N is a floating-point value on a scale of 0 to 1.
|
||||
</p>
|
||||
|
||||
<pre id="md3anim">md3anim A F N [S [P]]</pre>
|
||||
<p>
|
||||
This assigns a new animation to the last loaded model (md3load). A is the name of the animation
|
||||
to define. Any of the following names may be used:
|
||||
</p>
|
||||
<ul>
|
||||
<li>dying</li>
|
||||
<li>dead</li>
|
||||
<li>pain</li>
|
||||
<li>idle</li>
|
||||
<li>forward</li>
|
||||
<li>backward</li>
|
||||
<li>left</li>
|
||||
<li>right</li>
|
||||
<li>hold 1 ... hold 7</li>
|
||||
<li>attack 1 ... attack 7</li>
|
||||
<li>jump</li>
|
||||
<li>sink</li>
|
||||
<li>swim</li>
|
||||
<li>edit</li>
|
||||
<li>lag</li>
|
||||
<li>taunt</li>
|
||||
<li>win</li>
|
||||
<li>lose</li>
|
||||
<li>gun shoot</li>
|
||||
<li>gun idle</li>
|
||||
<li>vwep shoot</li>
|
||||
<li>vwep idle</li>
|
||||
<li>mapmodel</li>
|
||||
<li>trigger</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
F is the frame number the animation starts at. N is the number of frames in the animation.
|
||||
S is frames per second at which to run the anim. If none is specified or S=0, 10 FPS is the default.
|
||||
P specifies an optional priority for the animation (defaults to P=0).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A character model will have up to 2 animations simultaneously playing - a primary animation
|
||||
and a secondary animation. If a character model defines the primary animation, it will be used,
|
||||
otherwise the secondary will be used if it is available. Primary animations are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>dying</li>
|
||||
<li>dead</li>
|
||||
<li>pain</li>
|
||||
<li>hold 1 ... hold 7</li>
|
||||
<li>attack 1 ... attack 7</li>
|
||||
<li>edit</li>
|
||||
<li>lag</li>
|
||||
<li>taunt</li>
|
||||
<li>win</li>
|
||||
<li>lose</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Secondary animations are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>idle</li>
|
||||
<li>forward</li>
|
||||
<li>backward</li>
|
||||
<li>left</li>
|
||||
<li>right</li>
|
||||
<li>jump</li>
|
||||
<li>sink</li>
|
||||
<li>swim</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
This allows, for example, a torso part to "shoot" (a primary animation) while a leg part
|
||||
simultaneously runs "forward" (a secondary animation). In the event that a secondary animation
|
||||
other than "idle" is playing and there is no primary animation, then the secondary animation
|
||||
will behave as if it were primary, and the secondary animation will effectively be "idle".
|
||||
This allows parts that would not normally participate in a certain animation to do so in the
|
||||
"idle" case, or otherwise simply be "idle" if this is not desired. However, if you want to override
|
||||
which animation is primary for a specific part, you can set an explicit priority for that animation,
|
||||
and the animation with the highest priority is chosen, regardless of which is primary and
|
||||
which is secondary. So, for example, you could give an animation a -1 priority so that all animations
|
||||
with the default 0 priority are chosen first, or you could give an animation a 1 or greater priority
|
||||
so that it is always chosen before animations with the default 0 priority.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, to define a "punch" animation starting at frame 131 with 6 frames and running at
|
||||
15 frames per second: <i>md3anim "punch" 131 6 15</i>
|
||||
</p>
|
||||
|
||||
<pre id="md3link">md3link P C T [X Y Z]</pre>
|
||||
<p>
|
||||
This links two models together. Every model you load with md3load has an ID. The first model
|
||||
you load has the ID 0, the second has the ID 1, and so on, those ID's are now used to identify
|
||||
the models and link them together. P the ID of the parent model. C to ID of the
|
||||
child model. T name of the tag that specifies at which vertex the models should be linked.
|
||||
X, Y, and Z are optional translation for this link.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Hint: <i>Make sure you understand the difference between the parent and child model.
|
||||
Rendering starts at model 0 (first loaded model) and then continues with model 0's children,
|
||||
etc. Imagine a tree, model 0 is the root if it.</i>
|
||||
</p>
|
||||
|
||||
<h3 id="sample_configuration">Sample Configuration</h3>
|
||||
<pre>
|
||||
md3load lower.md3 // model no. 0
|
||||
md3skin l_lower ./default_l.png
|
||||
|
||||
md3anim dying 0 30 20
|
||||
md3anim dead 30 1 25
|
||||
md3anim "forward|backward|left|right|swim" 114 10 18
|
||||
md3anim idle 164 30 30
|
||||
md3anim "jump|lag|edit" 147 8 15
|
||||
|
||||
md3load upper.md3 // model no. 1
|
||||
md3skin u_torso ./default.png
|
||||
|
||||
md3anim dying 0 30 20
|
||||
md3anim dead 30 1 25
|
||||
md3anim "lag|edit" 91 40 18
|
||||
md3anim "attack *" 131 6 15
|
||||
md3anim idle 152 1 15
|
||||
md3anim pain 152 1 15
|
||||
|
||||
|
||||
md3load head.md3 // model no. 2
|
||||
md3skin h_head ./default_h.png
|
||||
|
||||
|
||||
md3link 0 1 tag_torso
|
||||
md3link 1 2 tag_head
|
||||
|
||||
mdlspec 50
|
||||
mdlscale 20 // 20 percent of the original size
|
||||
mdltrans 0 0 -1.5 // lower the model a bit
|
||||
</pre>
|
||||
|
||||
<h2 id="obj_format">OBJ Format</h2>
|
||||
<p>
|
||||
The Wavefront OBJ format is configured almost identically to how MD3s are used. The only differences are that OBJ specific commands are prefixed with "obj" instead of "md3" (i.e. "objskin" instead of "md3skin") which are specified in "obj.cfg" instead of "md3.cfg", it looks for "tris.obj" instead of "tris.md3" by default, and there is no support for animation ("objanim") or linking ("objlink"). Group names are used to identify meshes within the model.
|
||||
</p>
|
||||
|
||||
<h2 id="md5_format">MD5 Format</h2>
|
||||
<p>
|
||||
MD5 models require a proper configuration to function; make sure your exporter properly exports mesh names in the MD5 file so that these can be referenced in the configuration file (the Blender exporter does not export these, but a fixed Blender MD5 exporter can be gotten from the Cube wiki).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Make sure no more than 4 blend weights are used per vertex, any extra blend weights will be dropped silently. The skeleton should use no more than 256 bones, and less than 70 or so bones should be used if you wish the model to be skeletally animated on the GPU. To optimize animation of the model on both CPU and GPU, keep the number of blend weights per vertex to a minimum. Also, similar combinations of blend weights are cached while animating, especially on the CPU, such that if two or more vertices use the same blend weights, blending calculations only have to be done once for all the vertices - so try and minimize the number of distinct combinations of blend weights if possible.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When animating skeletal models, you should model the animations as a single piece for the entire body (unlike for MD3 which requires splitting the mesh). In the configuration file, you can choose a bone at which to split the model into an upper and lower part (via "md5animpart"), which allows, for example, the upper body movement of one animation to be combined with the lower body movement of another animation automatically. The bone at which you split the animation up should ideally be a root bone, of which the upper body and lower body are separate sub-trees. Rigging the model in this way also allows for pitch animation (which also requires selecting a bone to pitch at) to take place such as bending at the waist, which similarly requires the upper body to be a sub-tree of the bone at which the pitch animation will occur.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The included MD5 support allows for two methods of attaching models to another: via tags (by assigning a tag name to a bone with "md5tag"), or by animating multiple models against a common, named skeleton that will be shared among all of them (useful for modeling clothing attachments and similar items). To use a shared skeleton, you simply export all the models with the same skeleton. Animations only need to be specified for the base model. A name for the skeleton is specified via the "md5load" command, for both the model exporting the skeleton and the models using it. When one of the models is attached to the one supplying the skeleton internally, the tag setup is instead ignored and the skeleton/animations of the base model are used to animate the attachment as if it were a sub-mesh of the base model itself.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You must place a <i>md5.cfg</i> in a directory in <i>packages/models/</i>.
|
||||
The following commands may be used in the <i>md5.cfg</i>:
|
||||
</p>
|
||||
|
||||
<pre id="md5load">md5load P [S]</pre>
|
||||
<p>
|
||||
This command loads the first part of your model. As an example, this could be the <i>head.md5mesh</i>
|
||||
of a playermodel. P is the path to the md5mesh file to load, its relative to the location of the
|
||||
<i>md5.cfg</i>. S is an optional name that can be assigned to the skeleton specified in the md5mesh
|
||||
for skeleton sharing, but need not be specified if you do not wish to share the skeleton. This skeleton
|
||||
name must be specified for both the model supplying a skeleton and an attached model intending to use the skeleton.
|
||||
</p>
|
||||
|
||||
<pre id="md5pitch">md5pitch B S O M N</pre>
|
||||
<p>
|
||||
This command controls how a model responds to the model's pitch. B is the name of the bone which
|
||||
the pitch animation is applied to, as well as all bones in the sub-tree below it. The pitch (in degrees)
|
||||
is scaled by S, offset by O, and then clamped to the range M..N, i.e. clamp(pitch*S + O, M, N). By default,
|
||||
all model parts have S=1, O=0, M=-360, and N=360, such that the model part will pitch one-to-one.
|
||||
</p>
|
||||
|
||||
<pre id="md5skin">md5skin H S M [E [F]]</pre>
|
||||
<p>
|
||||
This loads a texture and assigns it to a mesh of the last loaded model (md5load). H is the name
|
||||
of the mesh you want to assign the texture to. S is the path to the texture, its recursive
|
||||
to the location of the <i>md5.cfg</i>. The optional M sets a texture for spec (red channel)/glow
|
||||
(green channel) maps as above. If E is non-zero, then the blue channel of the masks is
|
||||
interpreted as a chrome map. E (maximum envmap intensity) and F (minimum envmap intensity, default: 0) are floating point
|
||||
values in the range of 0 to 1, and specify the range in which the envmapping intensity will vary based on a viewing angle
|
||||
(a Fresnel term that is maximal at glancing angles, minimal when viewed dead-on). The intensity,
|
||||
after scaled into this range, is then multiplied by the chrome map.
|
||||
</p>
|
||||
|
||||
<pre id="md5bumpmap">md5bumpmap H N [S]</pre>
|
||||
<p>
|
||||
This command enables bumpmapping for a given mesh in the last loaded model (md5load). H is the name
|
||||
of the mesh you want to assign bumpmapping textures to. S is the path to a diffuse skin texture which is
|
||||
used (if specified) instead of the skin supplied with the "md5skin" command only if the user's 3D card supports bumpmapping,
|
||||
otherwise the skin supplied with "md5skin" takes precedence and no bumpmapping is done. These
|
||||
two diffuse skins may be the same. However a diffuse skin intended for bumpmapping should generally have
|
||||
little to no directional shading baked into it, whereas flat diffuse skins (no bumpmapping) generally should,
|
||||
and this command allows you to provide a separate skin for the bumpmapping case. N is a normal map texture which is
|
||||
used to shade the supplied diffuse skin texture.
|
||||
</p>
|
||||
|
||||
<pre id="md5spec">md5spec MESH S</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. S is the specular intensity (not given or 0 gives the default of 100, good for metal/plastics and anything shiny, use lower values like 50 for wood etc, -1 means off entirely).</p>
|
||||
|
||||
<pre id="md5alphatest">md5alphatest MESH T</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Controls the cut-off threshold, T, at which alpha-channel skins will discard pixels where alpha is less than T.
|
||||
T is a floating point value in the range of 0 to 1 (Default: 0.9).
|
||||
</p>
|
||||
|
||||
<pre id="md5alphablend">md5alphablend MESH B</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Controls whether a model with an alpha-channel skin will alpha blend (Default: 1).
|
||||
</p>
|
||||
|
||||
<pre id="md5shader">md5shader MESH S</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. S is the name of the shader to use for rendering the model (Default: "stdmodel").
|
||||
</p>
|
||||
|
||||
<pre id="md5glow">md5glow MESH G</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. G is the glowmap scale (not given or 0 gives the default of 300, -1 means off entirely), such that
|
||||
the glow is G percent of the diffuse skin color.
|
||||
</p>
|
||||
|
||||
<pre id="md5glare">md5glare MESH S G</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. S and G are floating point values that scale the amount of glare generated by specular light and glare, respectively (Default: 1 1).
|
||||
</p>
|
||||
|
||||
<pre id="md5envmap">md5envmap MESH P</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Sets the environment map used for the model, where P is a pathname in the same syntax as the
|
||||
"loadsky" command. If this is not specified, the mesh will use the closest "envmap" entity,
|
||||
or skybox, if none is available (unless overridden by "mdlenvmap").
|
||||
</p>
|
||||
|
||||
<pre id="md5ambient">md5ambient MESH A</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. A is the percent of the ambient light that should be used for shading. Not given or 0 gives the
|
||||
default of 30%, -1 means no ambient.
|
||||
</p>
|
||||
|
||||
<pre id="md5fullbright">md5fullbright MESH N</pre>
|
||||
<p>
|
||||
MESH specifies the name of the mesh this setting applies to. Uses a constant lighting level of N instead of the normal lighting. N is a floating-point value on a scale of 0 to 1.
|
||||
</p>
|
||||
|
||||
<pre id="md5anim">md5anim A F [S] [P] [START] [END]</pre>
|
||||
<p>
|
||||
This assigns a new animation to the current animation part of the last loaded model (md5load). A is the name of the animation
|
||||
to define. Any of the following names may be used:
|
||||
</p>
|
||||
<ul>
|
||||
<li>dying</li>
|
||||
<li>dead</li>
|
||||
<li>pain</li>
|
||||
<li>idle</li>
|
||||
<li>forward</li>
|
||||
<li>backward</li>
|
||||
<li>left</li>
|
||||
<li>right</li>
|
||||
<li>hold 1 ... hold 7</li>
|
||||
<li>attack 1 ... attack 7</li>
|
||||
<li>jump</li>
|
||||
<li>sink</li>
|
||||
<li>swim</li>
|
||||
<li>edit</li>
|
||||
<li>lag</li>
|
||||
<li>taunt</li>
|
||||
<li>win</li>
|
||||
<li>lose</li>
|
||||
<li>gun shoot</li>
|
||||
<li>gun idle</li>
|
||||
<li>vwep shoot</li>
|
||||
<li>vwep idle</li>
|
||||
<li>mapmodel</li>
|
||||
<li>trigger</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
F is the file name of an md5 animation file. S is frames per second at which to run the anim. If none is specified or S=0, 10 FPS is the default. P specifies an optional priority for the animation (defaults to P=0). START is an optional start frame offset within the animation, where a positive values is an offset from the first frame, and a negative value is an offset from end. END is an optional animation length in frames, where positive values specify the length, or negative values merely subtract off from the length.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A character model will have up to 2 animations simultaneously playing - a primary animation
|
||||
and a secondary animation. If a character model defines the primary animation, it will be used,
|
||||
otherwise the secondary will be used if it is available. Primary animations are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>dying</li>
|
||||
<li>dead</li>
|
||||
<li>pain</li>
|
||||
<li>hold 1 ... hold 7</li>
|
||||
<li>attack 1 ... attack 7</li>
|
||||
<li>edit</li>
|
||||
<li>lag</li>
|
||||
<li>taunt</li>
|
||||
<li>win</li>
|
||||
<li>lose</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Secondary animations are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>idle</li>
|
||||
<li>forward</li>
|
||||
<li>backward</li>
|
||||
<li>left</li>
|
||||
<li>right</li>
|
||||
<li>jump</li>
|
||||
<li>sink</li>
|
||||
<li>swim</li>
|
||||
</ul>
|
||||
|
||||
<pre id="md5animpart">md5animpart B</pre>
|
||||
<p>
|
||||
Starts a new animation part that will include bone B and all its sub-bones. This effectively splits animations up at the bone B, such that each animation part animates as if it were a separate model. Note that a new animation part has no animations (does not inherit any from the previous animation part). After an "md5load", an implicit animation part is started that involves all bones not used by other animation parts. Each model currently may only have 2 animation parts, including the implicit default part, so this command may only be used once and only once per md5mesh loaded. However, you do not need to specify any animation parts explicitly and can just use the default part for all animations, if you do not wish the animations to be split up/blended together.
|
||||
</p>
|
||||
|
||||
<pre id="md5tag">md5tag B T [X Y Z] [RX RY RZ]</pre>
|
||||
<p>
|
||||
Assigns the tag name T to the bone B, for either use with "md5link" or attachment of other models via tags. X, Y, and Z are an optional translation, whereas RX, RY, and RZ are optional rotations in degrees.
|
||||
</p>
|
||||
|
||||
<pre id="md5link">md5link P C T [X Y Z]</pre>
|
||||
<p>
|
||||
This links two models together. Every model you load with md5load has an ID. The first model
|
||||
you load has the ID 0, the second has the ID 1, and so on, those ID's are now used to identify
|
||||
the models and link them together. P the ID of the parent model. C to ID of the
|
||||
child model. T name of the tag that specifies at which vertex the models should be linked.
|
||||
X, Y, and Z are an optional translation for this link.
|
||||
</p>
|
||||
|
||||
<pre id="md5adjust">md5adjust BONE YAW [PITCH] [ROLL] [X Y Z]</pre>
|
||||
<p>
|
||||
Adjusts bone BONE with the specified rotations, in degrees, on any animations loaded after this command is specified. X, Y, and Z are an optional translation.
|
||||
</p>
|
||||
|
||||
<h2 id="smd_format">SMD Format</h2>
|
||||
<p>
|
||||
The Half-Life SMD format is configured almost identically to how MD5s are used. The only differences are that SMD specific commands are prefixed with "smd" instead of "md5" (i.e. "smdskin" instead of "md5skin") which are specified in "smd.cfg" instead of "md5.cfg".
|
||||
</p>
|
||||
|
||||
<h2 id="iqm_format">IQM Format</h2>
|
||||
<p>
|
||||
The Inter-Quake Model (IQM) format is configured almost identically to how MD5s are used. The only differences are that IQM specific commands are prefixed with "iqm" instead of "md5" (i.e. "iqmskin" instead of "md5skin") which are specified in "iqm.cfg" instead of "md5.cfg".
|
||||
</p>
|
||||
|
||||
<h2 id="common_commands">Common Commands</h2>
|
||||
<pre id="mdlcollide">mdlcollide N</pre>
|
||||
<p>
|
||||
If N is 0, collisions with the model are disabled (Default: 1).
|
||||
</p>
|
||||
|
||||
<pre id="mdlellipsecollide">mdlellipsecollide N</pre>
|
||||
<p>
|
||||
If N is 1, the model uses an elliptical collision volume instead of a box (Default: 0). This setting is good for barrels, trees, etc.
|
||||
</p>
|
||||
|
||||
<pre id="mdlbb">mdlbb R H [E]</pre>
|
||||
<p>
|
||||
Sets the model's bounding box to radius R and height H. If this is not set, or R and H are 0,
|
||||
a bounding box is automatically generated from the model's geometry. E is fraction of the
|
||||
model's height to be used as the eyeheight (Default: 0.9).
|
||||
</p>
|
||||
|
||||
<pre id="mdlcullface">mdlcullface N</pre>
|
||||
<p>
|
||||
If N is 0, backface culling is disabled for this model. Otherwise, backface culling is enabled
|
||||
(Default: 1).
|
||||
</p>
|
||||
|
||||
<pre id="mdlspec">mdlspec S</pre>
|
||||
<p>
|
||||
S is the specular intensity (not given or 0 gives the default of 100, good for metal/plastics
|
||||
and anything shiny, use lower values like 50 for wood etc, -1 means off entirely).
|
||||
</p>
|
||||
|
||||
<pre id="mdlalphatest">mdlalphatest T</pre>
|
||||
<p>
|
||||
Controls the cut-off threshold, T, at which alpha-channel skins will discard pixels where alpha is less than T.
|
||||
T is a floating point value in the range of 0 to 1 (Default: 0.9).
|
||||
</p>
|
||||
|
||||
<pre id="mdlalphablend">mdlalphablend B</pre>
|
||||
<p>
|
||||
Controls whether a model with an alpha-channel skin will alpha blend (Default: 1).
|
||||
</p>
|
||||
|
||||
<pre id="mdlglow">mdlglow G</pre>
|
||||
<p>
|
||||
G is the glowmap scale (not given or 0 gives the default of 300, -1 means off entirely), such that
|
||||
the glow is G percent of the diffuse skin color.
|
||||
</p>
|
||||
|
||||
<pre id="mdlglare">mdlglare S G</pre>
|
||||
<p>
|
||||
S and G are floating point values that scale the amount of glare generated by specular light and glare, respectively (Default: 1 1).
|
||||
</p>
|
||||
|
||||
<pre id="mdlshader">mdlshader S</pre>
|
||||
<p>
|
||||
S is the name of the shader to use for rendering the model (Default: "stdmodel").
|
||||
</p>
|
||||
|
||||
<pre id="mdlambient">mdlambient A</pre>
|
||||
<p>
|
||||
A is the percent of the ambient light that should be used for shading. Not given or 0 gives the
|
||||
default of 30%, -1 means no ambient.
|
||||
</p>
|
||||
|
||||
<pre id="mdlscale">mdlscale S</pre>
|
||||
<p>
|
||||
Scale the model's size to be S percent of its default size.
|
||||
</p>
|
||||
|
||||
<pre id="mdltrans">mdltrans X Y Z</pre>
|
||||
<p>
|
||||
Translate the model's center by (X, Y, Z), where X/Y/Z are in model units (may use floating
|
||||
point).
|
||||
</p>
|
||||
|
||||
<pre id="mdlyaw">mdlyaw Y</pre>
|
||||
<p>
|
||||
Offsets the model's yaw by Y degrees.
|
||||
point).
|
||||
</p>
|
||||
|
||||
<pre id="mdlpitch">mdlpitch P</pre>
|
||||
<p>
|
||||
Offsets the model's pitch by P degrees.
|
||||
</p>
|
||||
|
||||
<pre id="mdlspin">mdlspin Y</pre>
|
||||
<p>
|
||||
Simple spin animation that yaws the model by Y degrees per second.
|
||||
</p>
|
||||
|
||||
<pre id="mdlenvmap">mdlenvmap E F [P]</pre>
|
||||
<p>
|
||||
Sets the environment map used for the model, where P is a pathname in the same syntax as the
|
||||
"loadsky" command. If this is not specified, the model will use the closest "envmap" entity,
|
||||
or skybox, if none is available. If E is non-zero, then the blue channel of the masks is
|
||||
interpreted as a chrome map. E (maximum envmap intensity) and F (minimum envmap intensity, default: 0) are floating point
|
||||
values in the range of 0 to 1, and specify the range in which the envmapping intensity will vary based on a viewing angle
|
||||
(a Fresnel term that is maximal at glancing angles, minimal when viewed dead-on). The intensity,
|
||||
after scaled into this range, is then multiplied by the chrome map.
|
||||
</p>
|
||||
|
||||
<pre id="mdlfullbright">mdlfullbright N</pre>
|
||||
<p>
|
||||
Uses a constant lighting level of N instead of the normal lighting. N is a floating-point value on a scale of 0 to 1.
|
||||
</p>
|
||||
|
||||
<pre id="mdlshadow">mdlshadow B</pre>
|
||||
<p>
|
||||
Controls whether a mapmodel will cast shadows (Default: 1).
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
423
docs/rpg.html
423
docs/rpg.html
|
|
@ -1,423 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html
|
||||
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
|
||||
<head>
|
||||
<title>Sauerbraten RPG</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
||||
<h1>Sauerbraten RPG</h1>
|
||||
|
||||
<h2 id="running">Running</h2>
|
||||
<p>
|
||||
To launch the game, run the "rpg.bat" file which is included in the main Sauerbraten install directory.
|
||||
</p>
|
||||
|
||||
<h2 id="building">Building</h2>
|
||||
|
||||
<p>
|
||||
A Visual Studio solution and a Code::Blocks project file are included for building in the "src\rpggame\" directory within the Sauerbraten install directory.
|
||||
</p>
|
||||
|
||||
<h2 id="gameplay_scripting">Gameplay Scripting</h2>
|
||||
|
||||
<p>
|
||||
The RPG is set up in a very open way such that all gameplay objects and behaviour can be modified in a script file,
|
||||
currently in data/game_rpg.cfg (this will change later to be on a per-map basis). The idea is that every map comes with its own "mod",
|
||||
and that gameplay can be influenced by level designer, allowing gameplay types spanning
|
||||
from a stat/story influenced FPS game, an action RPG, all the way to more complex
|
||||
quest/story/stat based RPGs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This file simply lists all gameplay objects, which can then be placed in the level editor. For example, by writing:
|
||||
</p>
|
||||
|
||||
<pre id="spawn_apple">spawn_apple = [ r_worth 20 ]</pre>
|
||||
|
||||
<p>
|
||||
you define a script that gets executed when an apple is spawned. You place this apple either directly in the world or as part of another objects inventory.
|
||||
To place it in the world, you create an entity of type "spawn" with a name attached. This is best done by typing (in the console):
|
||||
</p>
|
||||
|
||||
<pre id="newrpgspawn">newrpgspawn apple</pre>
|
||||
|
||||
<p>
|
||||
which will show you your new entity in the editor. Running the map then will create
|
||||
a new apple object at that location, with all stats set to your liking (in this
|
||||
case just its worth).</p>
|
||||
<p>
|
||||
What is important to realize is that most r_ commands work with what is called the RPG stack. This makes it possible to apply
|
||||
properties and actions to things without having to specify all the time which object you are talking about. For example, when the
|
||||
spawn_apple script gets executed, the apple object will be on the top of the RPG stack, so any commands such as r_worth that apply to an
|
||||
object, will automatically apply to it. It is a stack, because during the initialization of one object you may spawn another, which means
|
||||
all r_ commands will apply to the new object, until it is done, when the RPG stack returns to the previous object.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Following is a list of all commands... unless otherwise noted, they apply to the current object (top of the RPG stack).
|
||||
</p>
|
||||
|
||||
<h2 id="rpg_object_commands">RPG object commands</h2>
|
||||
|
||||
|
||||
<pre id="r_pop">r_pop</pre>
|
||||
<p>
|
||||
Removes the top object from the RPG stack
|
||||
</p>
|
||||
|
||||
<pre id="r_spawn">r_spawn N</pre>
|
||||
<p>
|
||||
creates a new object, places it on the top of the RPG stack, then executes spawn_N to initialize it.
|
||||
</p>
|
||||
|
||||
<pre id="r_contain">r_contain T</pre>
|
||||
<p>
|
||||
Takes the object on the top of the stack, and makes it part of the inventory of the object on the stack below it.
|
||||
T is the type of inventory object, see the convenient scripts r_inventory, r_loot, r_fortrade instead.
|
||||
</p>
|
||||
|
||||
<pre id="r_model">r_model M</pre>
|
||||
<p>
|
||||
Specify model M to represent this object visually when placed in the world
|
||||
</p>
|
||||
|
||||
<pre id="r_action">r_action N A</pre>
|
||||
<pre id="Pre3">r_quest N A</pre>
|
||||
<p>
|
||||
defines a custom action the player can take on this object. N is the tag word that describes the action, visible in
|
||||
the objects menu in the game world, and A is the script that gets executed when the player selects it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When A gets executed, the top of the stack will be object on which the action is
|
||||
defined, below that target of the action, and below that the user of the action.
|
||||
For example, the player (user) casts a fireball (object) onto a monster (target).
|
||||
Or, the player (user/target) interacts with an npc (object).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A special tag is "use", this is the default action for items to be executed when
|
||||
the user clicks on them in the inventory, or, it is the action that gets executed
|
||||
when the player casts the currently selected spell (also see usetype below).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
r_quest is the same as r_action, except that it also marks the start of a quest, with the action being the resolution of the quest.
|
||||
The quest description is whatever the last r_say command was. Any r_take inside the action with a positive outcome concludes the quest. Quests can be seen
|
||||
in the quest log.
|
||||
</p>
|
||||
|
||||
<pre id="r_say">r_say T</pre>
|
||||
<p>
|
||||
Make text T the last thing this object said to the player
|
||||
</p>
|
||||
|
||||
<pre id="r_take">r_take N A NA</pre>
|
||||
<p>
|
||||
Attempt to take object with name N from the player inventory, and place it in the objects inventory. If the item was succesfully grabbed (it was present),
|
||||
action A is executed. If the item was not available, NA is executed. r_take is the preferred way to structure resolution of quests, i.e. everything the player ever
|
||||
needs to do should go via token items.
|
||||
</p>
|
||||
|
||||
<pre id="r_give">r_give N</pre>
|
||||
<p>
|
||||
give the player an item with name N
|
||||
</p>
|
||||
|
||||
<pre id="Pre1">r_applydamage D</pre>
|
||||
<p>
|
||||
does D damage to the object on top of the stack. object one below the top of the stack must be the one doing the damage.
|
||||
</p>
|
||||
|
||||
<pre id="Pre2">r_use</pre>
|
||||
<p>
|
||||
select or use the object for the player (see usetype below).
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="H2_1">RPG stats & attributes</h2>
|
||||
<p>
|
||||
The following is a list of all stats tracked by each object. A stat is defined as a property of an object that determines its effectiveness when performing a certain action,
|
||||
i.e. the "melee" stat affects your melee combat effectiveness. Stats are things that you can build up thruout the game, hence "health" is not a stat, but it is dependent on a stat, maxhp.
|
||||
</p>
|
||||
<table class="n" border="0" cellpadding="6" cellspacing="0">
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
melee</td>
|
||||
<td style="width: 802px">
|
||||
amount of damage when using a melee weapon (fists, swords, axes...)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
ranged</td>
|
||||
<td style="width: 802px">
|
||||
amount of damage when using a ranged weapon (crossbow, shotgun, ...)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
magic</td>
|
||||
<td style="width: 802px">
|
||||
amount of damage when using an attack spell (fireball...), level of utility when
|
||||
using healing/creation spells</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 44px;">
|
||||
regen</td>
|
||||
<td style="width: 802px; height: 44px;">
|
||||
amount of hp regenerated per second. regen is the only defense stat, it replaces
|
||||
the traditional armour or resistence stats. regen is more flexible in the sense that
|
||||
it is time based, so your effectiveness depends on being able to give or take sustained
|
||||
damage, and deals better with the effects of running away mid-fight etc.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
focus</td>
|
||||
<td style="width: 802px">
|
||||
amount of mana regenerated per second</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
attackspeed</td>
|
||||
<td style="width: 802px">
|
||||
reduces time delay between two attacks for any attack (melee/ranged/magic)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 17px;">
|
||||
movespeed</td>
|
||||
<td style="width: 802px; height: 17px;">
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
jumpheight</td>
|
||||
<td style="width: 802px">
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
maxhp</td>
|
||||
<td style="width: 802px">
|
||||
maximum health you will regenerate to</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 17px;">
|
||||
maxmana</td>
|
||||
<td style="width: 802px; height: 17px;">
|
||||
maximum mana you can store</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
tradeskill</td>
|
||||
<td style="width: 802px">
|
||||
will give your better deals when trading</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
feared</td>
|
||||
<td style="width: 802px; font-family: verdana,'trebuchet ms','zurich bt',tahoma,arial,helvetica,sans-serif;">
|
||||
the higher this stat, the more likely people are likely to comply with your wishes</td>
|
||||
</tr>
|
||||
<tr style="font-family: verdana,'trebuchet ms','zurich bt',tahoma,arial,helvetica,sans-serif">
|
||||
<td style="width: 100px">
|
||||
stealth</td>
|
||||
<td style="width: 802px">
|
||||
reduces npc fov & distance when stealing stuff</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
hostility</td>
|
||||
<td style="width: 802px">
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
stata, statb,
|
||||
statc</td>
|
||||
<td style="width: 802px">
|
||||
generic stats, i.e. their meaning is map-specific. they can be set and
|
||||
accumulated like any other stat, then scripts can use the results in any way they
|
||||
wish.</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
a stat can be set on any rpg object using the r_X command, where X is any of the
|
||||
above stat names, e.g. <i>r_melee 50</i>
|
||||
gives the current object 50 melee points.
|
||||
a script can read the current points using r_get_X, i.e. <i>echo "your melee points are: " (r_get_melee)</i>
|
||||
outputs the current objects melee points.
|
||||
</p>
|
||||
<p>
|
||||
A special case are objects that have no stats set directly (typically the player,
|
||||
and sometimes NPCs): their stats are computed as cumulative from the stats of all
|
||||
their inventory items. So if the player carries a gem that has melee 50, and gloves
|
||||
that have melee 20, his own melee points are 70.
|
||||
</p>
|
||||
<p>
|
||||
It's important to realize that stat points do not directly translate to damage and
|
||||
such. Points are an indication of efficiency of a particular stat over the base
|
||||
100%, along a logarithmic curve. So 0 melee points translates into 100% melee efficiency,
|
||||
and what 70 melee points translates into... well, something above 100%, depending
|
||||
on the log curve. Every map can define their own log curve for each stat, depending
|
||||
on how fast you want points to result in increased melee damage. This is a game
|
||||
balancing thing, in the sense that if the game world makes obtain items with melee
|
||||
points too easy and the log curve is too gentle, then players will be overpowered.
|
||||
The formula for melee is (other stats work similarly):
|
||||
</p>
|
||||
<p>
|
||||
<i>meleedamage = weapondamage * ( log ( points / pointsscale + 1 ) * percentscale + 100 ) / 100</i>
|
||||
</p>
|
||||
<p>
|
||||
(log = natural logarithm). so with a pointscale of 10, and a percentscale of 25,
|
||||
our 70 points amount to a 152% melee efficiency, which, when combined with a weapon
|
||||
that does 10 damage (at 100%), now does 15 melee damage. For movespeed you'd have
|
||||
a similar formula, where instead of weapondamage you'd have the default running
|
||||
speed.</p>
|
||||
<p>
|
||||
You can get the efficiency of any stat using r_eff_X, e.g. r_eff_melee.</p>
|
||||
<p>
|
||||
That may seem like a really convoluted way of doing things, but the log scale is
|
||||
the only way to give a relatively constant challenge level in the game. Without
|
||||
it, the game would start hard and become too easy real soon. The UI will show both
|
||||
points and efficiency for stats so you can easy see the effect without understanding
|
||||
the math.
|
||||
</p>
|
||||
<p>
|
||||
You can define the log scale by doing: <i>r_def_X pointscale percentscale</i>, but this should only
|
||||
really ever be done by the game designer, or experienced rpg level designers on their own levels, as tweaking
|
||||
these values requires deep insight into how players will collect points thruout
|
||||
a game.
|
||||
</p>
|
||||
<p>
|
||||
It is worth repeating what should be obvious from the above: the player and npcs
|
||||
don't have "levels" as in other RPGs. Increased ability is purely denoted by means
|
||||
of points and efficiency above whatever is the 100% value of the related ability.
|
||||
The end result is similar to traditional RPGs, but not quite. The above system is
|
||||
more flexible in the sense that you can have completely independent "levels" for
|
||||
all your abilities. But best of all, since your points are determined by what you
|
||||
have in your inventory, any way you can get items can increase your ability, which
|
||||
includes killing, stealing, finding, trading etc. You can change how you assign
|
||||
your priorities mid-game, by trading melee items for magic items, for example. You
|
||||
won't hit a "item plateau" as in so many RPG games 20% into the game because most
|
||||
items you get are useless, here you can put everything to <em>some</em> use, even
|
||||
if sometimes minimal.
|
||||
</p>
|
||||
<p>
|
||||
The following are the attributes of any rpg object. Attrs are simpler in the sense
|
||||
that they are just variables kept track of per object, and can be set/changed by
|
||||
either the rpg system or the script code. They are all default 0 for a newly
|
||||
initialized object.
|
||||
</p>
|
||||
<table border="0" cellpadding="6" cellspacing="0">
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
health</td>
|
||||
<td style="width: 800px">
|
||||
set to maxhp when an AI object spawns in the world, and regens using regen</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 16px">
|
||||
mana</td>
|
||||
<td style="width: 800px; height: 16px">
|
||||
set to maxmana upon spawn, and regens using focus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
gold</td>
|
||||
<td style="width: 800px">
|
||||
how much money is owned by the object (mostly for npcs/player only)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 17px;">
|
||||
worth</td>
|
||||
<td style="width: 800px; height: 17px;">
|
||||
base value when this object is sold by an npc (not necessarily when sold TO an npc)
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 17px">
|
||||
ai</td>
|
||||
<td style="width: 800px; height: 17px">
|
||||
0: no AI (a lifeless object, default), 1: a friendly AI (npc), 2: hostile AI (animals/monsters) </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 17px">
|
||||
useamount</td>
|
||||
<td style="width: 800px; height: 17px">
|
||||
amount of uses this object has. items such as melee weapons have a certain amount
|
||||
of uses before they break, and potion bottles may have a certain content.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px; height: 30px;">
|
||||
usetype</td>
|
||||
<td style="width: 800px; height: 30px;">
|
||||
how this object is used: 0: not a weapon, 1: melee weapon, 2: ranged weapon, 3: magic (projectile).<br />
|
||||
When you "use" an object, an it is not a weapon, its associated action will be executed
|
||||
immediately. When it is a weapon, it is merely selected, and
|
||||
it is then available for repeated execution through the fire button (see attackrate).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
damage</td>
|
||||
<td style="width: 800px">
|
||||
if not 0, this object can be used a weapon</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
maxrange</td>
|
||||
<td style="width: 800px">
|
||||
max range within which objects can be targeted when this object is used</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
maxangle</td>
|
||||
<td style="width: 800px">
|
||||
max angle from "forward" that objects can be targeted</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
attackrate</td>
|
||||
<td style="width: 800px">
|
||||
minimum time between two uses of this object</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
manacost</td>
|
||||
<td style="width: 800px">
|
||||
amount of mana used up for one use of this object</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="width: 100px">
|
||||
effect</td>
|
||||
<td style="width: 800px">
|
||||
the effect associated with this item when it is used... for spells it is the particle
|
||||
number</td>
|
||||
</tr>
|
||||
<tr style="font-family: verdana,'trebuchet ms','zurich bt',tahoma,arial,helvetica,sans-serif">
|
||||
<td style="width: 100px">
|
||||
attra, attrb, attrc</td>
|
||||
<td style="width: 800px">
|
||||
generic attributes, can be set by the script code to implement gameplay features
|
||||
not foreseen by the system</td>
|
||||
</tr>
|
||||
<tr style="font-family: verdana,'trebuchet ms','zurich bt',tahoma,arial,helvetica,sans-serif">
|
||||
<td style="width: 100px">
|
||||
usesound</td>
|
||||
<td style="width: 800px">
|
||||
sound played when this item is used. value must be from a call to "registersound"</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
These can be used similarly using r_X and r_get_X.
|
||||
</p>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
/* Sauerbraten Stylesheet */
|
||||
body { margin: 50px 4%; width: 90%; background-color: #302c28; color: #ffffff; font-family: verdana,"trebuchet ms","zurich bt",tahoma,arial,helvetica,sans-serif; font-size: 8pt; }
|
||||
a { text-decoration: underline; color: #ffbb00; }
|
||||
a:visited { color: #ff9900; }
|
||||
a:hover { color: #ff9900; }
|
||||
h1,h2,h3 { margin: 20px 1px 4px 1px; background-color: #662222; font-weight: bold; }
|
||||
h1 { font-size: 120%; }
|
||||
h2 { font-size: 100%; }
|
||||
h3 { font-size: 90%; }
|
||||
pre,code { padding: 1px 10px 1px 10px; font-family: monospace; border: 2px dotted #662222 }
|
||||
table,tr,td { margin: 0px 0px 0px 0px; padding: 0px 0px 0px 0px; border: 2px solid #662222; }
|
||||
p { padding: 1px 10px 5px 10px; }
|
||||
div { padding: 1px 10px 1px 10px; }
|
||||
div.credits { letter-spacing: 8px; font-weight: bold; }
|
||||
div.contents, .wiki #toc
|
||||
{ margin: 0px 0px 10px 20px; padding: 1px 10px 1px 1px; background-color: #302c28; border: 2px solid #662222; float: right; clear: right; width: 25%; }
|
||||
ul.contents { list-style-type: decimal; list-style-position: outside; }
|
||||
ul.contents2 { list-style-type: disc; list-style-position: outside; }
|
||||
ul.contents3 { list-style-type: square; list-style-position: outside; }
|
||||
|
|
@ -1 +0,0 @@
|
|||
start bin\sauerbraten.exe "-q$HOME\My Games\Sauerbraten" -glog.txt %*
|
||||
|
|
@ -9,7 +9,7 @@ SAUER_BIN=${SAUER_DATA}/bin_unix
|
|||
|
||||
# SAUER_OPTIONS contains any command line options you would like to start Sauerbraten with.
|
||||
#SAUER_OPTIONS="-f"
|
||||
SAUER_OPTIONS="-q${HOME}/.sauerbraten"
|
||||
SAUER_OPTIONS="-q${HOME}/.sauerbraten -ktesseract"
|
||||
|
||||
# SYSTEM_NAME should be set to the name of your operating system.
|
||||
#SYSTEM_NAME=Linux
|
||||
|
|
|
|||
134
src/Makefile
134
src/Makefile
|
|
@ -42,7 +42,7 @@ CLIENT_OBJS= \
|
|||
engine/decal.o \
|
||||
engine/dynlight.o \
|
||||
engine/grass.o \
|
||||
engine/lightmap.o \
|
||||
engine/light.o \
|
||||
engine/main.o \
|
||||
engine/material.o \
|
||||
engine/menus.o \
|
||||
|
|
@ -204,104 +204,101 @@ shared/zip.o: shared/cube.h shared/tools.h shared/geom.h shared/ents.h
|
|||
shared/zip.o: shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/3dgui.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/3dgui.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/3dgui.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/3dgui.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/3dgui.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/3dgui.o: engine/textedit.h
|
||||
engine/bih.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/bih.o: shared/ents.h shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/bih.o: engine/world.h engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/bih.o: engine/world.h engine/octa.h engine/light.h engine/bih.h
|
||||
engine/bih.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/blend.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/blend.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/blend.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/blend.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/blend.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/client.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/client.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/client.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/client.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/client.o: engine/model.h engine/varray.h
|
||||
engine/client.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/client.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/command.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/command.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/command.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/command.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/command.o: engine/model.h engine/varray.h
|
||||
engine/command.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/command.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/command.o: engine/varray.h
|
||||
engine/console.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/console.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/console.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/console.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/console.o: engine/model.h engine/varray.h
|
||||
engine/console.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/console.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/console.o: engine/varray.h
|
||||
engine/decal.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/decal.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/decal.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/decal.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/decal.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/dynlight.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/dynlight.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/dynlight.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/dynlight.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/dynlight.o: engine/model.h engine/varray.h
|
||||
engine/dynlight.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/dynlight.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/dynlight.o: engine/varray.h
|
||||
engine/grass.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/grass.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/grass.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/grass.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/grass.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/lightmap.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/lightmap.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/lightmap.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/lightmap.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/lightmap.o: engine/model.h engine/varray.h
|
||||
engine/light.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/light.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/light.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/light.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/main.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/main.o: shared/ents.h shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/main.o: engine/world.h engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/main.o: engine/world.h engine/octa.h engine/light.h engine/bih.h
|
||||
engine/main.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/material.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/material.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/material.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/material.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/material.o: engine/model.h engine/varray.h
|
||||
engine/material.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/material.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/material.o: engine/varray.h
|
||||
engine/menus.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/menus.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/menus.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/menus.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/menus.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/movie.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/movie.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/movie.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/movie.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/movie.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/normal.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/normal.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/normal.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/normal.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/normal.o: engine/model.h engine/varray.h
|
||||
engine/normal.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/normal.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/octa.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/octa.o: shared/ents.h shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/octa.o: engine/world.h engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/octa.o: engine/world.h engine/octa.h engine/light.h engine/bih.h
|
||||
engine/octa.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/octaedit.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/octaedit.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/octaedit.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/octaedit.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/octaedit.o: engine/model.h engine/varray.h
|
||||
engine/octaedit.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/octaedit.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/octaedit.o: engine/varray.h
|
||||
engine/octarender.o: engine/engine.h shared/cube.h shared/tools.h
|
||||
engine/octarender.o: shared/geom.h shared/ents.h shared/command.h
|
||||
engine/octarender.o: shared/iengine.h shared/igame.h engine/world.h
|
||||
engine/octarender.o: engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/octarender.o: engine/octa.h engine/light.h engine/bih.h
|
||||
engine/octarender.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/physics.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/physics.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/physics.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/physics.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/physics.o: engine/model.h engine/varray.h engine/mpr.h
|
||||
engine/physics.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/physics.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/physics.o: engine/varray.h engine/mpr.h
|
||||
engine/pvs.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/pvs.o: shared/ents.h shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/pvs.o: engine/world.h engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/pvs.o: engine/world.h engine/octa.h engine/light.h engine/bih.h
|
||||
engine/pvs.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/rendergl.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/rendergl.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/rendergl.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/rendergl.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/rendergl.o: engine/model.h engine/varray.h
|
||||
engine/rendergl.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/rendergl.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/rendergl.o: engine/varray.h
|
||||
engine/rendermodel.o: engine/engine.h shared/cube.h shared/tools.h
|
||||
engine/rendermodel.o: shared/geom.h shared/ents.h shared/command.h
|
||||
engine/rendermodel.o: shared/iengine.h shared/igame.h engine/world.h
|
||||
engine/rendermodel.o: engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/rendermodel.o: engine/octa.h engine/light.h engine/bih.h
|
||||
engine/rendermodel.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/rendermodel.o: engine/ragdoll.h engine/animmodel.h engine/vertmodel.h
|
||||
engine/rendermodel.o: engine/skelmodel.h engine/md2.h engine/md3.h
|
||||
|
|
@ -309,62 +306,60 @@ engine/rendermodel.o: engine/md5.h engine/obj.h engine/smd.h engine/iqm.h
|
|||
engine/renderparticles.o: engine/engine.h shared/cube.h shared/tools.h
|
||||
engine/renderparticles.o: shared/geom.h shared/ents.h shared/command.h
|
||||
engine/renderparticles.o: shared/iengine.h shared/igame.h engine/world.h
|
||||
engine/renderparticles.o: engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/renderparticles.o: engine/octa.h engine/light.h engine/bih.h
|
||||
engine/renderparticles.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/renderparticles.o: engine/explosion.h engine/lensflare.h
|
||||
engine/renderparticles.o: engine/lightning.h
|
||||
engine/rendersky.o: engine/engine.h shared/cube.h shared/tools.h
|
||||
engine/rendersky.o: shared/geom.h shared/ents.h shared/command.h
|
||||
engine/rendersky.o: shared/iengine.h shared/igame.h engine/world.h
|
||||
engine/rendersky.o: engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/rendersky.o: engine/octa.h engine/light.h engine/bih.h
|
||||
engine/rendersky.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/rendertext.o: engine/engine.h shared/cube.h shared/tools.h
|
||||
engine/rendertext.o: shared/geom.h shared/ents.h shared/command.h
|
||||
engine/rendertext.o: shared/iengine.h shared/igame.h engine/world.h
|
||||
engine/rendertext.o: engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/rendertext.o: engine/octa.h engine/light.h engine/bih.h
|
||||
engine/rendertext.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/renderva.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/renderva.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/renderva.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/renderva.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/renderva.o: engine/model.h engine/varray.h
|
||||
engine/renderva.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/renderva.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/renderva.o: engine/varray.h
|
||||
engine/server.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/server.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/server.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/server.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/server.o: engine/model.h engine/varray.h
|
||||
engine/server.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/server.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/serverbrowser.o: engine/engine.h shared/cube.h shared/tools.h
|
||||
engine/serverbrowser.o: shared/geom.h shared/ents.h shared/command.h
|
||||
engine/serverbrowser.o: shared/iengine.h shared/igame.h engine/world.h
|
||||
engine/serverbrowser.o: engine/octa.h engine/lightmap.h engine/bih.h
|
||||
engine/serverbrowser.o: engine/octa.h engine/light.h engine/bih.h
|
||||
engine/serverbrowser.o: engine/texture.h engine/model.h engine/varray.h
|
||||
engine/shader.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/shader.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/shader.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/shader.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/shader.o: engine/model.h engine/varray.h
|
||||
engine/shader.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/shader.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/sound.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/sound.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/sound.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/sound.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/sound.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/texture.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/texture.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/texture.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/texture.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/texture.o: engine/model.h engine/varray.h engine/scale.h
|
||||
engine/texture.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/texture.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/texture.o: engine/varray.h engine/scale.h
|
||||
engine/water.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/water.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/water.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/water.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/water.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/world.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/world.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/world.o: shared/igame.h engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/world.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/world.o: engine/bih.h engine/texture.h engine/model.h engine/varray.h
|
||||
engine/worldio.o: engine/engine.h shared/cube.h shared/tools.h shared/geom.h
|
||||
engine/worldio.o: shared/ents.h shared/command.h shared/iengine.h
|
||||
engine/worldio.o: shared/igame.h engine/world.h engine/octa.h
|
||||
engine/worldio.o: engine/lightmap.h engine/bih.h engine/texture.h
|
||||
engine/worldio.o: engine/model.h engine/varray.h
|
||||
engine/worldio.o: shared/igame.h engine/world.h engine/octa.h engine/light.h
|
||||
engine/worldio.o: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/worldio.o: engine/varray.h
|
||||
fpsgame/ai.o: fpsgame/game.h shared/cube.h shared/tools.h shared/geom.h
|
||||
fpsgame/ai.o: shared/ents.h shared/command.h shared/iengine.h shared/igame.h
|
||||
fpsgame/ai.o: fpsgame/ai.h
|
||||
|
|
@ -405,9 +400,8 @@ shared/cube.h.gch: shared/tools.h shared/geom.h shared/ents.h
|
|||
shared/cube.h.gch: shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/engine.h.gch: shared/cube.h shared/tools.h shared/geom.h shared/ents.h
|
||||
engine/engine.h.gch: shared/command.h shared/iengine.h shared/igame.h
|
||||
engine/engine.h.gch: engine/world.h engine/octa.h engine/lightmap.h
|
||||
engine/engine.h.gch: engine/bih.h engine/texture.h engine/model.h
|
||||
engine/engine.h.gch: engine/varray.h
|
||||
engine/engine.h.gch: engine/world.h engine/octa.h engine/light.h engine/bih.h
|
||||
engine/engine.h.gch: engine/texture.h engine/model.h engine/varray.h
|
||||
fpsgame/game.h.gch: shared/cube.h shared/tools.h shared/geom.h shared/ents.h
|
||||
fpsgame/game.h.gch: shared/command.h shared/iengine.h shared/igame.h
|
||||
fpsgame/game.h.gch: fpsgame/ai.h
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
#ifndef STANDALONE
|
||||
|
||||
#include "octa.h"
|
||||
#include "lightmap.h"
|
||||
#include "light.h"
|
||||
#include "bih.h"
|
||||
#include "texture.h"
|
||||
#include "model.h"
|
||||
|
|
|
|||
|
|
@ -1,17 +1,9 @@
|
|||
#define LM_MINW 2
|
||||
#define LM_MINH 2
|
||||
#define LM_MAXW 128
|
||||
#define LM_MAXH 128
|
||||
#define LM_PACKW 512
|
||||
#define LM_PACKH 512
|
||||
|
||||
struct PackNode
|
||||
{
|
||||
PackNode *child1, *child2;
|
||||
ushort x, y, w, h;
|
||||
int available;
|
||||
|
||||
PackNode() : child1(0), child2(0), x(0), y(0), w(LM_PACKW), h(LM_PACKH), available(min(LM_PACKW, LM_PACKH)) {}
|
||||
PackNode(ushort x, ushort y, ushort w, ushort h) : child1(0), child2(0), x(x), y(y), w(w), h(h), available(min(w, h)) {}
|
||||
|
||||
void discardchildren()
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
Note that this is the license only for original Sauerbraten code, and does
|
||||
not cover new code provided as part of the Tesseract engine. For the
|
||||
license governing those changes, please see the included "readme_tesseract.txt".
|
||||
|
||||
Sauerbraten source code license, usage, and documentation.
|
||||
|
||||
You may use the Sauerbraten source code if you abide by the ZLIB license
|
||||
|
|
@ -10,7 +14,7 @@ LICENSE
|
|||
|
||||
Sauerbraten game engine source code, any release.
|
||||
|
||||
Copyright (C) 2001-2011 Wouter van Oortmerssen, Lee Salzman, Mike Dysart, Robert Pointon, and Quinton Reeves
|
||||
Copyright (C) 2001-2012 Wouter van Oortmerssen, Lee Salzman, Mike Dysart, Robert Pointon, and Quinton Reeves
|
||||
|
||||
This software is provided 'as-is', without any express or implied
|
||||
warranty. In no event will the authors be held liable for any damages
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
Note that this license is an extension of the original Sauerbraten source
|
||||
code license which is included under the file "readme_sauerbraten.txt" for
|
||||
reference. Both are essentially the ZLIB license, but the Tesseract license
|
||||
may include differing copyright owners and usage clarifications.
|
||||
|
||||
Tesseract source code license, usage, and documentation.
|
||||
|
||||
You may use the Tesseract source code if you abide by the ZLIB license
|
||||
http://www.opensource.org/licenses/zlib-license.php
|
||||
(very similar to the BSD license):
|
||||
|
||||
|
||||
LICENSE
|
||||
=======
|
||||
|
||||
Tesseract game engine source code, any release.
|
||||
|
||||
Copyright (C) 2001-2012 Wouter van Oortmerssen, Lee Salzman, Mike Dysart, Robert Pointon, Quinton Reeves, and Benjamin Segovia
|
||||
|
||||
This software is provided 'as-is', without any express or implied
|
||||
warranty. In no event will the authors be held liable for any damages
|
||||
arising from the use of this software.
|
||||
|
||||
Permission is granted to anyone to use this software for any purpose,
|
||||
including commercial applications, and to alter it and redistribute it
|
||||
freely, subject to the following restrictions:
|
||||
|
||||
1. The origin of this software must not be misrepresented; you must not
|
||||
claim that you wrote the original software. If you use this software
|
||||
in a product, an acknowledgment in the product documentation would be
|
||||
appreciated but is not required.
|
||||
2. Altered source versions must be plainly marked as such, and must not be
|
||||
misrepresented as being the original software.
|
||||
3. This notice may not be removed or altered from any source distribution.
|
||||
|
||||
|
||||
LICENSE NOTES
|
||||
=============
|
||||
The license covers the source code found in the "src" directory of this
|
||||
archive as well as the .cfg files under the "data" directory. The included
|
||||
ENet network library which Tesseract uses is covered by an MIT-style
|
||||
license, which is however compatible with the above license for all
|
||||
practical purposes.
|
||||
|
||||
Other media included with this distribution (maps, textures, sounds, models etc.)
|
||||
are NOT covered by this license, and may have individual copyrights and
|
||||
distribution restrictions (see individual readmes).
|
||||
|
||||
AUTHORS
|
||||
======
|
||||
Wouter "Aardappel" van Oortmerssen
|
||||
http://strlen.com
|
||||
|
||||
Lee "eihrul" Salzman
|
||||
http://lee.fov120.com
|
||||
|
||||
Mike "Gilt" Dysart
|
||||
|
||||
Robert "baby-rabbit" Pointon
|
||||
http://www.fernlightning.com
|
||||
|
||||
Quinton "Quin" Reeves
|
||||
http://www.redeclipse.net
|
||||
|
||||
Benjamin Segovia
|
||||
|
||||
For additional authors/contributors, see the Tesseract distribution readme.
|
||||
|
||||
|
|
@ -973,7 +973,7 @@ struct triangle
|
|||
|
||||
/**
|
||||
|
||||
Sauerbraten uses 3 different linear coordinate systems
|
||||
The engine uses 3 different linear coordinate systems
|
||||
which are oriented around each of the axis dimensions.
|
||||
|
||||
So any point within the game can be defined by four coordinates: (d, x, y, z)
|
||||
|
|
|
|||
|
|
@ -427,7 +427,7 @@
|
|||
</FileConfiguration>
|
||||
</File>
|
||||
<File
|
||||
RelativePath="..\engine\lightmap.cpp"
|
||||
RelativePath="..\engine\light.cpp"
|
||||
>
|
||||
<FileConfiguration
|
||||
Name="Release|Win32"
|
||||
|
|
@ -458,7 +458,7 @@
|
|||
</FileConfiguration>
|
||||
</File>
|
||||
<File
|
||||
RelativePath="..\engine\lightmap.h"
|
||||
RelativePath="..\engine\light.h"
|
||||
>
|
||||
</File>
|
||||
<File
|
||||
|
|
|
|||
|
|
@ -210,11 +210,11 @@
|
|||
<Option target="default" />
|
||||
<Option target="debug" />
|
||||
</Unit>
|
||||
<Unit filename="..\engine\lightmap.cpp">
|
||||
<Unit filename="..\engine\light.cpp">
|
||||
<Option target="default" />
|
||||
<Option target="debug" />
|
||||
</Unit>
|
||||
<Unit filename="..\engine\lightmap.h">
|
||||
<Unit filename="..\engine\light.h">
|
||||
<Option target="default" />
|
||||
<Option target="debug" />
|
||||
</Unit>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@
|
|||
B9AC7AD30D06DB44005506F8 /* command.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A880D06DB44005506F8 /* command.cpp */; };
|
||||
B9AC7AD40D06DB44005506F8 /* console.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A890D06DB44005506F8 /* console.cpp */; };
|
||||
B9AC7AD70D06DB44005506F8 /* grass.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A8C0D06DB44005506F8 /* grass.cpp */; };
|
||||
B9AC7AD80D06DB44005506F8 /* lightmap.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A8D0D06DB44005506F8 /* lightmap.cpp */; };
|
||||
B9AC7AD80D06DB44005506F8 /* light.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A8D0D06DB44005506F8 /* light.cpp */; };
|
||||
B9AC7ADA0D06DB44005506F8 /* main.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A8F0D06DB44005506F8 /* main.cpp */; };
|
||||
B9AC7ADB0D06DB44005506F8 /* material.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A900D06DB44005506F8 /* material.cpp */; };
|
||||
B9AC7ADE0D06DB44005506F8 /* menus.cpp in Sources */ = {isa = PBXBuildFile; fileRef = B9AC7A930D06DB44005506F8 /* menus.cpp */; };
|
||||
|
|
@ -139,8 +139,8 @@
|
|||
B9AC7A890D06DB44005506F8 /* console.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = console.cpp; sourceTree = "<group>"; };
|
||||
B9AC7A8B0D06DB44005506F8 /* engine.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = engine.h; sourceTree = "<group>"; };
|
||||
B9AC7A8C0D06DB44005506F8 /* grass.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = grass.cpp; sourceTree = "<group>"; };
|
||||
B9AC7A8D0D06DB44005506F8 /* lightmap.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = lightmap.cpp; sourceTree = "<group>"; };
|
||||
B9AC7A8E0D06DB44005506F8 /* lightmap.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = lightmap.h; sourceTree = "<group>"; };
|
||||
B9AC7A8D0D06DB44005506F8 /* light.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = light.cpp; sourceTree = "<group>"; };
|
||||
B9AC7A8E0D06DB44005506F8 /* light.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = light.h; sourceTree = "<group>"; };
|
||||
B9AC7A8F0D06DB44005506F8 /* main.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = main.cpp; sourceTree = "<group>"; };
|
||||
B9AC7A900D06DB44005506F8 /* material.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = material.cpp; sourceTree = "<group>"; };
|
||||
B9AC7A910D06DB44005506F8 /* md2.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = md2.h; sourceTree = "<group>"; };
|
||||
|
|
@ -374,7 +374,7 @@
|
|||
B91D40200D525FE0004EF78A /* decal.cpp */,
|
||||
D16BD00C0D7000EA0053CECE /* dynlight.cpp */,
|
||||
B9AC7A8C0D06DB44005506F8 /* grass.cpp */,
|
||||
B9AC7A8D0D06DB44005506F8 /* lightmap.cpp */,
|
||||
B9AC7A8D0D06DB44005506F8 /* light.cpp */,
|
||||
B9AC7A8F0D06DB44005506F8 /* main.cpp */,
|
||||
B9AC7A900D06DB44005506F8 /* material.cpp */,
|
||||
B9AC7A930D06DB44005506F8 /* menus.cpp */,
|
||||
|
|
@ -405,7 +405,7 @@
|
|||
D19E775D11977E82003753EF /* iqm.h */,
|
||||
D18B8FBF0DB0AF8200171439 /* lensflare.h */,
|
||||
D18B8FC00DB0AF8200171439 /* lightning.h */,
|
||||
B9AC7A8E0D06DB44005506F8 /* lightmap.h */,
|
||||
B9AC7A8E0D06DB44005506F8 /* light.h */,
|
||||
B9AC7A910D06DB44005506F8 /* md2.h */,
|
||||
B9AC7A920D06DB44005506F8 /* md3.h */,
|
||||
B91D40220D525FE9004EF78A /* md5.h */,
|
||||
|
|
@ -592,7 +592,7 @@
|
|||
B9AC7AD30D06DB44005506F8 /* command.cpp in Sources */,
|
||||
B9AC7AD40D06DB44005506F8 /* console.cpp in Sources */,
|
||||
B9AC7AD70D06DB44005506F8 /* grass.cpp in Sources */,
|
||||
B9AC7AD80D06DB44005506F8 /* lightmap.cpp in Sources */,
|
||||
B9AC7AD80D06DB44005506F8 /* light.cpp in Sources */,
|
||||
B9AC7ADA0D06DB44005506F8 /* main.cpp in Sources */,
|
||||
B9AC7ADB0D06DB44005506F8 /* material.cpp in Sources */,
|
||||
B9AC7ADE0D06DB44005506F8 /* menus.cpp in Sources */,
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
start bin\sauerbraten.exe "-q$HOME\My Games\Tesseract" -ktesseract -glog.txt %*
|
||||
|
Before Width: | Height: | Size: 124 KiB After Width: | Height: | Size: 124 KiB |
|
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 52 KiB |
Loading…
Reference in New Issue