Copy Link
Add to Bookmark
Report
Quake Editing Digest Volume 1 : Number 9
quake-editing-digest Friday, 15 March 1996 Volume 01 : Number 009
The Gimp!
Map Conversion Utility, Anyone?
One more file format suggestion
Re: One more file format suggestion
----------------------------------------------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Thu, 14 Mar 1996 10:54:14 +0100 (MET)
Subject: The Gimp!
In a flash of shallow inspiration, I wrote
> Start thinking "plug-ins" instead of node builder etc. :-).
Now here's your daily pointer:
http://www.xcf.berkeley.edu/~gimp/gimp.html
or use the image-intensive index page of this image conversion,
manipulation, and paint tool.
I recommend this to anybody who is thinking of some kinf of
Quake Construction/Developers Kit for Linux, be it for free
distribution or private use.
From a programmer's point of view, I am particularly interested
in the external module (plug-in) interface. If you think of
creating an editor or a frontend for tools, you should take a
close look at this. I will!
b.
P.S.: Peter Mattis, one of the authors, wrote one of the DOOM-style
rendering engines out there. See
http://www.csua.berkeley.edu/~petm/final.html
- -------------------------------------------------------------------
"Bring out the Gimp."
"The Gimp's sleepin'!"
"Guess you just have to go wake 'im up now won't you?"
- -------------------------------------------------------------------
------------------------------
From: Tom Wheeley <tomw@tsys.demon.co.uk>
Date: Wed, 13 Mar 96 19:14:16 GMT
Subject: Map Conversion Utility, Anyone?
In article <01BB10C5.66E97C00@descent.interplay.com> you write:
> In perusing the postings here, I've seen some discussions of homebrew Quake
> editors. If it hasn't been already, I'd like to suggest that a map
> conversion utility, which would convert existing DOOM maps to work with the
> Quake Deathmatch Test engine, might be a good first project rather than a
> full blown editor. My reasoning is as follows:
>
> We all know that the Quake data file formats are in a state of flux, so a
> full-blown editor would likely represent at least a not insignificant
> amount of wasted effort because the end result would not work with the
> next release of Quake. True, much of the investment in coding will be
> reusable with little or no changes in the "Quake Final" editors. However,
> the same is true for the routines developed for the conversion utility.
Not really. The only bits which are likely to change are 90% of the conv.
utility -- as it is the file formats and BSP generation which are most likely
to change. Quake will still be a 3D game, needing a 3D editor.
BTW, from the Quake specs it seems that the nodes etc of the BSP file are
reasonably well understood (well, documented, anyway..) So, how far has
anyone got with writing a `node builder'?
> Reaction? Comments?
I think that such a tool, although encouraging levels which do not make use
of the Quake engine, would be very popular and useful. (You could do a
template in a Doom editor, then change it later in a beta Quake editor)
> begin 600 WINMAIL.DAT
> M>)\^(@H2`0:0' `$```````!``$``0>0!@`(````Y 0```````#H``$-@ 0`
wtf?!
.splitbung
- --
* TQ 1.0 * 101 Slogans for Quake
61. Quake: To Boldly Go Where No Hammer Has Gone Before
------------------------------
From: Lauri Alanko <mivars@cc.helsinki.fi>
Date: Thu, 14 Mar 1996 17:23:03 +0200 (EET)
Subject: One more file format suggestion
Hello! As there has been talk about a file format suitable for distributing
levels etc., here are some of my thoughts about this.
The general problem seems to be that there are many different pieces of data
that can be modified, but there are only a few forms in which Quake will
read this data. Therefore a system is needed which converts editable and
distributable pieces of data into Quake-readable pieces of data.
It is my thought that there is no reason to limit this system merely to maps
and textures. Couldn't there be a general resource location system which
allows the "statical linking" of almost anything that people are likely to
modify?
So, basically, when someone distributes an add-on, be it a level, a model
texture or whatever, it should contain information about:
1. What should be created from these add-ons (eg. a .bsp level file)
2. What else is required to create them (eg. textures, entities)
In addition, the end-user should supply information about:
3. Where the required "libraries" are located (eg. a .pak file)
4. How all the things are joined to create the final product (eg. qube 2.0)
The end-user should have a reference table where the "linker" can find
the locations of the pieces of data needed to create the final product. This
would be a text file, easily editable. Something along these lines...
texture water { //Grab the texture straight from the .pak file
pak id1.pak
bspfile maps/test2.bsp //This is looked up in the packfile now.
bspentry 02 //This would probably be the default anyway...
mipname *04mwat2
}
texture water { //The mipmap is composed from bitmaps
mip1 maps/textures/_04mwat2.bmp //in the linking process. Slow but
mip2 maps/textures/_04mwat2.bm2 //handy if one is editing the texture
mip4 maps/textures/_04mwat2.bm4 //all the time.
mip8 maps/textures/_04mwat2.bm8
}
texture water { //This would maybe be the most common way
bspfile maps/test2.bsp //to do it, grab the texture from a level.
mipname *04mwat2
}
Then when the new level is distributed (probably in some format that
includes all the visilist calculations), there is a header or something
which tells to use the symbolic texture name "water" in certain areas. When
the final map is "linked", the end result will be a level where water looks
like whatever the _end user_ has customized it to look like.
This kind of "resource locating" could be used for anything else. A level
could contain a symbolic entity "ogre", which defaults to progs/ogre.mdl,
but could be redefined by the end user to contrib/progs/bgates.mdl.
Or someone might just distribute an entity list and tell in the header
which map it is for.
A system this flexible would have advantages. Given proper configuration,
it should be possible to create a new 2 meg level from a 50k distribution
file with a single command. Also, the end user could (but wouldn't have to)
change the outlook of the distributed level by simply changing some
definitions and relinking. No need for Qeutex.
Okay, there are disadvantages, too. The linking process could take a
lot of time. If all the end user's textures are in .bmp files it may take a
while to create proper .bsp entries from them. But the end user _could_ have
everything neatly "precompiled" in a .pak file, in which case it shouldn't
take too long just to copy the necessary entries and add a few from the
distribution. In any case the end user could have his files in whatever
format he prefers.
This would require a very sophisticated "linker" program, which would
read the end user's reference table and invoke the proper tools to change
pieces of data from one format to another (eg. a model texture and a full
model into another model where the texture has been replaced).
And finally, any of this will be damn near useless until the file formats
that Quake will support have been confirmed.
So my idea is a system where every conceivable piece of data could be
identified and automatically put in the right place to compose the final
product. Silly me.
Comments? How much of this would be conceivable?
Lauri Alanko
------------------------------
From: "Brian K. Martin" <brian@phyast.pitt.edu>
Date: Thu, 14 Mar 1996 13:01:12 -0500 (EST)
Subject: Re: One more file format suggestion
I think this talk may not be very useful at this exact moment.
I'm not trying to sound like a smart ass, but I would guess
that id will prolly have some type of load commands on the consol
which allow one to add different maps while still using the standard
textures. I hope they don't continue to have the maps and textures
together. If they do, then we will surely need to think of something.
(several good ideas so far though).
brian
------------------------------
End of quake-editing-digest V1 #9
*********************************
