Hosting and domain costs until October 2024 have been generously sponsored by dumptruck_ds. Thank you!
Difference between revisions of "Skybox Support"
From Quake Wiki
(→Loading from Worldspawn) |
(→Loading from Worldspawn) |
||
| Line 31: | Line 31: | ||
To issue these commands you need to use the "stuffcmd" function instead and make sure that the entity first parameter is the player that you are controlling in the game. | To issue these commands you need to use the "stuffcmd" function instead and make sure that the entity first parameter is the player that you are controlling in the game. | ||
| − | But luckily "loadsky" has nothing to do with the player that we are controlling in the game and this means that this command can be invoked with the "localcmd" function! | + | But both luckily and fortunately "loadsky" has nothing to do with the player that we are controlling in the game and this means that this command can be invoked with the "localcmd" function! |
For example if you want to always see a blue sky no matter what level, map and skill you play then make sure that you have all the six images files of a blue skybox in the "id1/gfx/env" directory or folder or in a pak or pk3 file(s) and in the "worldspawn" function, that is usually defined in the "world.qc" file, somewhere just insert/inject the following line of code: | For example if you want to always see a blue sky no matter what level, map and skill you play then make sure that you have all the six images files of a blue skybox in the "id1/gfx/env" directory or folder or in a pak or pk3 file(s) and in the "worldspawn" function, that is usually defined in the "world.qc" file, somewhere just insert/inject the following line of code: | ||
Revision as of 01:33, 14 October 2021
Contents
Abstract
This page proposes a standard for implementing Skybox Support in Quake 1 engines. Please be aware that as the Quake 1 source has been released for a significant number of years, there are already diverging implementations. The proposed standard attempts to cover the most commonly used. Engines which diverge from the standard should be re-engineered to conform to it.
If you feel I've got anything wrong here, feel free to put it right - it is a Wiki, after all!
Description
A Skybox consists of 6 image files, representing the 6 faces of a cube, which is then rendered at a far (but fixed) distance from the observer. See Quake II (and others) for an example.
Loading a Skybox
A skybox is loaded using either the "loadsky" console command or directly from the BSP file (by specifying a skybox name in the worldspawn entry).
The "loadsky" Command
This command should take one argument: the skybox base name (see "Naming Convention" below). A Quake filesystem path is not required. If the skybox loads successfully, it is immediately used to replace the classic Quake sky. If the skybox load fails, the current skybox (or the classic Quake sky) is retained. The standard does not specify what happens if only some of the 6 faces fail to load.
Loading from Worldspawn
This is possible to load your favorite skies, assuming that you have all of them in the "id1/gfx/env" directory or folder or in a pak or pk3 file(s), automatically, without having to manually invoke the "loadsky" command every time you either start a new map, level or episode, by using the "worldspawn" QuakeC function if you have the source QuakeC (QC in short) code of the game that you want to play and a working QuakeC compiler that can compile for you the source QuakeC code and produce a valid "progs.dat" file that you should then place it inside the "id1" directory or folder.
Assuming that all of the above is true then:
In the "worldspawn" QuakeC function, that is usually defined in the "world.qc" file, invoke the "loadsky" command of your favorite Quake client or engine that you use by using the "localcmd" function, that is usually defined in the "defs.qc" file, without forgetting the line feed suffix "\n".
"localcmd" is a C function of every Quake client and engine written in the C programming language and this function can be used in QuakeC without having to mess up with the C source code of your favorite Quake client/engine that you chose to use to play any Quake game.
This function allows you to automatically invoke every command that you can manually invoke with the console in game except commands that are related to the player that you are controlling with your keyboard and mouse, like the bf,give, god, fly, notarget and noclip commands.
To issue these commands you need to use the "stuffcmd" function instead and make sure that the entity first parameter is the player that you are controlling in the game.
But both luckily and fortunately "loadsky" has nothing to do with the player that we are controlling in the game and this means that this command can be invoked with the "localcmd" function!
For example if you want to always see a blue sky no matter what level, map and skill you play then make sure that you have all the six images files of a blue skybox in the "id1/gfx/env" directory or folder or in a pak or pk3 file(s) and in the "worldspawn" function, that is usually defined in the "world.qc" file, somewhere just insert/inject the following line of code:
localcmd("loadsky bluesky\n"); //I want to see a blue sky all the time
If you have a large collection of many different skies all in the "id1/gfx/env" directory or folder or in a pak or pk3 file(s) then you may want to use the "self.model" variable to know which sky to load for which level and map.
For example if you love to see night when starting a new game then make sure that you have all the six images files of a night skybox in the "id1/gfx/env" directory or folder or in a pak or pk3 file(s) and then in the "worldspawn" QuakeC function, that is usually defined in the "world.qc" file, somewhere insert/inject the following line of code:
if (self.model == "maps/start.bsp") localcmd("loadsky night\n"); //I love to see night when starting a new game
Use the "skill" global variable instead of the "self.model" variable if you have at least 4 skies for Easy, Normal, Hard and Nightmare skills.
If you do have them then you may want in the "worldspawn" QuakeC function, usually defined in the world.qc file, somewhere insert/inject the following piece of code:
if (skill == 0) localcmd("loadsky easy\n"); //Load the "easy" sky if I am playing the game on the "Easy" skill else if (skill == 1) localcmd("loadsky normal\n"); //Load the "normal" sky if I am playing the game on the "Normal" skill else if (skill == 2) localcmd("loadsky hard\n"); //Load the "hard" sky if I am playing the game on the "Hard" skill else if (skill == 3) localcmd("loadsky nightmare\n"); //Load the "nightmare" sky if I am playing the game on the "Nightmare" skill
This way you can know what is the skill of the game without bringing down the console with tilde and then type "skill".
Just look up on the sky and the sky will tell you what is the skill of the game that you are playing!
Of course that after inserting/injecting the piece of code with any text editor, like Notepad, make sure that you save all the changes that you have made to the file, that should be usually world.qc, before closing your favorite text editor (for me Notepad is my favorite text editor because it is so fast, lightweight and very easy to use and it is built-in in Windows 10).
After saving all the changes and closing the text editor you need to compile the QuakeC QC code with a working QuakeC compiler.
Nowadays all the QuakeC developers, coders and programmers use either FTEQCC or GMQCC to compile QuakeC code.
Between the two FTEQCC is my favorite QuakeC compiler because it has a GUI version, lightweight and very easy to use exactly like Notepad.
Yes I personally love all software that are both lightweight and very easy to use!
But choose the QuakeC compiler that best fits your needs.
If you are using a QuakeC compiler that is a console application then make sure that the executable file of the QuakeC compiler is in the same directory or folder where all the source QuakeC files are.
If you are using the GUI version of FTEQCC, usually called "fteqccgui.exe" or "fteqccgui64.exe", then you can place the executable file wherever you want but when launching the QuakeC compiler you must find and open the "progs.src".
The "progs.src" file should be in the same directory or folder where all the source QuakeC files are.
If you have successfully compile the source QuakeC code then the QuakeC compiler, that you chose to use, should create a "progs.dat" file, Usually outside of the directory or folder where all the source QuakeC files are.
Make sure that this "progs.dat" file is inside the "id1" directory/folder where all the pak and pk3 files of the game should be.
This should not be "id1" if you execute the Quake client/engine with the "-game" command argument but it should be X instead if the "-game X" command argument specified.
If the "progs.dat" file is in the right directory or folder then you can play the game with all your favorite skies and they will be loaded automatically as you like!
Unloading a Skybox
Issuing the "loadsky" command without any arguments will unload the current skybox and revert to the classic Quake sky. Engine coders may implement an "unloadsky" command if they wish, but this is not a requirement and should not be relied on.
Image Formats
Skyboxes should be provided as either TGA or PNG files. All 6 faces should be same format (should engines be required to support a possibility that they are different formats?) The images should be sized so that they are powers of 2: 256 x 256, 512 x 512 or 1024 x 1024 are common sizes. The 6 faces need not be the same size.
Naming Convention
Each Skybox face name is composed of two components: the base name and a suffix indicating which face the image relates to.
The base name should be strictly alphanumeric, and should not contain spaces. Only the base name is used for loading.
The suffix should be either of "bk" (back face), "ft" (front face), "lf" (left face), "rt" (right face), "up" (up face) or "dn" (down face).
Optionally, there may be an underscore ("_") between the base name and the suffix. Engines should be capable of successfully loading a skybox (1) where the underscore is present in both the load command and the name, (2) where the underscore is absent in the load command but present in the name, and (3) where the underscore is absent in both.
Filesystem
Skyboxes may be stored in either the native OS filesystem or in a PAK file, and loading from either should be supported in any implementation. All filesystem references are relative to the base game directory (e.g "ID1").
A skybox may be loaded from any of "gfx", "env" or "gfx/env"; implementations should support loading from all 3. Skyboxes should not be present in "textures" (nor in any subdirectory thereof).
All 6 components of a skybox should be in the same directory.