Misplaced Pages

QuakeC: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 14:28, 4 August 2011 editClueBot NG (talk | contribs)Bots, Pending changes reviewers, Rollbackers6,438,920 editsm Reverting possible vandalism by 151.188.18.85 to version by Smyth. False positive? Report it. Thanks, ClueBot NG. (533832) (Bot)← Previous edit Latest revision as of 13:48, 10 December 2024 edit undoFrap (talk | contribs)Autopatrolled, Extended confirmed users, File movers, Pending changes reviewers, Rollbackers33,227 editsm →Client-side QuakeC 
(47 intermediate revisions by 42 users not shown)
Line 1: Line 1:
{{short description|Compiled language}}
{{Gamecleanup|May 2008|date=July 2008}}

{{Infobox programming language {{Infobox programming language
| name = QuakeC | name = QuakeC
| paradigm = ] (]), ] | paradigm = ] (]), ]
⚫ | year = 1996
| designer = ] | designer = ]
| developer = ] | developer = ]
⚫ | turing-complete = No
| typing = ], ] | typing = ], ]
| implementations = ], FastQCC, QCCx | implementations = Quake C Compiler, FastQCC, FTEQCC, QCCx, GMQCC
⚫ | year = 1996
⚫ | turing-complete = No
| influenced_by = ] | influenced_by = ]
}} }}


'''QuakeC''' is an ] developed in 1996 by ] of ] to program parts of the ] '']''. Using QuakeC, a programmer is able to customize ''Quake'' to great extents by adding weapons, changing game logic and physics, and programming complex scenarios. It can be used to control many aspects of the game itself, such as parts of the AI, triggers, or changes in the level. The ] was the only game engine to use QuakeC. Following engines used DLL game modules for customization written in ] and ] from idtech 4 on. '''QuakeC''' is a ] developed in 1996 by ] of ] to program parts of the ] '']''. Using QuakeC, a programmer is able to customize ''Quake'' to great extents by adding weapons, changing game logic and physics, and programming complex scenarios. It can be used to control many aspects of the game itself, such as parts of the AI, triggers, or changes in the level. The ] was the only game engine to use QuakeC. Following engines used ] game modules for customization written in ], and ] from ] on.


==Overview== == Overview ==
The QuakeC source to the original ] Quake game logic was published in 1996 and used as the basis for modifications like ] and others.<ref>{{cite web |url=http://www.satanicslaughter.com/news/?news_id=94 |title=QuakeC released |author=Lasse Lehtinen |date=1996-07-25 |work=Quake and QuakeWorld history |accessdate=2011-01-14}}</ref> QuakeC source code is compiled using a tool called ] into a ] kept in a file called <tt>progs.dat</tt>. The programmers of Quake modifications could then publish their <tt>progs.dat</tt> bytecode without revealing their source code. Most Quake mods were published this way. The QuakeC source to the original ] ''Quake'' game logic was published in 1996 and used as the basis for modifications like ] and others.<ref>{{cite web |url=http://www.satanicslaughter.com/news/?news_id=94 |title=QuakeC released |author=Lasse Lehtinen |date=1996-07-25 |work=Quake and QuakeWorld history |access-date=2011-01-14}}</ref> QuakeC source code is compiled using a tool called ] into a ] kept in a file called {{mono|progs.dat}}. The programmers of ''Quake'' modifications could then publish their {{mono|progs.dat}} bytecode without revealing their source code. Most ''Quake'' mods were published this way.


QuakeC allowed the ] to dominate the direction of the ] genre. Thanks to Carmack's idea of extending computer game life by adding unlimited expandability (extensibility already played a big role in ]), an enormous ] community of gamers and programmers alike has arisen and many modern ] games are extensible in some form.{{Citation needed|date=March 2009}} QuakeC allowed the ] to dominate the direction of the ] genre.{{CN|date=April 2020}} Thanks to Carmack's idea of extending video game life by adding unlimited expandability (extensibility already played a big role in '']''), an enormous Internet community of gamers and programmers alike has arisen and many modern multiplayer games are extensible in some form.{{Citation needed|date=March 2009}}


QuakeC is known as interpreted because as ''Quake'' runs, it is continually interpreting the progs.dat file.<ref>{{cite web |url=http://www.bluesnews.com/guide/quakec2.htm |title=Quake C Basics |author=Andrew Wu |access-date=2013-04-06}}</ref>
==Limitations==

== Limitations and subsequent solutions ==
The ] of QuakeC is based on that of the ], explaining its name, but it does not support the implementation of new types, structures, arrays, or any kind of referencing other than the "entity" type (which is always a reference). QuakeC also suffers from the fact that many built-in functions (functions prototyped in the QuakeC code but actually defined within the game engine and written in C) return strings in a temporary string buffer, which can only hold one string at any given time. In other words, a construct such as The ] of QuakeC is based on that of the ], explaining its name, but it does not support the implementation of new types, structures, arrays, or any kind of referencing other than the "entity" type (which is always a reference). QuakeC also suffers from the fact that many built-in functions (functions prototyped in the QuakeC code but actually defined within the game engine and written in C) return strings in a temporary string buffer, which can only hold one string at any given time. In other words, a construct such as


:<code>SomeFunction (ftos (num1), ftos (num2));</code> :<code>SomeFunction (ftos (num1), ftos (num2));</code>


will fail because the second call to ftos (which converts a floating-point value to a string) overwrites the string returned by the first call before SomeFunction can do something with it. QuakeC does not contain any string handling functions or file handling functions, which were simply not needed by the original game. will fail because the second call to <code>ftos</code> (which converts a floating-point value to a string) overwrites the string returned by the first call before SomeFunction can do something with it. QuakeC does not contain any string handling functions or file handling functions, which were simply not needed by the original game.


Most computer games at the time had their game logic written in plain C/C++ and ] into the executable, which is faster. However, this makes it harder for the community to create ] and it makes the process of ] the game to another platform (such as ]) more costly. Most video games at the time had their game logic written in plain C/C++ and ] into the executable, which is faster. However, this makes it harder for the community to create ] and it makes the process of ] the game to another platform (such as ]) more costly.


Despite its advantages, the concept of implementing the game logic in a separate scripting language and writing an ] for it was soon dropped (even by ] who had implemented this concept) because of the overall inflexibility of an interpreted language,<ref>{{cite web |last=Carmack |first=John |authorlink=John Carmack |title=Here is a technical issue to be discussed |url=http://www.team5150.com/~andrew/carmack/johnc_plan_1997.html#d19970313 |date=13 March 1997 |work=] |publisher=] |accessdate=20 August 2009}}</ref> the increasingly complex game logic and the fact that the game logic could be packaged into a native ] whose source code could be released to the mod community. Despite its advantages, the choice of implementing game logic using a custom scripting language and ] was dropped from the next generation ] in favor of compiled ] code due to the overall inflexibility of QuakeC, the increasingly complex game logic, the performance to be gained by packaging game logic into a native ], and the advantage of leveraging an already established programming language's community, tools, educational materials, and documentation.<ref>{{cite web |last=Carmack |first=John |author-link=John Carmack |title=Here is a technical issue to be discussed, Pg.18 |url=http://fabiensanglard.net/fd_proxy/doom3/pdfs/johnc-plan_1997.pdf#page=19 |date=13 March 1997 |work=] |publisher=] |access-date=5 November 2018}}</ref>


Distributing native code created new security and portability concerns. QuakeC bytecode afforded little opportunity for mischief, while native code has access to the whole machine. QuakeC bytecode also worked on any machine that could run Quake. Compiling to native code added an additional barrier to entry for novice mod developers, because they were being asked to set up a more complicated ]. The eventual solution, implemented by the ], was to combine the advantages of original QuakeC with the advantages of compiling C to native code. The ] was extended to compile standard C into bytecode, which could be interpreted by a ] in a manner similar to QuakeC. This addressed the security, portability, and tool chain problems, but lost the performance advantage of native code. That was solved by further compiling the bytecode into native code at run time on supported machines.<ref>{{cite web |last=Carmack |first=John |author-link=John Carmack |title=Jul 24, 1999, Pg.54 |url=http://fabiensanglard.net/fd_proxy/doom3/pdfs/johnc-plan_1999.pdf#page=54 |date=24 July 1999 |work=] |publisher=] |access-date=5 November 2018}}</ref>
⚫ ==Modified compilers and language extensions==
⚫ As is their custom to do with nearly everything they make, ] released the source of ], their QuakeC compiler, along with the original QuakeC code in 1996. Modified versions soon sprung up, including Jonathan Roy's ] and Ryan "FrikaC" Smith's ]. These added functionality, optimizations, and compiling speed boosts.


⚫ == Modified compilers and language extensions ==
⚫ In 1999 when ] released the code from Quake's engine under the ], the workings of the bytecode interpreter were examined and new QuakeC compilers were released, such as J.P. Grossman's ] and a new version of FrikQCC. These compilers took advantage of newly discovered features in a backwards-compatible way so that the bytecode could still be properly interpreted by unmodified Quake engines. New features include arrays, pointers, integers, for loops and string manipulation.
A decompiler and a recompiler were released by ] (called <code>DEACC</code> and <code>REACC</code> respectively). These programs were made through the process of ], and were most likely published before the release of <code>qcc</code>.<ref>{{Cite web|url=http://users.yknet.yk.ca/dmckay/qmap/inter.html|title=Interview with Armin Rigo - Feb. 12th 1997|date=April 30, 1997|archive-url=https://web.archive.org/web/19970430160107/http://users.yknet.yk.ca/dmckay/qmap/inter.html|archive-date=1997-04-30}}</ref>


⚫ ] released the source of <code>qcc</code>, their QuakeC compiler, along with the original QuakeC code in 1996. Modified versions soon sprung up, including Jonathan Roy's <code>fastqcc</code> and Ryan "FrikaC" Smith's ]. These added functionality, optimizations, and compiling speed boosts.
⚫ With the Quake engine source code now able to be changed, further features were added to QuakeC in the form of new builtin functions. Features long yearned for by QuakeC coders finally reached realization as QuakeC now had file and string handling functions, enlarged string buffers, more math functions, and so on. However, programmers taking advantage of these changes lost backwards compatibility with the unmodified Quake engine.


⚫ In 1999, when id Software released the code from Quake's engine under the ] (GPL), the workings of the bytecode interpreter were examined and new QuakeC compilers were released, such as J.P. Grossman's <code>qccx</code> and a new version of FrikQCC. These compilers took advantage of newly discovered features in a backwards-compatible way so that the bytecode could still be properly interpreted by unmodified Quake engines. New features include arrays, pointers, integers, for loops and string manipulation.
⚫ ==See also==


⚫ With the ''Quake'' engine source code now able to be changed, further features were added to QuakeC in the form of new built-in functions. Features long yearned for by QuakeC coders finally reached realization as QuakeC now had file and string handling functions, enlarged string buffers, more math functions, and so on. However, programmers taking advantage of these changes lost backwards compatibility with the unmodified Quake engine.
⚫ *]


'']'' since version 0.7 uses the compiler.<ref>{{cite web| url = http://www.xonotic.org/2013/06/xonotic-0-7-release/| title = Xonotic 0.7 Release}}</ref>
⚫ ==References==

== Client-side QuakeC ==
Some enhanced ''Quake'' engines (notably ] and FTEQW){{clarify|What is FTEQW?|date=July 2021}} have support for an extension of regular QuakeC (now commonly referred to as server-side QuakeC) that allows client-side-only scripting of the ''Quake'' engine, also abbreviated as CSQC (client-side QuakeC). This is especially useful for GUIs, HUDs{{Clarify|reason=What do these letters mean?|date=August 2021}} and any visually heavy effects that do not need to be simulated on the server and transferred over the network.<ref>{{Cite web|url=http://www.quakewiki.net/darkplaces-wiki/client-side-quakec/|title=Client-Side QuakeC|website=QuakeWiki|date=30 September 2012 |access-date=2016-11-16}}</ref>

⚫ == See also ==
⚫ * ]
* ]
⚫ * ]

⚫ == References ==
{{reflist}} {{reflist}}


== External links == == External links ==
* *
* *
* *
*
*
* *
* *
*


{{Quake}} {{Quake}}
Line 58: Line 68:
{{DEFAULTSORT:Quakec}} {{DEFAULTSORT:Quakec}}
] ]
] ]
]
] ]
]

]
]
]
]
⚫ ]
]
]
]

Latest revision as of 13:48, 10 December 2024

Compiled language
QuakeC
Paradigmimperative (procedural), structured
Designed byJohn Carmack
Developerid Software
First appeared1996
Typing disciplinestatic, strong
Major implementations
Quake C Compiler, FastQCC, FTEQCC, QCCx, GMQCC
Influenced by
C

QuakeC is a compiled language developed in 1996 by John Carmack of id Software to program parts of the video game Quake. Using QuakeC, a programmer is able to customize Quake to great extents by adding weapons, changing game logic and physics, and programming complex scenarios. It can be used to control many aspects of the game itself, such as parts of the AI, triggers, or changes in the level. The Quake engine was the only game engine to use QuakeC. Following engines used DLL game modules for customization written in C, and C++ from id Tech 4 on.

Overview

The QuakeC source to the original id Software Quake game logic was published in 1996 and used as the basis for modifications like capture the flag and others. QuakeC source code is compiled using a tool called qcc into a bytecode kept in a file called progs.dat. The programmers of Quake modifications could then publish their progs.dat bytecode without revealing their source code. Most Quake mods were published this way.

QuakeC allowed the Quake engine to dominate the direction of the first-person shooter genre. Thanks to Carmack's idea of extending video game life by adding unlimited expandability (extensibility already played a big role in Doom), an enormous Internet community of gamers and programmers alike has arisen and many modern multiplayer games are extensible in some form.

QuakeC is known as interpreted because as Quake runs, it is continually interpreting the progs.dat file.

Limitations and subsequent solutions

The syntax of QuakeC is based on that of the C programming language, explaining its name, but it does not support the implementation of new types, structures, arrays, or any kind of referencing other than the "entity" type (which is always a reference). QuakeC also suffers from the fact that many built-in functions (functions prototyped in the QuakeC code but actually defined within the game engine and written in C) return strings in a temporary string buffer, which can only hold one string at any given time. In other words, a construct such as

SomeFunction (ftos (num1), ftos (num2));

will fail because the second call to ftos (which converts a floating-point value to a string) overwrites the string returned by the first call before SomeFunction can do something with it. QuakeC does not contain any string handling functions or file handling functions, which were simply not needed by the original game.

Most video games at the time had their game logic written in plain C/C++ and compiled into the executable, which is faster. However, this makes it harder for the community to create mods and it makes the process of porting the game to another platform (such as Linux) more costly.

Despite its advantages, the choice of implementing game logic using a custom scripting language and interpreter was dropped from the next generation Quake II engine in favor of compiled C code due to the overall inflexibility of QuakeC, the increasingly complex game logic, the performance to be gained by packaging game logic into a native dynamic link library, and the advantage of leveraging an already established programming language's community, tools, educational materials, and documentation.

Distributing native code created new security and portability concerns. QuakeC bytecode afforded little opportunity for mischief, while native code has access to the whole machine. QuakeC bytecode also worked on any machine that could run Quake. Compiling to native code added an additional barrier to entry for novice mod developers, because they were being asked to set up a more complicated programming environment. The eventual solution, implemented by the Quake III engine, was to combine the advantages of original QuakeC with the advantages of compiling C to native code. The lcc C compiler was extended to compile standard C into bytecode, which could be interpreted by a virtual machine in a manner similar to QuakeC. This addressed the security, portability, and tool chain problems, but lost the performance advantage of native code. That was solved by further compiling the bytecode into native code at run time on supported machines.

Modified compilers and language extensions

A decompiler and a recompiler were released by Armin Rigo (called DEACC and REACC respectively). These programs were made through the process of reverse engineering, and were most likely published before the release of qcc.

id Software released the source of qcc, their QuakeC compiler, along with the original QuakeC code in 1996. Modified versions soon sprung up, including Jonathan Roy's fastqcc and Ryan "FrikaC" Smith's FrikQCC. These added functionality, optimizations, and compiling speed boosts.

In 1999, when id Software released the code from Quake's engine under the GNU General Public License (GPL), the workings of the bytecode interpreter were examined and new QuakeC compilers were released, such as J.P. Grossman's qccx and a new version of FrikQCC. These compilers took advantage of newly discovered features in a backwards-compatible way so that the bytecode could still be properly interpreted by unmodified Quake engines. New features include arrays, pointers, integers, for loops and string manipulation.

With the Quake engine source code now able to be changed, further features were added to QuakeC in the form of new built-in functions. Features long yearned for by QuakeC coders finally reached realization as QuakeC now had file and string handling functions, enlarged string buffers, more math functions, and so on. However, programmers taking advantage of these changes lost backwards compatibility with the unmodified Quake engine.

Xonotic since version 0.7 uses the gmqcc compiler.

Client-side QuakeC

Some enhanced Quake engines (notably DarkPlaces and FTEQW) have support for an extension of regular QuakeC (now commonly referred to as server-side QuakeC) that allows client-side-only scripting of the Quake engine, also abbreviated as CSQC (client-side QuakeC). This is especially useful for GUIs, HUDs and any visually heavy effects that do not need to be simulated on the server and transferred over the network.

See also

References

  1. Lasse Lehtinen (1996-07-25). "QuakeC released". Quake and QuakeWorld history. Retrieved 2011-01-14.
  2. Andrew Wu. "Quake C Basics". Retrieved 2013-04-06.
  3. Carmack, John (13 March 1997). "Here is a technical issue to be discussed, Pg.18" (PDF). .plan. id Software. Retrieved 5 November 2018.
  4. Carmack, John (24 July 1999). "Jul 24, 1999, Pg.54" (PDF). .plan. id Software. Retrieved 5 November 2018.
  5. "Interview with Armin Rigo - Feb. 12th 1997". April 30, 1997. Archived from the original on 1997-04-30.
  6. "Xonotic 0.7 Release".
  7. "Client-Side QuakeC". QuakeWiki. 30 September 2012. Retrieved 2016-11-16.

External links

Quake series
Games
People
Machinima
Mods
Quake
Quake II
Quake III
Professional
players
Technology
id Tech
Other
Related
Categories: