QuakeEd Source Overview
QuakeEd Source Overview
Here you will find the source files of QuakeEd as released by John Carmack. Quote: "I will probably release the source code for the editor, but the bulk of it is in objective-c, which is likely of little use to most people. Some of the techincal stuff dealing with polyhedron operations may be usefull." I tried to sort it out a bit, but I have never used ObjectiveC or NEXTSTEP - if in doubt, look at the source.
There are several pages related to this sources:
QuakeEd Main programDisplay Updating, Region Modification, BSP Processing, other methods. The QuakeEd_main.m is automatically generated by the Interface Builder and not very useful.
As far as the classes are concerend, the English.proj/QUakeEd.nib/data.classes file provides a pretty good overview of classes and methods, that will come handy for porting. The following list needs to be reworked later, when I have both the time and a clue what each module actually does.
Functions to turn Planes into groups of Faces, Interaction, Drawing, Single and Multiple Brush Actions, Brush Substraction. Polyhedral operations that are important for interactive editing.
An Entity os a list of Brushes, with additional Key/Value information. I guess the KeyPairView is related to displaying trigger/target relations, but do not bet on it.
A Map is a list of Entity objects.
Inspectors are spawned by QuakeEd on request and handled by a control module, from the looks of it. There are four inspectors in the screenshots, two handling general Preferences and Project Info settings, one is a Texture Palette Browser, and one an Entity Inspector. There are View modules related to the latter. There are Help, Settings, and Output inspectors defined in the control module, the Project is not included. Strangely, a DoomEdIcon is referenced.
Handling of NeXT defaults files, and of Editing Project files.
QuakeEd has three different views: a 3D camera mode, a top-down XY view, and a Z view. The camera view includes transformations, key and mosue control. The Z-plane selected controls display in the XY view, again including mouse usage. Different drawing methods again with user interaction in the XY view module.
Related: Definition of View Frustrum, possibly. Seems to use Display Postscript functions. Rendering functions are used in CameraView, SetBrush, XYView, and provided in a library for texturing and flat rasterization. This might be the texture rendering code John Carmack called "crap", and is supposed to be replaced by Mesa/OpenGL usage.I am not sure whether the Dictionary lookups are used for Entity key/value pairs only; they might be used for any kind of string/value operations, or even WAD assmebly.
There is a math library of basic vector operations, and a command library with several I/O and other functions.
The UserPath routines are written by Bruce Blumberg of NeXT and freely distributable. They are used to speed up Display Postscript based rendering, and, in this regard, NeXT-specific. In the Postscript Language, a path deinfes shapes, trajectories, and regions of all sorts. User paths are self-contained objects and can be cached for repeated use. See Adobe Postscript Reference Manual for details.
There are some leftovers. You could safely ignore
Brush.h, as it is not referenced
anywhere. The same is true for all files in the
English.lproj/Info.nib/ directory. I have
no clue how the
help.txt
has been included in the
English.lproj/QuakeEd.nib/data.nib file
in first place using the Interface Builder, but as
it is in there you do not need it anymore.
There are two different issues: porting QuakeEd using a compiler suited for ObjectiveC, and using NEXTSTEP, as well as porting QuakeEd to C++, using a library like Mesa or OpenGL, and a windows toolkit like wxWindows. Quoting from a John Carmack mail reply: "We may be porting it to openstep for windows and releasing it as a seperate shareware product if we can get a reasonable royalty rate from NeXT." In the meantime, it seems that there will never be an OpenStep port of QuakeEd, and the id development tools will be written for NT from now on.
This application was really not a very good fit for NEXTSTEP. The display postscript model fundamentally doesn't fit very well with what we need here -- if you run in an 8 bit color mode, the line drawing runs at an ok speed, but the texture view goes half the speed it should as it dithers from 24 bit color down to 8 bit. If you run in 24 bit color mode, you get less screen real estate and significantly slower line drawing as a 3 megabyte XY view is flushed. Sigh. If anyone does actually run this on NEXTSTEP be advised that you want a fast machine."
I posted this info in a recent mail:
Quoting John Carmack: "QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an implementation of the OPENSTEP spec. I haven't had time to port it to openstep yet, but it looks like it will take a little effort. NeXT has tools in NS 4.0 to help, but it still isn't automatic."
The GNU GCC (and possibly DJGPP) supports ObjectiveC, and GNUstep is free software, see
ObjectiveC and NextStep references will come handy now, see
By the way, on the NeXT the use of C++ objects within ObjectiveC
source seems to be possible, and there is an
extern "Objective-C"
expression supported with C++ source. However, this is not available
with Linux/GCC.
