Difference between revisions of "Reload hack"
From DoomWiki.org
| [checked revision] | [checked revision] |
(embed youtube video) |
m (Formalize reference, +wls) |
||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{youtube|zQqwPeYh8mk|The reload hack being demonstrated, with [[Vanilla Doom]] and [[Edmap]] running in separate [[wikipedia:DOSBox|DOSBox]] instances.}} | {{youtube|zQqwPeYh8mk|The reload hack being demonstrated, with [[Vanilla Doom]] and [[Edmap]] running in separate [[wikipedia:DOSBox|DOSBox]] instances.}} | ||
| − | The '''reload hack''' is an undocumented feature of [[ | + | The '''reload hack''' is an undocumented feature of [[vanilla Doom]] that allows rapid turnaround for level authors to test their changes without needing to completely restart the game. |
| − | == | + | == Purpose == |
| − | Doom's levels were developed on | + | Doom's levels were developed on {{wp|NeXT|NeXT workstations}} using the [[DoomEd]] editor, while the game itself ran under {{wp|MS-DOS}} on PCs. On early '90s hardware, starting up the game on a 486 class machine could take a long time (up to 30 seconds or more if using a 33 MHz processor); extensive pre-processing is performed on startup to prepare texture data for use in the renderer. |
| − | This makes the development cycle (Make change; | + | This makes the development cycle (Make change; rebuild [[WAD]]; restart game) quite expensive in terms of time. The reload hack was therefore implemented to reduce the time required to test out a level change. |
== Usage == | == Usage == | ||
| − | The well-known -file command line parameter can be used to load a PWAD file for play, typically containing a third-party level. Adding a tilde (~) before the filename signifies that the reload hack should be | + | The well-known {{c|-file}} [[command line parameter]] can be used to load a [[PWAD]] file for play, typically containing a third-party level. Adding a tilde (~) before the filename signifies that the reload hack should be applied to that file. For example: |
| − | + | doom2.exe -file ~reload.wad | |
| − | will load | + | will load {{c|reload.wad}}, but the WAD file will be reloaded each time the level is restarted. So if {{c|reload.wad}} is changed using an external editing tool, the changes can be immediately seen by using the IDCLEV level warp [[Doom cheat codes|cheat code]], or by restarting the level through dying or any other normal means. |
| − | Because of the nature of the hack, not all changes to the WAD will have an effect. For example, texture changes will have no effect as they are precomputed on startup. | + | Because of the nature of the hack, not all changes to the WAD file will have an effect. For example, texture changes will have no effect as they are precomputed on startup. A comment in the WAD code ([[Doom source code files|w_wad.c]]) where the reload hack is implemented refers to it as "a fragile hack". |
| − | It is likely that | + | It is likely that [[id Software]]'s developers used the hack with a NeXTStep workstation and PC in concert, with the PC loading PWADs stored on a network drive accessed in parallel by a NeXT workstation. This is evidenced by the {{c|-wart}} parameter that loads maps from the directory {{c|e:\doom\cdata}} and automatically prepends the tilde to enable the reload hack - drive E: may have been a network mount present on the Doom development machines. |
| − | == | + | == History == |
| − | + | In April 1994, [[Dave Taylor]] posted a company status update to Doom [[Usenet|newsgroups]] that mentioned that the upcoming version 1.3 would include "a new map reload feature for the map editor types out there so that you can test a level immediately after developing it without restarting."{{cite web|author=[[Dave Taylor|Taylor, Dave]]|title=idNews: Petition & Whatsup|url=http://doomgate.gamers.org/pub/archives/idNews/idNews11_work1.3_ports_petition |publication=alt.games.doom, comp.sys.ibm.pc.games.action|publishdate=12 Apr 1994 11:31:38 -0500|accessdate=30 November 2018}} Unfortunately, either id Software forgot to properly document this new feature, or else knowledge of it was lost, as it was only rediscovered following the [[Doom source code]] release in 1997. This is unfortunate because the hack would have been useful on the hardware of the time, and usable with a {{wp|Computer multitasking|multitasking OS}} capable of running Doom (such as {{wp|Windows 95}} or {{wp|OS/2}}). | |
| − | On modern hardware, CPUs are fast enough that the startup pre-processing time is negligible, | + | On modern hardware, CPUs are fast enough that the startup pre-processing time is negligible, negating most of the benefit of the hack. |
== External links == | == External links == | ||
* [https://www.youtube.com/watch?v=zQqwPeYh8mk Video showing the reload hack in action] | * [https://www.youtube.com/watch?v=zQqwPeYh8mk Video showing the reload hack in action] | ||
| + | |||
| + | ==References== | ||
| + | <references /> | ||
[[Category:Doom engine]] | [[Category:Doom engine]] | ||
Revision as of 21:31, 30 November 2018
The reload hack is an undocumented feature of vanilla Doom that allows rapid turnaround for level authors to test their changes without needing to completely restart the game.
Purpose
Doom's levels were developed on NeXT workstations using the DoomEd editor, while the game itself ran under MS-DOS on PCs. On early '90s hardware, starting up the game on a 486 class machine could take a long time (up to 30 seconds or more if using a 33 MHz processor); extensive pre-processing is performed on startup to prepare texture data for use in the renderer.
This makes the development cycle (Make change; rebuild WAD; restart game) quite expensive in terms of time. The reload hack was therefore implemented to reduce the time required to test out a level change.
Usage
The well-known -file command line parameter can be used to load a PWAD file for play, typically containing a third-party level. Adding a tilde (~) before the filename signifies that the reload hack should be applied to that file. For example:
doom2.exe -file ~reload.wad
will load reload.wad, but the WAD file will be reloaded each time the level is restarted. So if reload.wad is changed using an external editing tool, the changes can be immediately seen by using the IDCLEV level warp cheat code, or by restarting the level through dying or any other normal means.
Because of the nature of the hack, not all changes to the WAD file will have an effect. For example, texture changes will have no effect as they are precomputed on startup. A comment in the WAD code (w_wad.c) where the reload hack is implemented refers to it as "a fragile hack".
It is likely that id Software's developers used the hack with a NeXTStep workstation and PC in concert, with the PC loading PWADs stored on a network drive accessed in parallel by a NeXT workstation. This is evidenced by the -wart parameter that loads maps from the directory e:\doom\cdata and automatically prepends the tilde to enable the reload hack - drive E: may have been a network mount present on the Doom development machines.
History
In April 1994, Dave Taylor posted a company status update to Doom newsgroups that mentioned that the upcoming version 1.3 would include "a new map reload feature for the map editor types out there so that you can test a level immediately after developing it without restarting."[1] Unfortunately, either id Software forgot to properly document this new feature, or else knowledge of it was lost, as it was only rediscovered following the Doom source code release in 1997. This is unfortunate because the hack would have been useful on the hardware of the time, and usable with a multitasking OS capable of running Doom (such as Windows 95 or OS/2).
On modern hardware, CPUs are fast enough that the startup pre-processing time is negligible, negating most of the benefit of the hack.
External links
References
- ↑ Taylor, Dave (12 April 1994). "idNews: Petition & Whatsup." alt.games.doom, comp.sys.ibm.pc.games.action. Retrieved 30 November 2018.
