This is the sidebar
This is an old revision of the document!
Give me some time until this is finished
Welcome to the QuakeC programming introduction. This article is intended for people who already have their fair share of experience in other programming languages like Java or C/C++. As you know, there is already the QuakeC reference guide which gives you an overview of the language used in server-side and client-side quake code. You will actually need to read that page at some point. Anyways, this page will provide the following information:
To summarize this page: It explains how to setup an environment in which you can efficiently develop SVQC (server-side QC) and CSQC (client-side QC).
Keep in mind that this page does not provide coding tutorials. Some of these may be created another time at another place.
From the programming perspective, Nexuiz consists of two parts:
The game engine provides the capability to run a dedicated (console-only) server as well as acting as a client (which you use to play the game). As you know, DarkPlaces runs on Windows, Linux and Mac systems. To achieve that, the developers have to do quite a bit of work, as they'll have to use different APIs for accessing the hardware that Nexuiz interacts with (such as the keyboard, mouse, joystick, soundcard...), as each operation system provides different APIs for that purpose. This is the reason why all the game-specific logic, e.g. the program code of the game modes, weapons, items, etc. is not written in the engine, as this would mean to write it in the language of the engine, and would also mean that you have to compile the whole engine each time you do a change in the game code.
Instead, the game logic is implemented in its own language, QuakeC, which is compiled by its own compiler, in our case FTEQCC (FTE QuakeC Compiler). The compiled code generated by FTEQCC gets into a file which is the placed inside the data dir of Nexuiz. When you launch the engine, it will look for that file and run the compiled code which is in that file in a virtual machine. This has three advantages:
However, it also has disadvantages:
For compilation the FTEQCC needs a file called progs.src which basically contains a list of all .qc and .qh files (note the intended similarity to .c and .h files). FTEQCC then compiles all these qc and qh files after another and puts the result in a .dat file. Remember that I was talking about 1 file that is interpreted by the engine? In fact, you actually need 3 of these files (and you also need to run FTEQCC 3 times while you specify a different progs.src file each time):
All 3 dat files need to be placed in the data directory of Nexuiz, as the engine expects them to be there.
Another note: FTEQCC also creates a lno file for each dat file. For Nexuiz these lno files are not important or needed. In case that you distribute a mod you created, you won't have to publish the lno files, only the dat files.
Hereby I assume that you are familiar with the basics of SVN and know how to check out code from a given location. Usually you would now have to download Nexuiz and it's QuakeC code, the DP engine and FTEQCC from SVN, compile FTEQCC and DP and then use your fresh FTEQCC binary to compile the code inside /data/qrsrc. However, the compilation of DP or FTEQCC can be non-trivial, especially for the ones that are not used to Makefiles and the C compiler.
This is the reason why beginners should use a premade build-system. However, the build systems are platform specific.
For windows you can get the build-system made by divVerent, located here. After you downloaded and extracted the zip file, all you have to do is to start the build.bat file and wait. The script will do all the work for you:
Note 1: The compiled FTEQCC binary is the console version which makes sense as it is executed in the batch file, however, there is also a GUI version of FTEQCC that you can get in one Nexuiz source package builds also done by divVerent, e.g. here.
Note 2: For the future I would recommend that you take a closer look at the build.bat file and create your own modified versions of it, e.g. one that only compiles the Nexuiz game code with FTEQCC - you will need this one often when you change the game code in your future QuakeC coder career and you want to compile it fast.
Note 3: To start the game, all you need to do is to start the run-wgl.bat or run-sdl.bat file. The three dat files generated by FTEQCC will already be in the correct place, you don't need to worry about that!
TODO: Someone else has to do the linux part!
TODO: Someone else has to do the mac part!
Even though the build-system mentioned above comes with a command-line svn client used for checking out the sources and updating them, you will need at least one good SVN client with a graphical user interface. If you are ambitious and, within given time, do more or less big changes to the QuakeC code base, you will find out that you will have to do a lot of conflict merging when you update your SVN copy, because it is likely that you changed parts of the code that were, in the meantime, also changed by the official developers. The other reason to use a handsome SVN tool is the ability to create and apply patches to your code base without being a victim of command line tools.
Eclipse in combination with Subclipse is the only tool I know of that allows you to have a truly non-destructive update procedure. Normally, when you use other tools and you update your code and a conflict is detected, SVN will mess with your file system, create ”.mine” files, etc, and you have to hope that your merge tool is good enough to do the job after the catastrophy happened. With Eclipse+Subclipse, there is the “Team synchronisation” perspective that allows you “spy first”, you click on “synchronize” and you will see which files would be updated if you clicked on “update”. You will also see which files would become a conflicted file, you can deal with the conflict before hand and save the merged file.
Here is how to use it: TODO
http://subclipse.tigris.org/update_1.4.x
TODO: Introduce Eclipse+Subclipse Plugin. Alternative: TortoiseSVN (what about Linux?)
TODO: good for patching patched files, diffing and patching in general
TODO: you linux gurus do that ;p
TODO: Introduction to CodeBLocks, explain the features of it. Explain known bugs.
TODO: Link to the article in this wiki. Some explanations.
TODO2: Explain how to access built-in functions.
TODO: Explain the common tasks that come with the usage of SVN and the fact that you likely changed (a lot of) code:
- Updating SVN by using Team Synchronisation feature of Subclipse to prevent conflicts when updating
- Creating patches to backup your work, keeping your work modular.
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() | |
![]() | GFDLcontent Unless mentioned on the licensing page, the work on this page is licensed under the GNU Free Documentation License. The author states that the text and images can be used within the restrictions of this license (for example, they can be incorporated into certain free encyclopedias such as Wikipedia). |
Kindly hosted by NexuizNinjaz.com |