 |
|
You are here: Foswiki>WorldFoundry Web>WorldFoundryTechnicalNotes (07 Oct 2002, MrLin;)Edit Attach
This is horribly formatted, but the important thing at this point is to make the info available...
WORLD FOUNDRY PROGRAMMERS' GUIDE Contents
'> of which can be separately tested, is sound. Can each library also
'> be used separately? Would it make sense to make separate use of
'> individual libraries?
As much as possible, I have tried to make the libraries be a vertical stack of dependencies, with pigsys (damn I need to rename that) at the bottom, and the game at the top. They pretty much follow the order given in /wfsource/source/README. (oops, pigsys and HAL should be reversed in README, this is because I wrote HAL, someone else wrote pigsys, and we fought over who should be at the bottom, and he won). I want to take pigsys, streams and cpplib and release them as a base toolkit suitable for any project (where exceptions aren't needed). They provide good assertion macros, validation, debugging streams, binary IO streams, platform independence, library independence. (If you throw HAL in you get platform independent task switching and timers which, ironicaly are not used by WF (the memory manegment is, however). Above the core I would like the libraries to be fairly independent, but they still stack, gfx needs iff and math, for example, and anim needs gfx. I intend to make a diagram of the relationship of all of the libraries, just haven't taken the time to find a package to do it in. (I might look at the stuff you used for your book). Most of the tools use a sub-set of the libraries, so they demonstrate how easy it is to link against them. Any project I start in the future will most certainly use at least the core libraries. (I am thinking of writting a package to transport MIDI over TCP/IP, since I recently aquired a bunch of cheap 133Mhz K5 machines to use as synthesizers).
'> And even though I don't have 3DS, you do, right? So why can't
'> you just compile all of the sample levels on the WF FTP server
'> into an asset file which can then be run, even if only under
'> Windows? Am I forgetting something?
Sorry, we have several boring, 'doesn't really demonstrate the engine' levels. What we don't have is anything like the dozen or so levels which were made for Velocity, which were full-fledged, playable levels, with goals, and enemies, etc. (We do have a promotional video we made, I should see if I can get that into a format suitable for downloading). I want something where a person downloads the executable with a level, plays it, has fun, says 'This is cool, I want to work on this!'. Or 'I want to make a level with this'.
'> World Foundry, including level-building tools, is available on Linux?
'> Half a year? One year? Two years?
Well, that is a tough question. Currently I am the only person really working on it (I have received a few patches from others). I see it as 2 projects: port the engine, and port the production environment. The engine is running, but needs lots of work. The production pathway used 3dsMax as its level layout tool (max and other 3d packages were used for geometry creation), so the first step is to choose a 3d package to use on linux. I am currently leaning towards extreme wave. The windows version had a max plug-in which did the level exporting, much of the code in it is not max specific, last year we decided it would be much cleaner if the exporter simply wrote out an intermediate file, and have a command line tool do the the level processing. I am still working on this (I have a max exporter which produces an iff file with all the object data in it, and am nearing completion on the command line version of the level converter). Once this is done, all that is left to have a functional pathway is the attributes editor in the modeler, and the exporter. At my current rate, I imagine I will have something working in 6 months or so. Now if I get some help, that could probably be shorted quite a bit./makefile: builds that
library.
Includes wfsource/Makefile.env and
wfsource/source/Makefile.lib
wfsource/Makefile.env: defines all the build variables and compiler
options
Includes: wfsource/Makefile.<targetname, i.e. linux, win, psx)
wfsource/Makefile.bld
wfsource/Makefile.rul
wfsource/Makefile.: platform specific definitions, name of
compiler, name of shell commands (rename, delete, etc).
wfsource/Makefile.bld: implements easy build names, for example:
buildmode=release is all
optimizations on, assertions off, debug streaming off, etc; where
buildmode=debug is
no optimizations, assertions on, debug streamming on, etc. This
allows definition of
new buildmodes easily (some are built on others, for example,
buildmode=tool is based
on buildmode=debug.
wfsource/Makefile.rul: make rules, defines how to build a .cc file, a
.asm file, etc.
wfsource/source/Makefile.lib: rule to build library file
Includes: wfsource/source/Makefile.test
wfsource/source/Makefile.print
wfsource/source/Makefile.test: rule for building test program for each
library
wfsource/source/Makefile.print: rule for dumping lots of variable
settings, used to debug the makefiles.
Sorry, I forgot VC has a GUI, these need to be set in the DOS shell,
i.e.: set RENDERER=gl set RENDERER_PIPELINE=software etc. I place all
of these in a batch file and execute the batch file before I try to
make (enclosed to make it easier).
'> other macro preprocessors can't do? What are its goals? What is its
'> purpose in this universe?
prep was started before I was much of an internet user (way back in 1994), so I didn't know about m4. However, looking at m4 now I don't like it. prep was written to get around limitations of the c preprocessor. Some of my design goals: Only ONE escape character (@, choosen because C doesn't use it). I hate having to escape half of the characters because they mean something to the preprocessor. Better macros: default parameters in macros (heavily used in the oas directory) (and, better than C++, the defaults don't have to go at the end, and you can specify param 1, default 2, param 3 (you just put two commas in a row)). Ability to have preprocessor commands in macro expansions Better expression handing. regular expression based search/replace. More powerfull macro execution: in prep you can define a macro during macro execution. This amounts to having variables "@define foo @e(foo+1)@t" will create a string which is numerically 1 larger than it was before (@e = evaulate expression, @t = terminate macro definition). stream oriented instead of line oriented. With a few exceptions, all prep commands can operate in the middle of a line (or the middle of a macro invocation). Written as a text input class. Prep can be used in any program to pre-process text (hand it a file to open, and call GetLine repeatedly to get processed text). Small. The code base is small enough to understand in just a few hours (I think). There is a word document on prep in the prep directory (prep.doc), I should convert it to html or something. It has grown to have looping and other sick things God did not intend a text preproces sor to have. shortcommings: Cryptic. Not well documented (sometimes I read the source when writting prep macros). Slow. Doesn't process text particularly fast (watch how long it takes to make in the oas directory). So, in conclusion, it does what WF needs it to do, but would need some cleanup before I would claim it was general purpose.
'> simpler, the better.
I am working on a file format for oad data when exported from a 3d package, it uses iff, but is fairly simple, mostly boils down to: name "attribute name" data "value" wrapped in chunks. Internally (before export, when you are using your attribute editor, you can use anything you want (but again, the easiest is just to store name,value for each field). '> 4) The underlying fundamental or important characteristics of an
'> attribute editor are not yet completely clear. It appears mainly
'> to be a type-attribute system, i.e. you choose an object-type for
'> the mesh, then depending on the type you get a list of valid
'> attributes for this type which you edit. Are there more fundamental
'> ideas which need to play a key role in the early design?
You are correct, the class type must be chosen first to establish what type of game object it is, which determines what attributes will be displayed. The only other key concept I can think of is that the interface is not hard coded (you don't know what attributes a 'Player' has when you compile the editor, you read that information from the oad file and construct a user interface on the fly for it (instead of laying out an attribute page, you just lay out a gui element for int, fixed, object reference, color picker, etc., then build stacks of them based on the oad data). '> 5) Are meshes really the only objects which need attributes? (I hope
'> so, though workarounds are always possible.) How about paths?
'> Anything else?
Yes, in World Foundry, you have to be an object to get data attached to you (so we have a special object, the "level" object, which contains any level-wide data we wish to encode (this object doesn't appear in the running level). Paths are something which happens to objects, so any object which has a path ought to export it when its position and rotation are exported. '> 6) This really isnt a problem but I will put it here - I need to
'> be careful about isolating dependencies on widget-set, system,
'> Blender, and my magic-X-encoding in separate classes, so that
'> the fundamental part of the system (type-attribute) can be
'> reused with other editors or other encoding schemes.
Agreed, I will try to supply something which already has full oad support so all you should need to do is provide user interface and blender stuff. If you make it able to run stand-alone (without blender), it can be the starting point for any other 3d packages attributes editor as well (I would get that done before attempting the blender integration).
'> generated 1 per object, are just temporary and thus not so
'> important. The real files are the .blend file containing the object
'> positions, and the one or more attributes files containing the
'> attributes for the objects. For now I will probably have one
'> attribute file per object and will investigate ways of reducing this
'> to one file containing all attributes for all objects (a simple
'> concatenated text file or something like a zip file using zlib),
'> which could conceivably even be bound into the .blend file if I find
'> the appropriate mechanism for doing so -- though everything in 1
'> file doesn't seem of paramount importance to me; two files seems
'> bearable. Two files is fine.
'>> (this is sort of a wart on our oad files, they list all of the data
'>> we wanted to control in addition to what max gave us, so they don't
'>> contain position, orientation, name, etc, even though all of those
'>> things get exported into the .lvl file (except the name, which is
'>> only used for object references)). When everything gets stable I
'>> want to re-think that a bit. > > Um, can't say I really follow -
'>> what part needs rethinking, what is > the problem? (But I agree
'>> with the part "rethink it when everything > gets stable"...)
Sorry. The .lvl file contains object position, object orientation, object bounding box, AND all of the oad data for that object. I think it would be cleaner if the oad data called for position, orientation, etc, so that the only object data in the .lvl file was the oad data (which would then INCLUDE position, etc). Not a priority. '> >> > Orientation: I just >> > finished extending the magic-X to be a
magic-coordinate system, >> >> > Path information: >> Paths are only used for objects which have a set motion (mostly for platform >> (sonic or mario) style games. Conveyor belts, or machinery. In WF they are stored >> as keyframes which we draw straight lines between, so we can't really follow curves >> very well (but it would be easy for someone to add a new position player to path to >> do it). So I would get everything else working first, then we can figure out paths. > > Thankfully (I just tried it) Blender can store and export polylines > as meshes (it can also convert curves into polylines), BUT these > polylines consist of tons of ... two-vertex edges, which is exactly > what I previously assumed was not allowable and thus could flag > the begin of my meta-data. But, don't panic, I can signal my > meta-data with a series of three (or 20, or 42) OVERLAPPING two-vertex > edges, which should definitely never occur in any geometry, even > in polylines, so the magic-X encoding will work for paths, as well. > > Anyway, let's not worry too much about paths now, I at least am 95% > sure it will work, so it's just an "implementation detail" which > we'll do later after the other stuff with boxes is working. '>> > I think we're getting close: object identity, arbitrary object
'>> > attributes, export of all objects with OID, position, and
'>> > orientation, and almost certainly path information too (once I
'>> > understand exactly how it works in WF). Anything else we need?
'>> > >> I believe that is all we use for level export (we will discuss
'>> > geometry >> export later, once we have a working level running
'>> > with boxes). > > So... what exactly do I need to export? I
'>> > imagine something like > the following... You click "export
'>> > level" in my little standlone > program. This sends the
'>> > keystrokes to blender to mark and export all > meshes. Then I
'>> > invoke a perl script (to be written) which parses > all the .obj
'>> > (exported videoscape) files, extracts the id, position, > and
'>> > orientation from the magic-X, finds the object id in the
'>> > attributes > file and finds the appropriate attributes. > > So
'>> > far, so good. (It doesn't have to be in perl, either, but it >
'>> > would probably be fastest to whip it up this way.) At this point
'>> > > I have all objects, their positions, orientations, and
'>> > attributes > (including the name, the object-ID is irrelevant to
'>> > external > users). > > In what form do you then need to access
'>> > this information? > Can I simply then write out some sort of a
'>> > simple text file > > OBJECTNAME=BLAHBLAH > POSITION=1.0,2.0,3.0 >
'>> > ORIENTATION_X=1.0,0.0,0.0 > ORIENTATION_Y=0.0,0.0,0.0 >
'>> > ORIENTATION_Z=0.0,0.0,0.0 > OBJECT_SPECIFIC_ATTRIB_1="my name is
'>> > joe" > OBJECT_SPECIFIC_ATTRIB_2="green" > END_OBJECT > >
'>> > OBJECTNAME=BLAHBLAH_2 > POSITION=9.0,9.0,9.0 >
'>> > ORIENTATION_X=0.0,0.0,0.0 > ORIENTATION_Y=0.0,1.0,0.0 >
'>> > ORIENTATION_Z=0.0,0.0,0.0 >
'>> > ANOTHER_OBJECT_SPECIFIC_ATTRIB=773.21; >
'>> > ANOTHER_OBJECT_SPECIFIC_ATTRIB_2="he said mount huh huh"; >
'>> > (courtesy of pole.oas, line 15
) > END_OBJECT > > which you
'>> > then parse into whatever form you need? Or should I output > IFF
'>> > at this point already? I've never done any IFF stuff, so don't >
'>> > necessarily want to slow up the whole development process by >
'>> > struggling with it if I don't have to...
Wow, that looks just like videoscape (I can't imagine why ;-). Have I got a bargain for you. What if I told you you could have the power of iff with the ease of use of text? All you have to do is produce a text file which iffcomp can read, and you can produce binary iff output. Now how much would you pay? (Doesn't matter, its free!). So, here is some sample output: '> I'm not a Microsoft Windows expert, but I play one at work. Though
'> Linux is my OS of choice, the reality of the marketplace for my main
'> employer dictates that we write software for M$win, so I have some
'> experience with Windows programming. Therefore it is conceivable
'> that I could start looking at the property editor now even if it
'> doesn't completely run yet. The main problem I foresee is that the
'> code is probably not yet compilable with any free compiler (Cygnus
'> gcc for windows), right? I don't have access to any non-free C++
'> compilers at the moment, and in fact have no need for anything other
'> than gcc.
Since it is based on the 3dsmax code, it is compiled with VC++ (you HAVE to use VC++ to do 3dsmax work). I don't care too much about having a working windows version, I just want to prove the rest of the code is working, it shouldn't take me too long to debug it (the source is in wfsource.tar.gz in source/attrib if you want to look at it. It hasn't been updated to read the new oad iff files, still reads the .oad binary files). '>> I decided I would have better luck promoting WF if there were
'>> better levels to show, so I am concentrating on getting a working
'>> windows release out there so that artists could have a chance of
'>> making some. If someone made a cool level showing off the
'>> capabilities of WF, I think it would start to take off. > > Sounds
'>> perfectly reasonable. However, don't forget that the sooner a >
'>> free (Linux, or at least non-3DS-dependent) GDK is available, the
'>> more > people will be able to develop levels. Yes, I am done
'>> working on the windows GDK (other than documentation and any
'>> support anyone needs).
'> If it's not too fancy, the attributes editor could conceivably run
'> under WINE, the Linux Windows emulator. Wine can run a surprising
'> number of native Windows binaries these days. In fact it can even
'> run Tomb Raider II with hardware acceleration (the Direct3D emuation
'> layer makes calls to Mesa). Pretty amazing, huh? gcc can also cross
'> compile for Windows, meaning the editor could even be compiled under
'> Linux if the source code is gcc-friendly.
Interesting idea, it most likely will work, but getting it to compile under gcc for windows might be more of a hassle than porting it to another gui toolkit under linux. I guess I will leave that up to you. (On second thought, I am sure it would be easier to change compilers than to change gui toolkits, as soon as I get it working I will test it on wine). '> I need to review our previous emails to understand the entire system
'> architecture again regarding levels and attributes, but assuming
'> that the attributes editor can run unchanged under Wine, then how
'> much additional work is needed to get a level editing environment up
'> and running with, say, blender? What type of file does the
'> standalone attributes editor read in, anyway? I am thinking along
'> these lines: Blender \ \ \ \ stand alone \ property editor my
'> magic-x / object ID encoding / \ / \ / \ / \ / some common file
'> format In other words, I lay out some cubes in Blender and write
'> only the most elementary of attribute information (type, name) into
'> some common file format using my already-established magic-X
'> encoding and blender remote-control via keystrokes. The standalone
'> property editor (running under Wine on Linux, for instance) would
'> run parallel as a separate program and would read in the file I just
'> wrote, and from there I could fill in the additional properties. In
'> other words (hey, there's that phrase again) I would just use
'> Blender and my remote-control system to help identify and position
'> objects in 3D space. Everything else would be specified through your
'> already-working (or almost-already-working) standlone property
'> editor, which could run under Wine on Linux. Is this chain of
'> reasoning tenable? If so, the main problem I see is the common file
'> format read by the existing standalone property editor. I guess
'> this is IFF? Or is it even uglier, being some sort of native 3DS
'> format? Sorry if you already covered this in a previous email, it's
'> all kind of foggy in my memory right now.
Yes, I think that can be made to work. There are actually two common file formats: the ObjectAttributeDescription (oad), which describes each field (name, etc), which is only changed by programmers (which the attribute editor reads but doesn't change) , and the data itself (oad data), which there is a copy of for each object, and is what the attribute editor edits. I intend both of these to be store in .iff files, vcurrently the oad is stored in a binary file (.oad) (although I have made the production pathway produce an .iff version as well), and the oad data is stored inside of 3dstudio max (although I have written an exporter which writes it out as .iff). So I have the .iff files, just not the code to use it (about 1/2 finished with a version of the level converter which uses the .iff files). Within a few days I will get back on that task. '> As for me, I enhanced the magic-X Blender encoding so that it also
'> works with paths (polylines) by using 4 overlapping edges at the
'> beginning to flag the start of the metadata. It still needs a bit of
'> tweaking but is mostly working okay.
'>> we wanted to control in addition to what max gave us, so they don't
'>> contain position, orientation, name, etc, even though all of those
'>> things get exported into the .lvl file (except the name, which is
'>> only used for object references)). When everything gets stable I
'>> want to re-think that a bit. > > Um, can't say I really follow -
'>> what part needs rethinking, what is > the problem? (But I agree
'>> with the part "rethink it when everything > gets stable"...)
Sorry. The .lvl file contains object position, object orientation, object bounding box, AND all of the oad data for that object. I think it would be cleaner if the oad data called for position, orientation, etc, so that the only object data in the .lvl file was the oad data (which would then INCLUDE position, etc). Not a priority. '> As far as I can tell, I need to get up to speed on the OAS/OAD
'> files to do an attribute editor. I am not quite sure as to what I
'> need to do. For writing a new attribute editor, do I need to
'> parse/create OAD files, or are OAD files completely 3DS specific? I
'> am a bit confused here. I had a first pass at reading the readme.txt
'> file in the oad and oas directories but am still kind of
'> disoriented. Maybe you could give a quick summary as to the whole
'> pipeline, starting from OAS and going down through the
'> transformations into different file types, which of those file types
'> are 3DS specific, and what a non-3DS attribute editor actually needs
'> to create and parse? -Norman
This stuff is hard to describe, I need to relay a lot of data, and I am not sure what the correct order is. This can get confusing real fast. The problem is we don't have very good terminology for discussing this stuff. First I want to explain what is in an .oad file: An oad file describes an object type in the game. There is one oad file for player, one for platform, one for camera, etc. The oad describes what attributes each object type has (it does NOT contain how many hit points the player has, it indicates the player has an attribute called "HitPoints", that it is a fixed point number, what its valid range is, and maybe a help string). Each oad file contains an array of oad entries. An oad entry is a struct (defined is source/oas/oad.h, called _typeDescriptor). (Note this struct is not used in the game!, only by the tools). Each entry maps to exactly one attribute on an object. Each entry contains a variety of information: Display information name type (int, color, object reference, bool, etc) user interface (combo box, slider, drop down menu, text entry, object selector) help string describing usage etc Editing information (minimum value, maximum value, default value, validation) The attributes editor builds its display by reading the oad file. For example: if an oad file has 4 oad entries the attributes editor will build a user interface with 4 editable fields, each customized to the entry. Since they say a picture is worth a thousand words: look at: www.recombinant.com/WorldFoundry/LevelEditor/attributes.htm Look at the section labeled "Common", that was created by reading the oad file generated from: PROPERTY_SHEET_HEADER(Common) TYPEENTRYFIXED32(Mass,,FIXED32(0),FIXED32(100),FIXED32( DEFAULT_MASS )) TYPEENTRYFIXED32(Surface Friction,,FIXED32(0),FIXED32(1.0),FIXED32(DEFAULT_FRICTION)) TYPEENTRYFIXED32(hp,,FIXED32(0),FIXED32(32767),FIXED32(DEFAULT_HITPOINTS)) TYPEENTRYINT32(Number Of Local Mailboxes,Local Mailboxes,0,40,0,"",SHOW_AS_SLIDER) TYPEENTRYOBJREFERENCE(Poof) TYPEENTRYBOOLEAN(Is Needle Gun Target,Needle Gun Target,0) TYPEENTRYINT32(Write To Mailbox On Death,Death Mailbox, 0, 3999, 0,,SHOW_AS_NUMBER,"Mailbox to write to when object is destroyed") TYPEENTRYXDATA_CONVERT(Script,DEFAULT_SCRIPTNAME,"Cave Logic Studios AI Script||..\\script s\\default.s",XDATA_NOT_REQUIRED,,,,,XDATA_SCRIPT) TYPEENTRYBOOLEAN(Script Controls Input,,0) TYPEENTRYXDATA_NOTES PROPERTY_SHEET_FOOTER LEVELCONFLAGENDCOMMON As you can see, there is a one-to-one corespondence between user interface elements and oad entries. The whole purpose of the oad file is to describe these user interface elements and how to write out a structure the game can read. Change the oad file, and the interface changes (without recompiling the attributes editor). The 3dsmax attributes editor used a binary data file (.oad). The .oad file was a kludge (it was created by making a C structure definition, compiling it (without a main), and using the binary output). It sucks, and is not portable. So, it was recently decided to switch to an iff file which contains all of the attribute information. I have made the oad system generate these files, but they have not been tested very well. I already have C++ classes which load the .oad files into memory, making it easy to query it, etc. I plan to make the same classes read from the iff file instead. Once this is done, you should be able to write the attributes editor without worrying much about how the data is stored on disk. The oad files are compiled from the oas files, they are the source file, and the only one that should ever be edited by the programmers making a game. Through much trickery (ok, by using prep), I generate several different output files from the .oas file:.iff.txt ( new improved oad file, goes into the attributes
editor) .ht ( header file for including in the engine)
.oad ( not implemented on linux, use the iff file instead)
.def ( used by the scripting system )
We have a stand-alone windows version of the attributes editor (not
really usefull, but the idea was to use it as a starting point for
adding attribute editing to other 3d packages). I haven't verified it
builds right now, but I will soon. Once I get it working, this is
where I plan to test switching from oad to iff files. Once that is all
working I think you should use it as the starting point to making a
GTK version (does GTK have a C++ interface? I would like to use a well
abstracted user interface if possible).
I hope this explaination helps, I focused on the part pertaining to
making an attributes editor, and skipped lots of other oas directory
info, so ask away.
Kevin
'> know about quaternions is that their discoverer scratched their
'> derivation on a bridge whilst walking home so he wouldn't forget
'> it). Got any good online references? (Not just formulas, I want to
'> understand what they are!) Quats are weird, but they have the
'> unique property of being able to tween orientations naturally (if
'> you tween eulers, it can look strange). They are only there because
'> that is how the data came from 3dsmax. We use Eulers in the engine,
'> so we can just change it to be eulers.
'>> We have a library which makes writting such iff files (text or
binary) easy. > > Is this library already part of the (compilable) Linux wftools? What > do the library calls look like (sample code perhaps?) The library is in wfsource/source/iffwrite, use looks like: _iff->enterChunk( ID( "STR" ) ); _iff->enterChunk( ID( "NAME" ) );
'> rush - just hungry for news!)
reason. Since this engine had the playstation as a target, we have our own memory allocation, there is a file called ram.iff.txt (I recently changed this, your version might be called ramiff.txt) which controls the size of each memory buffer. All game/level specific memory allocations come from these buffers (which means if it runs at all, it will never fail with a system memory allocation failure (so once a game has been tested enough to insure it allocates enough to start with, it will never fail). Those levels need more ram (or in a different configuration) than the default. I probably failed to update those files in the zips I uploaded. Here is the one I have for streets: { 'RAM' 'OBJD' 340000l 'PERM' 123600l 'ROOM' 191072l 'FLAG' 0l 0l // doomstick, bungeecam } Here is the one I have for babylon5: { 'RAM' 'OBJD' 340000l 'PERM' 153600l 'ROOM' 131072l 'FLAG' 0l 0l // doomstick, bungeecam } I have not tested babylon5 in quite some time, it might not run without some work (it was going to be a descent style level, it is just started, so it is not much to look at anyway).
'> development environment up and running so I could try stuff out) -
'> you only store 3 rooms of the world in memory at once. Does this
'> mean that NPC's can only be active in these three rooms? In other
'> words, if I am at one side of the world, and an NPC is 50 rooms
'> away, can the NPC move around, think, shoot, or basically act even
'> though his room is not currently within the "3 active room" window?
'> Currently only objects in the 3 rooms run, so everything else is
'> "frozen" in time. We talked about having objects which always run,
'> but that can get problematic with the physics engine. As fast as
'> computers are today, probably the best solution for this sort of
'> game would be to separate what gets rendered from what gets physics,
'> i.e. only render 9 rooms or so, but update all of them.
'> 1. It appears your visibility scheme is room-based: one room before,
the > current room, and one room after. (I use a portal scheme in my > engine.) Is World Foundry therefore limited to indoor types of > environments, or can outdoor scenes also be done reasonably well? > (Landscapes, mountains, space combat shooters, flight simulators, > racing games, etc) The current 3 room limit came from having the sony playstation as one of the targets (this allowed us to control 3 resources: texture memory, model memory, and execution time). In the short term I would like to simply increase the # of rooms loaded at once, which would greatly expand the game possibilities (if we increase it to 9 it would allow laying out a 2d grid of rooms for games like racing, etc). In the longer term I would like to investigate other methods of model/execution management (bsp trees, etc. (and I haven't had the time to read up on portal based systems). In addition, we have a tile based 2d background renderer for distant images (not currently ported to GL). '> So most of the games produced with World Foundry have been inddor,
'> right? That's what it looked like from the screenshots.
Indoor, outdoors with fog (with movement restricted), or floating in cyberspace (no boundaries, if you fall, you die). '> It gets more confusing (to me) when I start thinking about
'> arbitrary, unlimited, outdoor geometry. I suppose some sort of a
'> regular spatial partitioning (such as a 9x9 grid like you suggested)
'> is one of the more easily doable and understandable
'> strategies. Every other method seems to require some complicated way
'> of deciding when to stop drawing (when you reach a certain depth in
'> the BSP tree, when you have covered all pixels in the screen, when
'> you have reached a certain distance from the camera, when you have
'> run out of rendering time, etc.).
I think the key to any system is quick ways to cull large pieces of geometry, it doesn't matter if it is bsp's, bounding boxes, whatever, as long as you can quickly decide to ignore most of the level geometry, you should be all right (and with the speed of todays cpus, you don't even have to try that hard).
'> cross-platform way, or more fundamentally, how do they work at all
'> in WF?
Our sound support is a bit primitive, we can trigger sounds from inside of scripts, we can trigger sounds from animation key frames (with events). The sound stuff definitely needs more design work, we were just getting to it when we stopped. We don't currently have any networking stuff, but our game can run deterimisticaly (we have a joystick recorder which can re-produce an entire game by just recording the joystick and time values), so it shouldn't be that hard to make a frame-locked networked version (revisionist history would be MUCH harder). Actually, I think revisionist history can't really work unless gameplay is quite simple.
'> the technical issues a 3D engine has to face. How does WF know which
'> objects are within a room? There doesn't appear to be a "starts
'> within room" attribute on any objects. So does WF use the bounding
'> box of the room to determine which objects are in the room, or how
'> does this work? Is it even correct to say that objects "belong to" a
'> room? What is the relationship between room and object and how is it
'> specified? Yes, it uses the bounding
You have to make room objects which are the size and shape of the room. The level converter (currently runs in 3dsmax and exports a .lvl file) sorts all of the objects into room lists in the .lvl file (based, as you said, on the bounding box of the room). When the game loads a level, it goes through all of the rooms constructing the objects (we construct all of them, even though we only run 3 rooms worth at a time). The room objects keep track of which objects they contain, and hand them off to other rooms as they move about. Yes, objects "belong" in a room, it is possible for an object to be in room 1 and stick out into room 2 (which room you are in is decided by your position point). Since the current collision system doesn't check objects in the previous room against objects in the next room, objects should not be longer than a room (or a long object in room 3 sticking into room 2 might pass through a long object in room 1 sticking into room 2). Even fairly short objects can cause problems if you are not careful with the level design (if there is an object in room 3 sticking into room 2 being stood on by an object in room 2, and the camera moves into room 1, the objects in room 3 stop getting rendered and colllision checks, so the object in room 2 falls through it. On the psx we were willing to live with this, now I think we definitly want more rooms running at once.
'>> it gets saved out with the modeler's project file. So we need to be
'>> able to attach arbitrary data to an object (coming in the next
'>> release of ewave), and we need to be able to run a plug-in on a
'>> object when the users requests it. > > The arbitrary data
'>> attachment sounds like it is half of the work, is this > right? And
'>> what do you mean by running a plug-in on an object - do you just >
'>> mean calling up its property editor, or is there more? If the
'>> modeler already has the ability to attach data to objects, that
'>> part is a snap.
If it doesn't, then we would have to add that ability to it. I mean running OUR property editor (which we call the attributes editor), which allows editing of World Foundry attributes, like mass, render type, etc. When I say "plug-in" I just mean our code instead of the modelers code. It could be a plug-in, extension, script, whatever, as long as it can tell which object is selected, read/write our data to that object, and present a user interface to allow editing our attributes. '> And, how about non-humanoid characters - robots, spaceships, dogs,
'> snakes, dinosaurs, snails, sharks. Are these doable? It looked like
'> the screenshots all seemed to involve humanoid-based characters.
Of course the imagery can be whatever you want. The physic system views most things as axis aligned boxes (the exceptions are sloped surfaces (which are always contained in a box for quick culling), and what we call 'handles', which are points in geometry which can collide with other collision boxes (imagine a player stabbing another player with a sword, the handle would be the tip of the sword). We don't handle objects which change shape greatly very well, but then, show me a game that does I do have some ideas in this area, however.
'>> that was hard (it is easy to calculate where an object would be if
'>> it doesn't hit anything, it is much more difficult to figure out
'>> where it should be after hitting 3 objects in the middle of the
'>> last frame, and do it quickly). > > As for the physics, I have
'>> heard people say that simple so-called > "Euler integration" (I am
'>> not 100% sure what they mean by this, I assume > they mean simply
'>> computing the physical time difference between one frame > and
'>> another and plugging this delta-t into the velocity and
'>> acceleration) > has lots of instability problems. Nonetheless, due
'>> to its simplicity, > and before I try to understand anything more
'>> complicated, I was wanting > to play with this kind of physics. Did
'>> you use this in WF, or do you use > some more advanced form of
'>> integration? What is important for physics > in a game, anyway?
'>> Velocity and acceleration, clearly enough -- but what > else? WF
'>> seems to have momentum transfer too, a phenomenon whose equation >
'>> I have unfortunately long forgotten - any other important physics
'>> equations > built into WF's physics engine? I haven't heard of it,
'>> but we do use Euler's to store our orientation. Integration would
'>> be slow, so we simplify by saying that all accelerations are linear
'>> (the rate of acceleration does not vary in the middle of a frame).
'>> Once you do that, then you can just average the old and new speed
'>> across the frame (if you start the frame at .1 meters per second,
'>> and you end at .2 meters per second, you can just pretend you went
'>> at .15 meters per second the entire frame). Which is not quite
'>> accurate (certain objects which should have "just missed" each
'>> other might hit, etc. But the higher the framerate, the more
'>> accurate it becomes. (If we just ran physics at 1000 frames per
'>> second, a lot of problems would just go away).
'> As for collision detection, one general approach I read about is to
'> assume the invariant condition is that no objects are colliding
'> during any frame. Then, after updating an object's position, if it
'> is colliding, then move it back where it was earlier. If you can't
'> move it back to where it was earlier because something else moved
'> there in the meantime, you have to move that object back, too -- and
'> possibly meaning in the worst case that everything has to be moved
'> back to its original location. Do you use such an approach in WF,
'> or do you search space for new allowable non-colliding positions, or
'> something else?
Our physics is kind of interesting, in that it is the design of two people: myself, who has no official training (and started very weak on physics and math), and Phil, who had a much more rigorous math/physics background. I had years of video game experience, he was just starting. So what would happen is I would make up some weird way of accomplishing something (usually involving a white board and diagrams), and then task Phil with implementing it. As he ran into problems, we would work together identifying what was the cause, and try to come up with ways to fix it. So, here is how it works (Phil, feel free to correct me where I get it wrong, this went through so many revisions I might mis-remember something): Each object has a starting position each frame, and calculates an ending position where it would be if it didn't hit anything. We then calculate an axis aligned collision box surrounding the objects at both the starting and ending positions. This is called the expanded colbox. We do (NxM)/2 collision checks on the expanded colboxes on everything in the room (and objects in the 2nd room check against objects in the 1st and 3rd). This produces a collision list (one entry per collision, if one object hits 3 others, there will be 3 entries in the list). As we are generating the list, we calculate what time the 2 objects hit each other (this time will obviously fall between the beginning of the frame and the end of the frame). The list is then sorted by this time. Then the list is processed one entry at a time, dealing with each collision in turn (configure the objects to the time in question, calculate the result of the collision). If the resulting position of the objects still fit inside of the original expand colbox, then we re-check the objects against the other objects in the collision list, add any appropriate new collisions, sort them by time, and proceed. If the new positions are OUTSIDE of the expanded colbox, we have to re-collide the offending object with the room again (1xM). So we try to do everything a frame at a time, but when a collision occurs, we sub-divide the frame time to the time of each collision. In most cases, this system works fairly well in quickly reducing the # of objects which need to be processed (bsp trees or some other collision partitioning would help a whole bunch more). I never liked the idea of moving objects inside of each other and then trying to fix it. First off, that is not how it happens in real life, so I have no proof it works. (I always said "How does the universe do it?", which is why I don't know calculus, the universe doesn't calculate where the cannonball will land, it just iteratively adds the velocity and subtracts gravity, and it eventually gets there). I have seen failed versions of this idea where when attempting to back out the object would go the wrong way and come out the other side of the wall, etc. On 23-Sep-99 nlin wrote: > First off, thanks for the physics explanation, that will give me > reading material for a couple of days for sure (man-days, that is, > probably meaning weeks before I actually get around to it). I > did wonder about this though: > >> Then the list is processed one entry at a time, dealing with each collision >> in turn (configure the objects to the time in question, calculate the result of > ^^^^^^^^^^^^^^^^^^^^^^^ >> the collision). If the resulting position of the objects still fit inside of the > ^^^^^^^^^^^^^^ > > Wha do you mean, "the result of the collision"? So you find a collision, > you set the Grand Universal Clock to the time of the collision, but what > do you calculate? Is this where objects bounce off of each other, transfer > momentum, etc? Well, if you want to get a headache, just read wfsource/source/game/collisio.cc: function ResolveCollisionEvent (line 259). Yes, this is where we do momentum transfer, and handle special cases like anchored objects (walls, floors, etc), objects on paths (which won't deviate, so also behave like they have infinite mass), steps (if you hit the edge of an object and its top is slightly higher than your bottom, just raise yourself over it (allows for climbing steps ala doom, but also covers over small alignment errors in the level data). I don't remember the momentum transfer function off the top of my head either, but it is in the code. I realize that I didn't really answer your question, I would have to dig in and wrap my brain around it again to really articulate some of it, and don't have the time right now. '> Also do you have any opinions as to whether this sort of stuff would
'> be easier/harder/better/worse with bounding spheres instead of
'> boxes, or some combination of sphere-sphere and sphere-plane
'> collision methods (which are what I currently use)? I could imagine
'> that (while still not nearly 'correct' as poly-to-poly collision)
'> the combination of sphere-sphere, sphere-plane, and box-box could
'> cover a lot of common collision cases pretty well.
Well, for most level games, the floor is flat, so you at least need bounding boxes (a space flight simulator might get by with just spheres). So since we had to have bounding boxes, we decided to try to make everything work with them. Near the end we added box-plane collision for sloped surface support. '>> original expand colbox, then we re-check the objects against the
'>> other objects in the collision list, add any appropriate new
'>> collisions, sort them by time, and proceed. If the new positions
'>> are OUTSIDE of the expanded colbox, we have to re-collide the
'>> offending object with the room again (1xM). > > I am still trying
'>> to figure out the idea behind the expanded colbox. > It sort of
'>> represents the volume of the path that the object took > between
'>> the last frame and this one, right? So if the new position is >
'>> inside of the expanded colbox this means that the collision stopped
'>> > it from moving along its path but didn't push it OUTSIDE of its
'>> path. > If the new position is outside of the expanded colbox this
'>> means that > the collision pushed the object outside of its path
'>> thus requiring > a new collision check. Is this a correct
'>> interpretation, or am I missing > the point of the expanded colbox?
The idea was to cull possible collisions quickly. I reasoned that if two expanded colboxes didn't overlap, then the containing objects did not touch. This idea would suck in a situation where all of the objects were going so fast they traversed most of a room every frame. The expanded colboxes of each object would touch most of the others, and we would run real slow. Since most objects don't move that fast per frame, in a typical case very few objects have expanded colbox overlap, and we focus our efforts on dealing with those. An overlapped colbox doesn't mean the 2 objects hit, just that they could have. We then do more mathematically intense checking to see if they actually hit. We could throw away the expanded colbox code completely and the game would still work, just run much slower as it spends time considering cases it will eventually reject. Since the expanded colbox is axis aligned, an object moving diagonally will generate more false hits than an object moving along a axis. If after a collision the object still fits entirely inside its expanded colbox, it doesn't need to consider any additional game objects that weren't already in its collision list (it didn't increase the # of objects it could have it). If it does leave its expanded colbox, it needs to consider all of the other objects in the room, since it now could have hit objects which did not overlap its expanded colbox. '> Also what exactly are N and M in your equations? I fiddled around
'> with a couple of assumptions (N the # of moving objects, M the ># of
'> static objects) but couldn't exactly decide what these are.
Sorry, N & M are both the # of objects in the room, we check object #0 against the rest, then object #1 against 2 and up, etc, so end up doing (NxM)/2 checks. '> (Looks like this discussion could be the beginning of part of a
'> programmers guide, eh?)
That would be cool, especially if someone else did the editing. We could host it on the WF web site. I would like to start with a FAQ, and grow it into some programmers documentation. I am sure you have noticed by now I am not a very good manual writer. '> What would theoretically be wrong with a sphere-plane collision for
'> the character-floor collision? Nothing, but since our main
'> character looked much more like a box than a sphere, we just stuck
'> with box-box collisions. Also, our floors aren't planes, they are
'> boxes, which means they don't extend to the horizon.
'>> An overlapped colbox doesn't mean the 2 objects hit, just that they
'>> could have. We then do more mathematically intense checking to see
'>> if they actually hit. > > Aha, that was the key point I missed,
'>> that the expanded colbox is used > as a first-pass "could they
'>> possibly have collided" before bothering to > do further checks. >
'>> > When you say "more mathematically intense checking" do you mean
'>> actual > poly-poly penetration for every polygon of both objects?
No, our physics don't know anything about geometry, it just works with the bounding boxes (2 exceptions: handles, and sloped surfaces: handles are a vertex which can collide with other bounding boxes, and sloped surfaces are done as one additional set of collision checks after all of the others). "more mathematically intense" is just real did it hit or miss collision checks. Involves calculating at what time exactly did the two objects begin to overlap (in all 3 axis), plus other stuff I can't remember without looking at the code again.
function > sys_call_atexit function called, num_atFuns = 0 > calling exit with return code of -1 > ValidPtr( (nil) ) failed > ValidPtr( (nil) ) failed > \xDA\xC4 ASSERTION FAILED \xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4Ŀ > \xB3ValidPtr(_oadData) \xB3 > \xB3in file "actor.hpi" on line 117 \xB3 > \xC0\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xD9 '> sys_exit: game quit > sys_exit(-1) called > sys_exit called
recursively, retcode = -1, calling exit directly. >
'>> don't convert the geometry from the level file. This allows the
'>> geometry to come from a different 3d package than the level. > >
'>> That's an interesting concept. It is key to making a playstation
'>> game work, since re-use of geometry is the only way to fit into
'>> memory (2mb main, 1mb video including frame buffers). (That 2mb of
'>> main includes the code, stack, EVERYTHING). Actually, most games
'>> do the same thing, you only make geometry for one grenade, then
'>> generate lots of them as the game runs. We just extended the idea
'>> to all geometry (separate what it looks like from how it behaves).
'> to allow the hero/ine to jump between land and water. Can the
'> physics system somehow be changed from one "room" (above water) to
'> another room (below water) to accomodate swimming? How about the
'> subtle lighting changes which occur when underwater? Have you done
'> something like this with the engine before?
The physics engine is set up so that there are handlers for different situations: the air handler runs when you are not standing on anything, and accelerates you towards the ground. The Ground handler runs when you are standing on something, and responds to the movement of the object you are standing on. We do not currently have a water handler, but it would not be hard to write. It is also possible to get pretty close without modifying the engine: There is an object called an 'activation box', and one of its capabilities is it can 'push' on any object within it. So water could be done by making an actbox the size of the water with an up vector at about the same rate as objects fall. This would make objects hover (they would behave like they do in the air).
'> character possible, where she clibms up ladders, hangs off of
'> ledges, etc? I have no idea what sort of collision detection they
'> are using, but it seems like it has to be pretty accurate.
We did some things like that in velocity, but it required custom movement handlers. We had swinging on poles, climbing up boxes, etc. For example, climbing a box was done by placing a handle on the character's hand, then the movement handler would align the handle with the top of the box. Make an animation of the character climbing (with respect to the handle), and it worked fine.
'> instance? Did it need one for the PSX?
No, the psx has a 2d polygon engine, so WF does not currently have a software rasterizer (and with GL available, no need for one). I have written rasterizers in the past (way back, when working at spectrum holobyte, so only flat shaded). It does have a complete 3D pipeline, however, the only thing it relies on external libraries for is the 2D rasterizer (it would not be hard to write one, just haven't needed it). Hmm, maybe that would be a good idea for non-accelerated machines. Currently, we are not using GL correctly, in that we are only using it to draw 2D polygons and using our own 3D pipeline, which causes the lighting to look incorrect, since GL doesn't allow me to make a 2D polygon which is brighter than the texture map (I can only darken, not lighten).
'> perspective. Is this correct? Yes, it doesn't even think in those
terms (the camera is a separate object, and follows whatever object you specify (player, bad guy, bullet, etc). So it is free to wander away from the player, or look at something else (we had some great cut-scene style behavior in velocity where you would drop a grenade, run away, and when the grenade went off the camera would jump back to the explosion and watch it, then jump back to the player). Another example would be we had as a weapon a guided missile, when fired it the camera would follow it (and you could steer the missile), when the missile hit something, the camera would back up to get a good shot of the explosion, then glide back to the player. This was all done without touching the engine code, just a few scripts.
World Foundry? Can I sell games either as shareware or commercially > without needing to pay you any license fees? No fees of any sort (unless of course you WANT to send us money
The code base is all GPL'ed, so you can do anything the GPL
allows. This would include creating a commercial game with it (but any
enhancements you make to the engine you would have to release under
GPL). You would NOT have to release any of your assets (levels,
geometry, scripts, etc), which are what make a game a game.
Let me know if you think this is a problem, we are open to other
licensing arrangements.
WORLD FOUNDRY PROGRAMMERS' GUIDE Contents
=================================================================== - PHILOSOPHY
- * TYPES OF GAMES
- * ENGINE
- * LIBRARIES
- * GLOBALS
- * MISSING
- ** TODO LIST (16 nov 99)
- BUILDING
- * GENERAL
- * PREP
- AEGIS
- LEVEL EDITING
- * GENERAL REQUIREMENTS
- * BLENDER ATTRIB SYSTEM
- ** TODO
- * OAD/OAS/IFF
- * IFF WRITING/FORMAT
- ENGINE ARCHITECTURE
- * MEMORY
- * CULLING
- * SOUND/NETWORKING
- * OBJECTS
- ** SEPARATION OF OBJECTS AND GEOMETRY
- * COLLISION DETECTION
- ** COLLISION ERROR MESSAGES
- * PHYSICS
- ** PHYSICS HANDLERS
- ** HANDLES
- * GRAPHICS
- ** DISPLAY
- ** OPENGL
- ** TEXTURES
- ** SOFTWARE RENDERING
- ** LIGHTING
- * CAMERA
- LEGAL
===================================================================
- PHILOSOPHY
===================================================================
- * TYPES OF GAMES
- * ENGINE
- * LIBRARIES
'> of which can be separately tested, is sound. Can each library also
'> be used separately? Would it make sense to make separate use of
'> individual libraries?
As much as possible, I have tried to make the libraries be a vertical stack of dependencies, with pigsys (damn I need to rename that) at the bottom, and the game at the top. They pretty much follow the order given in /wfsource/source/README. (oops, pigsys and HAL should be reversed in README, this is because I wrote HAL, someone else wrote pigsys, and we fought over who should be at the bottom, and he won). I want to take pigsys, streams and cpplib and release them as a base toolkit suitable for any project (where exceptions aren't needed). They provide good assertion macros, validation, debugging streams, binary IO streams, platform independence, library independence. (If you throw HAL in you get platform independent task switching and timers which, ironicaly are not used by WF (the memory manegment is, however). Above the core I would like the libraries to be fairly independent, but they still stack, gfx needs iff and math, for example, and anim needs gfx. I intend to make a diagram of the relationship of all of the libraries, just haven't taken the time to find a package to do it in. (I might look at the stuff you used for your book). Most of the tools use a sub-set of the libraries, so they demonstrate how easy it is to link against them. Any project I start in the future will most certainly use at least the core libraries. (I am thinking of writting a package to transport MIDI over TCP/IP, since I recently aquired a bunch of cheap 133Mhz K5 machines to use as synthesizers).
- * GLOBALS
- * MISSING
'> And even though I don't have 3DS, you do, right? So why can't
'> you just compile all of the sample levels on the WF FTP server
'> into an asset file which can then be run, even if only under
'> Windows? Am I forgetting something?
Sorry, we have several boring, 'doesn't really demonstrate the engine' levels. What we don't have is anything like the dozen or so levels which were made for Velocity, which were full-fledged, playable levels, with goals, and enemies, etc. (We do have a promotional video we made, I should see if I can get that into a format suitable for downloading). I want something where a person downloads the executable with a level, plays it, has fun, says 'This is cool, I want to work on this!'. Or 'I want to make a level with this'.
- ** TODO LIST (16 nov 99)
'> World Foundry, including level-building tools, is available on Linux?
'> Half a year? One year? Two years?
Well, that is a tough question. Currently I am the only person really working on it (I have received a few patches from others). I see it as 2 projects: port the engine, and port the production environment. The engine is running, but needs lots of work. The production pathway used 3dsMax as its level layout tool (max and other 3d packages were used for geometry creation), so the first step is to choose a 3d package to use on linux. I am currently leaning towards extreme wave. The windows version had a max plug-in which did the level exporting, much of the code in it is not max specific, last year we decided it would be much cleaner if the exporter simply wrote out an intermediate file, and have a command line tool do the the level processing. I am still working on this (I have a max exporter which produces an iff file with all the object data in it, and am nearing completion on the command line version of the level converter). Once this is done, all that is left to have a functional pathway is the attributes editor in the modeler, and the exporter. At my current rate, I imagine I will have something working in 6 months or so. Now if I get some help, that could probably be shorted quite a bit.
- BUILDING
- *GENERAL
- *PREP
'> other macro preprocessors can't do? What are its goals? What is its
'> purpose in this universe?
prep was started before I was much of an internet user (way back in 1994), so I didn't know about m4. However, looking at m4 now I don't like it. prep was written to get around limitations of the c preprocessor. Some of my design goals: Only ONE escape character (@, choosen because C doesn't use it). I hate having to escape half of the characters because they mean something to the preprocessor. Better macros: default parameters in macros (heavily used in the oas directory) (and, better than C++, the defaults don't have to go at the end, and you can specify param 1, default 2, param 3 (you just put two commas in a row)). Ability to have preprocessor commands in macro expansions Better expression handing. regular expression based search/replace. More powerfull macro execution: in prep you can define a macro during macro execution. This amounts to having variables "@define foo @e(foo+1)@t" will create a string which is numerically 1 larger than it was before (@e = evaulate expression, @t = terminate macro definition). stream oriented instead of line oriented. With a few exceptions, all prep commands can operate in the middle of a line (or the middle of a macro invocation). Written as a text input class. Prep can be used in any program to pre-process text (hand it a file to open, and call GetLine repeatedly to get processed text). Small. The code base is small enough to understand in just a few hours (I think). There is a word document on prep in the prep directory (prep.doc), I should convert it to html or something. It has grown to have looping and other sick things God did not intend a text preproces sor to have. shortcommings: Cryptic. Not well documented (sometimes I read the source when writting prep macros). Slow. Doesn't process text particularly fast (watch how long it takes to make in the oas directory). So, in conclusion, it does what WF needs it to do, but would need some cleanup before I would claim it was general purpose.
- AEGIS
- Copy baseline files to the local directory to change them: aecp. The file can then be edited. This is something like "checking out" a file, though it is not locked. Multiple concurrent changes are resolved because a file cannot be checked in unless it successfully builds against the current baseline and passes all tests.
- LEVEL EDITING
- * GENERAL REQUIREMENTS
'> simpler, the better.
I am working on a file format for oad data when exported from a 3d package, it uses iff, but is fairly simple, mostly boils down to: name "attribute name" data "value" wrapped in chunks. Internally (before export, when you are using your attribute editor, you can use anything you want (but again, the easiest is just to store name,value for each field). '> 4) The underlying fundamental or important characteristics of an
'> attribute editor are not yet completely clear. It appears mainly
'> to be a type-attribute system, i.e. you choose an object-type for
'> the mesh, then depending on the type you get a list of valid
'> attributes for this type which you edit. Are there more fundamental
'> ideas which need to play a key role in the early design?
You are correct, the class type must be chosen first to establish what type of game object it is, which determines what attributes will be displayed. The only other key concept I can think of is that the interface is not hard coded (you don't know what attributes a 'Player' has when you compile the editor, you read that information from the oad file and construct a user interface on the fly for it (instead of laying out an attribute page, you just lay out a gui element for int, fixed, object reference, color picker, etc., then build stacks of them based on the oad data). '> 5) Are meshes really the only objects which need attributes? (I hope
'> so, though workarounds are always possible.) How about paths?
'> Anything else?
Yes, in World Foundry, you have to be an object to get data attached to you (so we have a special object, the "level" object, which contains any level-wide data we wish to encode (this object doesn't appear in the running level). Paths are something which happens to objects, so any object which has a path ought to export it when its position and rotation are exported. '> 6) This really isnt a problem but I will put it here - I need to
'> be careful about isolating dependencies on widget-set, system,
'> Blender, and my magic-X-encoding in separate classes, so that
'> the fundamental part of the system (type-attribute) can be
'> reused with other editors or other encoding schemes.
Agreed, I will try to supply something which already has full oad support so all you should need to do is provide user interface and blender stuff. If you make it able to run stand-alone (without blender), it can be the starting point for any other 3d packages attributes editor as well (I would get that done before attempting the blender integration).
- * BLENDER ATTRIB SYSTEM
'> generated 1 per object, are just temporary and thus not so
'> important. The real files are the .blend file containing the object
'> positions, and the one or more attributes files containing the
'> attributes for the objects. For now I will probably have one
'> attribute file per object and will investigate ways of reducing this
'> to one file containing all attributes for all objects (a simple
'> concatenated text file or something like a zip file using zlib),
'> which could conceivably even be bound into the .blend file if I find
'> the appropriate mechanism for doing so -- though everything in 1
'> file doesn't seem of paramount importance to me; two files seems
'> bearable. Two files is fine.
'>> (this is sort of a wart on our oad files, they list all of the data
'>> we wanted to control in addition to what max gave us, so they don't
'>> contain position, orientation, name, etc, even though all of those
'>> things get exported into the .lvl file (except the name, which is
'>> only used for object references)). When everything gets stable I
'>> want to re-think that a bit. > > Um, can't say I really follow -
'>> what part needs rethinking, what is > the problem? (But I agree
'>> with the part "rethink it when everything > gets stable"...)
Sorry. The .lvl file contains object position, object orientation, object bounding box, AND all of the oad data for that object. I think it would be cleaner if the oad data called for position, orientation, etc, so that the only object data in the .lvl file was the oad data (which would then INCLUDE position, etc). Not a priority. '> >> > Orientation: I just >> > finished extending the magic-X to be a
magic-coordinate system, >> >> > Path information: >> Paths are only used for objects which have a set motion (mostly for platform >> (sonic or mario) style games. Conveyor belts, or machinery. In WF they are stored >> as keyframes which we draw straight lines between, so we can't really follow curves >> very well (but it would be easy for someone to add a new position player to path to >> do it). So I would get everything else working first, then we can figure out paths. > > Thankfully (I just tried it) Blender can store and export polylines > as meshes (it can also convert curves into polylines), BUT these > polylines consist of tons of ... two-vertex edges, which is exactly > what I previously assumed was not allowable and thus could flag > the begin of my meta-data. But, don't panic, I can signal my > meta-data with a series of three (or 20, or 42) OVERLAPPING two-vertex > edges, which should definitely never occur in any geometry, even > in polylines, so the magic-X encoding will work for paths, as well. > > Anyway, let's not worry too much about paths now, I at least am 95% > sure it will work, so it's just an "implementation detail" which > we'll do later after the other stuff with boxes is working. '>> > I think we're getting close: object identity, arbitrary object
'>> > attributes, export of all objects with OID, position, and
'>> > orientation, and almost certainly path information too (once I
'>> > understand exactly how it works in WF). Anything else we need?
'>> > >> I believe that is all we use for level export (we will discuss
'>> > geometry >> export later, once we have a working level running
'>> > with boxes). > > So... what exactly do I need to export? I
'>> > imagine something like > the following... You click "export
'>> > level" in my little standlone > program. This sends the
'>> > keystrokes to blender to mark and export all > meshes. Then I
'>> > invoke a perl script (to be written) which parses > all the .obj
'>> > (exported videoscape) files, extracts the id, position, > and
'>> > orientation from the magic-X, finds the object id in the
'>> > attributes > file and finds the appropriate attributes. > > So
'>> > far, so good. (It doesn't have to be in perl, either, but it >
'>> > would probably be fastest to whip it up this way.) At this point
'>> > > I have all objects, their positions, orientations, and
'>> > attributes > (including the name, the object-ID is irrelevant to
'>> > external > users). > > In what form do you then need to access
'>> > this information? > Can I simply then write out some sort of a
'>> > simple text file > > OBJECTNAME=BLAHBLAH > POSITION=1.0,2.0,3.0 >
'>> > ORIENTATION_X=1.0,0.0,0.0 > ORIENTATION_Y=0.0,0.0,0.0 >
'>> > ORIENTATION_Z=0.0,0.0,0.0 > OBJECT_SPECIFIC_ATTRIB_1="my name is
'>> > joe" > OBJECT_SPECIFIC_ATTRIB_2="green" > END_OBJECT > >
'>> > OBJECTNAME=BLAHBLAH_2 > POSITION=9.0,9.0,9.0 >
'>> > ORIENTATION_X=0.0,0.0,0.0 > ORIENTATION_Y=0.0,1.0,0.0 >
'>> > ORIENTATION_Z=0.0,0.0,0.0 >
'>> > ANOTHER_OBJECT_SPECIFIC_ATTRIB=773.21; >
'>> > ANOTHER_OBJECT_SPECIFIC_ATTRIB_2="he said mount huh huh"; >
'>> > (courtesy of pole.oas, line 15
) > END_OBJECT > > which you'>> > then parse into whatever form you need? Or should I output > IFF
'>> > at this point already? I've never done any IFF stuff, so don't >
'>> > necessarily want to slow up the whole development process by >
'>> > struggling with it if I don't have to...
Wow, that looks just like videoscape (I can't imagine why ;-). Have I got a bargain for you. What if I told you you could have the power of iff with the ease of use of text? All you have to do is produce a text file which iffcomp can read, and you can produce binary iff output. Now how much would you pay? (Doesn't matter, its free!). So, here is some sample output: '> I'm not a Microsoft Windows expert, but I play one at work. Though
'> Linux is my OS of choice, the reality of the marketplace for my main
'> employer dictates that we write software for M$win, so I have some
'> experience with Windows programming. Therefore it is conceivable
'> that I could start looking at the property editor now even if it
'> doesn't completely run yet. The main problem I foresee is that the
'> code is probably not yet compilable with any free compiler (Cygnus
'> gcc for windows), right? I don't have access to any non-free C++
'> compilers at the moment, and in fact have no need for anything other
'> than gcc.
Since it is based on the 3dsmax code, it is compiled with VC++ (you HAVE to use VC++ to do 3dsmax work). I don't care too much about having a working windows version, I just want to prove the rest of the code is working, it shouldn't take me too long to debug it (the source is in wfsource.tar.gz in source/attrib if you want to look at it. It hasn't been updated to read the new oad iff files, still reads the .oad binary files). '>> I decided I would have better luck promoting WF if there were
'>> better levels to show, so I am concentrating on getting a working
'>> windows release out there so that artists could have a chance of
'>> making some. If someone made a cool level showing off the
'>> capabilities of WF, I think it would start to take off. > > Sounds
'>> perfectly reasonable. However, don't forget that the sooner a >
'>> free (Linux, or at least non-3DS-dependent) GDK is available, the
'>> more > people will be able to develop levels. Yes, I am done
'>> working on the windows GDK (other than documentation and any
'>> support anyone needs).
'> If it's not too fancy, the attributes editor could conceivably run
'> under WINE, the Linux Windows emulator. Wine can run a surprising
'> number of native Windows binaries these days. In fact it can even
'> run Tomb Raider II with hardware acceleration (the Direct3D emuation
'> layer makes calls to Mesa). Pretty amazing, huh? gcc can also cross
'> compile for Windows, meaning the editor could even be compiled under
'> Linux if the source code is gcc-friendly.
Interesting idea, it most likely will work, but getting it to compile under gcc for windows might be more of a hassle than porting it to another gui toolkit under linux. I guess I will leave that up to you. (On second thought, I am sure it would be easier to change compilers than to change gui toolkits, as soon as I get it working I will test it on wine). '> I need to review our previous emails to understand the entire system
'> architecture again regarding levels and attributes, but assuming
'> that the attributes editor can run unchanged under Wine, then how
'> much additional work is needed to get a level editing environment up
'> and running with, say, blender? What type of file does the
'> standalone attributes editor read in, anyway? I am thinking along
'> these lines: Blender \ \ \ \ stand alone \ property editor my
'> magic-x / object ID encoding / \ / \ / \ / \ / some common file
'> format In other words, I lay out some cubes in Blender and write
'> only the most elementary of attribute information (type, name) into
'> some common file format using my already-established magic-X
'> encoding and blender remote-control via keystrokes. The standalone
'> property editor (running under Wine on Linux, for instance) would
'> run parallel as a separate program and would read in the file I just
'> wrote, and from there I could fill in the additional properties. In
'> other words (hey, there's that phrase again) I would just use
'> Blender and my remote-control system to help identify and position
'> objects in 3D space. Everything else would be specified through your
'> already-working (or almost-already-working) standlone property
'> editor, which could run under Wine on Linux. Is this chain of
'> reasoning tenable? If so, the main problem I see is the common file
'> format read by the existing standalone property editor. I guess
'> this is IFF? Or is it even uglier, being some sort of native 3DS
'> format? Sorry if you already covered this in a previous email, it's
'> all kind of foggy in my memory right now.
Yes, I think that can be made to work. There are actually two common file formats: the ObjectAttributeDescription (oad), which describes each field (name, etc), which is only changed by programmers (which the attribute editor reads but doesn't change) , and the data itself (oad data), which there is a copy of for each object, and is what the attribute editor edits. I intend both of these to be store in .iff files, vcurrently the oad is stored in a binary file (.oad) (although I have made the production pathway produce an .iff version as well), and the oad data is stored inside of 3dstudio max (although I have written an exporter which writes it out as .iff). So I have the .iff files, just not the code to use it (about 1/2 finished with a version of the level converter which uses the .iff files). Within a few days I will get back on that task. '> As for me, I enhanced the magic-X Blender encoding so that it also
'> works with paths (polylines) by using 4 overlapping edges at the
'> beginning to flag the start of the metadata. It still needs a bit of
'> tweaking but is mostly working okay.
- ** TODO
- *OAD/OAS/IFF
'>> we wanted to control in addition to what max gave us, so they don't
'>> contain position, orientation, name, etc, even though all of those
'>> things get exported into the .lvl file (except the name, which is
'>> only used for object references)). When everything gets stable I
'>> want to re-think that a bit. > > Um, can't say I really follow -
'>> what part needs rethinking, what is > the problem? (But I agree
'>> with the part "rethink it when everything > gets stable"...)
Sorry. The .lvl file contains object position, object orientation, object bounding box, AND all of the oad data for that object. I think it would be cleaner if the oad data called for position, orientation, etc, so that the only object data in the .lvl file was the oad data (which would then INCLUDE position, etc). Not a priority. '> As far as I can tell, I need to get up to speed on the OAS/OAD
'> files to do an attribute editor. I am not quite sure as to what I
'> need to do. For writing a new attribute editor, do I need to
'> parse/create OAD files, or are OAD files completely 3DS specific? I
'> am a bit confused here. I had a first pass at reading the readme.txt
'> file in the oad and oas directories but am still kind of
'> disoriented. Maybe you could give a quick summary as to the whole
'> pipeline, starting from OAS and going down through the
'> transformations into different file types, which of those file types
'> are 3DS specific, and what a non-3DS attribute editor actually needs
'> to create and parse? -Norman
This stuff is hard to describe, I need to relay a lot of data, and I am not sure what the correct order is. This can get confusing real fast. The problem is we don't have very good terminology for discussing this stuff. First I want to explain what is in an .oad file: An oad file describes an object type in the game. There is one oad file for player, one for platform, one for camera, etc. The oad describes what attributes each object type has (it does NOT contain how many hit points the player has, it indicates the player has an attribute called "HitPoints", that it is a fixed point number, what its valid range is, and maybe a help string). Each oad file contains an array of oad entries. An oad entry is a struct (defined is source/oas/oad.h, called _typeDescriptor). (Note this struct is not used in the game!, only by the tools). Each entry maps to exactly one attribute on an object. Each entry contains a variety of information: Display information name type (int, color, object reference, bool, etc) user interface (combo box, slider, drop down menu, text entry, object selector) help string describing usage etc Editing information (minimum value, maximum value, default value, validation) The attributes editor builds its display by reading the oad file. For example: if an oad file has 4 oad entries the attributes editor will build a user interface with 4 editable fields, each customized to the entry. Since they say a picture is worth a thousand words: look at: www.recombinant.com/WorldFoundry/LevelEditor/attributes.htm Look at the section labeled "Common", that was created by reading the oad file generated from: PROPERTY_SHEET_HEADER(Common) TYPEENTRYFIXED32(Mass,,FIXED32(0),FIXED32(100),FIXED32( DEFAULT_MASS )) TYPEENTRYFIXED32(Surface Friction,,FIXED32(0),FIXED32(1.0),FIXED32(DEFAULT_FRICTION)) TYPEENTRYFIXED32(hp,,FIXED32(0),FIXED32(32767),FIXED32(DEFAULT_HITPOINTS)) TYPEENTRYINT32(Number Of Local Mailboxes,Local Mailboxes,0,40,0,"",SHOW_AS_SLIDER) TYPEENTRYOBJREFERENCE(Poof) TYPEENTRYBOOLEAN(Is Needle Gun Target,Needle Gun Target,0) TYPEENTRYINT32(Write To Mailbox On Death,Death Mailbox, 0, 3999, 0,,SHOW_AS_NUMBER,"Mailbox to write to when object is destroyed") TYPEENTRYXDATA_CONVERT(Script,DEFAULT_SCRIPTNAME,"Cave Logic Studios AI Script||..\\script s\\default.s",XDATA_NOT_REQUIRED,,,,,XDATA_SCRIPT) TYPEENTRYBOOLEAN(Script Controls Input,,0) TYPEENTRYXDATA_NOTES PROPERTY_SHEET_FOOTER LEVELCONFLAGENDCOMMON As you can see, there is a one-to-one corespondence between user interface elements and oad entries. The whole purpose of the oad file is to describe these user interface elements and how to write out a structure the game can read. Change the oad file, and the interface changes (without recompiling the attributes editor). The 3dsmax attributes editor used a binary data file (.oad). The .oad file was a kludge (it was created by making a C structure definition, compiling it (without a main), and using the binary output). It sucks, and is not portable. So, it was recently decided to switch to an iff file which contains all of the attribute information. I have made the oad system generate these files, but they have not been tested very well. I already have C++ classes which load the .oad files into memory, making it easy to query it, etc. I plan to make the same classes read from the iff file instead. Once this is done, you should be able to write the attributes editor without worrying much about how the data is stored on disk. The oad files are compiled from the oas files, they are the source file, and the only one that should ever be edited by the programmers making a game. Through much trickery (ok, by using prep), I generate several different output files from the .oas file:
- *IFF WRITING/FORMAT
'> know about quaternions is that their discoverer scratched their
'> derivation on a bridge whilst walking home so he wouldn't forget
'> it). Got any good online references? (Not just formulas, I want to
'> understand what they are!) Quats are weird, but they have the
'> unique property of being able to tween orientations naturally (if
'> you tween eulers, it can look strange). They are only there because
'> that is how the data came from 3dsmax. We use Eulers in the engine,
'> so we can just change it to be eulers.
'>> We have a library which makes writting such iff files (text or
binary) easy. > > Is this library already part of the (compilable) Linux wftools? What > do the library calls look like (sample code perhaps?) The library is in wfsource/source/iffwrite, use looks like: _iff->enterChunk( ID( "STR" ) ); _iff->enterChunk( ID( "NAME" ) );
-
-
-
-
-
-
-
-
-
-
-
-
- _iff << "Class Name"; _iff->exitChunk(); _iff->enterChunk( ID( "DATA" ) );
- _iff << className.c_str(); _iff->exitChunk(); _iff->exitChunk();
-
-
-
-
-
-
-
-
-
-
-
'> rush - just hungry for news!)
- ENGINE ARCHITECTURE
- *MEMORY
reason. Since this engine had the playstation as a target, we have our own memory allocation, there is a file called ram.iff.txt (I recently changed this, your version might be called ramiff.txt) which controls the size of each memory buffer. All game/level specific memory allocations come from these buffers (which means if it runs at all, it will never fail with a system memory allocation failure (so once a game has been tested enough to insure it allocates enough to start with, it will never fail). Those levels need more ram (or in a different configuration) than the default. I probably failed to update those files in the zips I uploaded. Here is the one I have for streets: { 'RAM' 'OBJD' 340000l 'PERM' 123600l 'ROOM' 191072l 'FLAG' 0l 0l // doomstick, bungeecam } Here is the one I have for babylon5: { 'RAM' 'OBJD' 340000l 'PERM' 153600l 'ROOM' 131072l 'FLAG' 0l 0l // doomstick, bungeecam } I have not tested babylon5 in quite some time, it might not run without some work (it was going to be a descent style level, it is just started, so it is not much to look at anyway).
- * CULLING
'> development environment up and running so I could try stuff out) -
'> you only store 3 rooms of the world in memory at once. Does this
'> mean that NPC's can only be active in these three rooms? In other
'> words, if I am at one side of the world, and an NPC is 50 rooms
'> away, can the NPC move around, think, shoot, or basically act even
'> though his room is not currently within the "3 active room" window?
'> Currently only objects in the 3 rooms run, so everything else is
'> "frozen" in time. We talked about having objects which always run,
'> but that can get problematic with the physics engine. As fast as
'> computers are today, probably the best solution for this sort of
'> game would be to separate what gets rendered from what gets physics,
'> i.e. only render 9 rooms or so, but update all of them.
'> 1. It appears your visibility scheme is room-based: one room before,
the > current room, and one room after. (I use a portal scheme in my > engine.) Is World Foundry therefore limited to indoor types of > environments, or can outdoor scenes also be done reasonably well? > (Landscapes, mountains, space combat shooters, flight simulators, > racing games, etc) The current 3 room limit came from having the sony playstation as one of the targets (this allowed us to control 3 resources: texture memory, model memory, and execution time). In the short term I would like to simply increase the # of rooms loaded at once, which would greatly expand the game possibilities (if we increase it to 9 it would allow laying out a 2d grid of rooms for games like racing, etc). In the longer term I would like to investigate other methods of model/execution management (bsp trees, etc. (and I haven't had the time to read up on portal based systems). In addition, we have a tile based 2d background renderer for distant images (not currently ported to GL). '> So most of the games produced with World Foundry have been inddor,
'> right? That's what it looked like from the screenshots.
Indoor, outdoors with fog (with movement restricted), or floating in cyberspace (no boundaries, if you fall, you die). '> It gets more confusing (to me) when I start thinking about
'> arbitrary, unlimited, outdoor geometry. I suppose some sort of a
'> regular spatial partitioning (such as a 9x9 grid like you suggested)
'> is one of the more easily doable and understandable
'> strategies. Every other method seems to require some complicated way
'> of deciding when to stop drawing (when you reach a certain depth in
'> the BSP tree, when you have covered all pixels in the screen, when
'> you have reached a certain distance from the camera, when you have
'> run out of rendering time, etc.).
I think the key to any system is quick ways to cull large pieces of geometry, it doesn't matter if it is bsp's, bounding boxes, whatever, as long as you can quickly decide to ignore most of the level geometry, you should be all right (and with the speed of todays cpus, you don't even have to try that hard).
- * SOUND/NETWORKING
'> cross-platform way, or more fundamentally, how do they work at all
'> in WF?
Our sound support is a bit primitive, we can trigger sounds from inside of scripts, we can trigger sounds from animation key frames (with events). The sound stuff definitely needs more design work, we were just getting to it when we stopped. We don't currently have any networking stuff, but our game can run deterimisticaly (we have a joystick recorder which can re-produce an entire game by just recording the joystick and time values), so it shouldn't be that hard to make a frame-locked networked version (revisionist history would be MUCH harder). Actually, I think revisionist history can't really work unless gameplay is quite simple.
- * OBJECTS
'> the technical issues a 3D engine has to face. How does WF know which
'> objects are within a room? There doesn't appear to be a "starts
'> within room" attribute on any objects. So does WF use the bounding
'> box of the room to determine which objects are in the room, or how
'> does this work? Is it even correct to say that objects "belong to" a
'> room? What is the relationship between room and object and how is it
'> specified? Yes, it uses the bounding
You have to make room objects which are the size and shape of the room. The level converter (currently runs in 3dsmax and exports a .lvl file) sorts all of the objects into room lists in the .lvl file (based, as you said, on the bounding box of the room). When the game loads a level, it goes through all of the rooms constructing the objects (we construct all of them, even though we only run 3 rooms worth at a time). The room objects keep track of which objects they contain, and hand them off to other rooms as they move about. Yes, objects "belong" in a room, it is possible for an object to be in room 1 and stick out into room 2 (which room you are in is decided by your position point). Since the current collision system doesn't check objects in the previous room against objects in the next room, objects should not be longer than a room (or a long object in room 3 sticking into room 2 might pass through a long object in room 1 sticking into room 2). Even fairly short objects can cause problems if you are not careful with the level design (if there is an object in room 3 sticking into room 2 being stood on by an object in room 2, and the camera moves into room 1, the objects in room 3 stop getting rendered and colllision checks, so the object in room 2 falls through it. On the psx we were willing to live with this, now I think we definitly want more rooms running at once.
- ** SEPARATION OF OBJECTS AND GEOMETRY
'>> it gets saved out with the modeler's project file. So we need to be
'>> able to attach arbitrary data to an object (coming in the next
'>> release of ewave), and we need to be able to run a plug-in on a
'>> object when the users requests it. > > The arbitrary data
'>> attachment sounds like it is half of the work, is this > right? And
'>> what do you mean by running a plug-in on an object - do you just >
'>> mean calling up its property editor, or is there more? If the
'>> modeler already has the ability to attach data to objects, that
'>> part is a snap.
If it doesn't, then we would have to add that ability to it. I mean running OUR property editor (which we call the attributes editor), which allows editing of World Foundry attributes, like mass, render type, etc. When I say "plug-in" I just mean our code instead of the modelers code. It could be a plug-in, extension, script, whatever, as long as it can tell which object is selected, read/write our data to that object, and present a user interface to allow editing our attributes. '> And, how about non-humanoid characters - robots, spaceships, dogs,
'> snakes, dinosaurs, snails, sharks. Are these doable? It looked like
'> the screenshots all seemed to involve humanoid-based characters.
Of course the imagery can be whatever you want. The physic system views most things as axis aligned boxes (the exceptions are sloped surfaces (which are always contained in a box for quick culling), and what we call 'handles', which are points in geometry which can collide with other collision boxes (imagine a player stabbing another player with a sword, the handle would be the tip of the sword). We don't handle objects which change shape greatly very well, but then, show me a game that does
I do have some ideas in this area, however.
- * COLLISION DETECTION
'>> that was hard (it is easy to calculate where an object would be if
'>> it doesn't hit anything, it is much more difficult to figure out
'>> where it should be after hitting 3 objects in the middle of the
'>> last frame, and do it quickly). > > As for the physics, I have
'>> heard people say that simple so-called > "Euler integration" (I am
'>> not 100% sure what they mean by this, I assume > they mean simply
'>> computing the physical time difference between one frame > and
'>> another and plugging this delta-t into the velocity and
'>> acceleration) > has lots of instability problems. Nonetheless, due
'>> to its simplicity, > and before I try to understand anything more
'>> complicated, I was wanting > to play with this kind of physics. Did
'>> you use this in WF, or do you use > some more advanced form of
'>> integration? What is important for physics > in a game, anyway?
'>> Velocity and acceleration, clearly enough -- but what > else? WF
'>> seems to have momentum transfer too, a phenomenon whose equation >
'>> I have unfortunately long forgotten - any other important physics
'>> equations > built into WF's physics engine? I haven't heard of it,
'>> but we do use Euler's to store our orientation. Integration would
'>> be slow, so we simplify by saying that all accelerations are linear
'>> (the rate of acceleration does not vary in the middle of a frame).
'>> Once you do that, then you can just average the old and new speed
'>> across the frame (if you start the frame at .1 meters per second,
'>> and you end at .2 meters per second, you can just pretend you went
'>> at .15 meters per second the entire frame). Which is not quite
'>> accurate (certain objects which should have "just missed" each
'>> other might hit, etc. But the higher the framerate, the more
'>> accurate it becomes. (If we just ran physics at 1000 frames per
'>> second, a lot of problems would just go away).
'> As for collision detection, one general approach I read about is to
'> assume the invariant condition is that no objects are colliding
'> during any frame. Then, after updating an object's position, if it
'> is colliding, then move it back where it was earlier. If you can't
'> move it back to where it was earlier because something else moved
'> there in the meantime, you have to move that object back, too -- and
'> possibly meaning in the worst case that everything has to be moved
'> back to its original location. Do you use such an approach in WF,
'> or do you search space for new allowable non-colliding positions, or
'> something else?
Our physics is kind of interesting, in that it is the design of two people: myself, who has no official training (and started very weak on physics and math), and Phil, who had a much more rigorous math/physics background. I had years of video game experience, he was just starting. So what would happen is I would make up some weird way of accomplishing something (usually involving a white board and diagrams), and then task Phil with implementing it. As he ran into problems, we would work together identifying what was the cause, and try to come up with ways to fix it. So, here is how it works (Phil, feel free to correct me where I get it wrong, this went through so many revisions I might mis-remember something): Each object has a starting position each frame, and calculates an ending position where it would be if it didn't hit anything. We then calculate an axis aligned collision box surrounding the objects at both the starting and ending positions. This is called the expanded colbox. We do (NxM)/2 collision checks on the expanded colboxes on everything in the room (and objects in the 2nd room check against objects in the 1st and 3rd). This produces a collision list (one entry per collision, if one object hits 3 others, there will be 3 entries in the list). As we are generating the list, we calculate what time the 2 objects hit each other (this time will obviously fall between the beginning of the frame and the end of the frame). The list is then sorted by this time. Then the list is processed one entry at a time, dealing with each collision in turn (configure the objects to the time in question, calculate the result of the collision). If the resulting position of the objects still fit inside of the original expand colbox, then we re-check the objects against the other objects in the collision list, add any appropriate new collisions, sort them by time, and proceed. If the new positions are OUTSIDE of the expanded colbox, we have to re-collide the offending object with the room again (1xM). So we try to do everything a frame at a time, but when a collision occurs, we sub-divide the frame time to the time of each collision. In most cases, this system works fairly well in quickly reducing the # of objects which need to be processed (bsp trees or some other collision partitioning would help a whole bunch more). I never liked the idea of moving objects inside of each other and then trying to fix it. First off, that is not how it happens in real life, so I have no proof it works. (I always said "How does the universe do it?", which is why I don't know calculus, the universe doesn't calculate where the cannonball will land, it just iteratively adds the velocity and subtracts gravity, and it eventually gets there). I have seen failed versions of this idea where when attempting to back out the object would go the wrong way and come out the other side of the wall, etc. On 23-Sep-99 nlin wrote: > First off, thanks for the physics explanation, that will give me > reading material for a couple of days for sure (man-days, that is, > probably meaning weeks before I actually get around to it). I > did wonder about this though: > >> Then the list is processed one entry at a time, dealing with each collision >> in turn (configure the objects to the time in question, calculate the result of > ^^^^^^^^^^^^^^^^^^^^^^^ >> the collision). If the resulting position of the objects still fit inside of the > ^^^^^^^^^^^^^^ > > Wha do you mean, "the result of the collision"? So you find a collision, > you set the Grand Universal Clock to the time of the collision, but what > do you calculate? Is this where objects bounce off of each other, transfer > momentum, etc? Well, if you want to get a headache, just read wfsource/source/game/collisio.cc: function ResolveCollisionEvent (line 259). Yes, this is where we do momentum transfer, and handle special cases like anchored objects (walls, floors, etc), objects on paths (which won't deviate, so also behave like they have infinite mass), steps (if you hit the edge of an object and its top is slightly higher than your bottom, just raise yourself over it (allows for climbing steps ala doom, but also covers over small alignment errors in the level data). I don't remember the momentum transfer function off the top of my head either, but it is in the code. I realize that I didn't really answer your question, I would have to dig in and wrap my brain around it again to really articulate some of it, and don't have the time right now. '> Also do you have any opinions as to whether this sort of stuff would
'> be easier/harder/better/worse with bounding spheres instead of
'> boxes, or some combination of sphere-sphere and sphere-plane
'> collision methods (which are what I currently use)? I could imagine
'> that (while still not nearly 'correct' as poly-to-poly collision)
'> the combination of sphere-sphere, sphere-plane, and box-box could
'> cover a lot of common collision cases pretty well.
Well, for most level games, the floor is flat, so you at least need bounding boxes (a space flight simulator might get by with just spheres). So since we had to have bounding boxes, we decided to try to make everything work with them. Near the end we added box-plane collision for sloped surface support. '>> original expand colbox, then we re-check the objects against the
'>> other objects in the collision list, add any appropriate new
'>> collisions, sort them by time, and proceed. If the new positions
'>> are OUTSIDE of the expanded colbox, we have to re-collide the
'>> offending object with the room again (1xM). > > I am still trying
'>> to figure out the idea behind the expanded colbox. > It sort of
'>> represents the volume of the path that the object took > between
'>> the last frame and this one, right? So if the new position is >
'>> inside of the expanded colbox this means that the collision stopped
'>> > it from moving along its path but didn't push it OUTSIDE of its
'>> path. > If the new position is outside of the expanded colbox this
'>> means that > the collision pushed the object outside of its path
'>> thus requiring > a new collision check. Is this a correct
'>> interpretation, or am I missing > the point of the expanded colbox?
The idea was to cull possible collisions quickly. I reasoned that if two expanded colboxes didn't overlap, then the containing objects did not touch. This idea would suck in a situation where all of the objects were going so fast they traversed most of a room every frame. The expanded colboxes of each object would touch most of the others, and we would run real slow. Since most objects don't move that fast per frame, in a typical case very few objects have expanded colbox overlap, and we focus our efforts on dealing with those. An overlapped colbox doesn't mean the 2 objects hit, just that they could have. We then do more mathematically intense checking to see if they actually hit. We could throw away the expanded colbox code completely and the game would still work, just run much slower as it spends time considering cases it will eventually reject. Since the expanded colbox is axis aligned, an object moving diagonally will generate more false hits than an object moving along a axis. If after a collision the object still fits entirely inside its expanded colbox, it doesn't need to consider any additional game objects that weren't already in its collision list (it didn't increase the # of objects it could have it). If it does leave its expanded colbox, it needs to consider all of the other objects in the room, since it now could have hit objects which did not overlap its expanded colbox. '> Also what exactly are N and M in your equations? I fiddled around
'> with a couple of assumptions (N the # of moving objects, M the ># of
'> static objects) but couldn't exactly decide what these are.
Sorry, N & M are both the # of objects in the room, we check object #0 against the rest, then object #1 against 2 and up, etc, so end up doing (NxM)/2 checks. '> (Looks like this discussion could be the beginning of part of a
'> programmers guide, eh?)
That would be cool, especially if someone else did the editing. We could host it on the WF web site. I would like to start with a FAQ, and grow it into some programmers documentation. I am sure you have noticed by now I am not a very good manual writer. '> What would theoretically be wrong with a sphere-plane collision for
'> the character-floor collision? Nothing, but since our main
'> character looked much more like a box than a sphere, we just stuck
'> with box-box collisions. Also, our floors aren't planes, they are
'> boxes, which means they don't extend to the horizon.
'>> An overlapped colbox doesn't mean the 2 objects hit, just that they
'>> could have. We then do more mathematically intense checking to see
'>> if they actually hit. > > Aha, that was the key point I missed,
'>> that the expanded colbox is used > as a first-pass "could they
'>> possibly have collided" before bothering to > do further checks. >
'>> > When you say "more mathematically intense checking" do you mean
'>> actual > poly-poly penetration for every polygon of both objects?
No, our physics don't know anything about geometry, it just works with the bounding boxes (2 exceptions: handles, and sloped surfaces: handles are a vertex which can collide with other bounding boxes, and sloped surfaces are done as one additional set of collision checks after all of the others). "more mathematically intense" is just real did it hit or miss collision checks. Involves calculating at what time exactly did the two objects begin to overlap (in all 3 axis), plus other stuff I can't remember without looking at the code again.
- ** COLLISION ERROR MESSAGES
>
AssertMsg:Actor #1 (unknown) and Actor #67 (unknown) > \xDA\xC4 ASSERTION FAILED \xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4Ŀ > \xB3!attr1.PremoveCollisionCheck(attr2) \xB3 > \xB3in file "collisio.cc" on line 82 \xB3 > \xC0\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xD9 '> sys_exit: game quit > sys_exit(-1) called > Calling sys_call_atexitfunction > sys_call_atexit function called, num_atFuns = 0 > calling exit with return code of -1 > ValidPtr( (nil) ) failed > ValidPtr( (nil) ) failed > \xDA\xC4 ASSERTION FAILED \xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4Ŀ > \xB3ValidPtr(_oadData) \xB3 > \xB3in file "actor.hpi" on line 117 \xB3 > \xC0\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xC4\xD9 '> sys_exit: game quit > sys_exit(-1) called > sys_exit called
recursively, retcode = -1, calling exit directly. >
- *PHYSICS
'>> don't convert the geometry from the level file. This allows the
'>> geometry to come from a different 3d package than the level. > >
'>> That's an interesting concept. It is key to making a playstation
'>> game work, since re-use of geometry is the only way to fit into
'>> memory (2mb main, 1mb video including frame buffers). (That 2mb of
'>> main includes the code, stack, EVERYTHING). Actually, most games
'>> do the same thing, you only make geometry for one grenade, then
'>> generate lots of them as the game runs. We just extended the idea
'>> to all geometry (separate what it looks like from how it behaves).
- **PHYSICS HANDLERS
'> to allow the hero/ine to jump between land and water. Can the
'> physics system somehow be changed from one "room" (above water) to
'> another room (below water) to accomodate swimming? How about the
'> subtle lighting changes which occur when underwater? Have you done
'> something like this with the engine before?
The physics engine is set up so that there are handlers for different situations: the air handler runs when you are not standing on anything, and accelerates you towards the ground. The Ground handler runs when you are standing on something, and responds to the movement of the object you are standing on. We do not currently have a water handler, but it would not be hard to write. It is also possible to get pretty close without modifying the engine: There is an object called an 'activation box', and one of its capabilities is it can 'push' on any object within it. So water could be done by making an actbox the size of the water with an up vector at about the same rate as objects fall. This would make objects hover (they would behave like they do in the air).
- **HANDLES
'> character possible, where she clibms up ladders, hangs off of
'> ledges, etc? I have no idea what sort of collision detection they
'> are using, but it seems like it has to be pretty accurate.
We did some things like that in velocity, but it required custom movement handlers. We had swinging on poles, climbing up boxes, etc. For example, climbing a box was done by placing a handle on the character's hand, then the movement handler would align the handle with the top of the box. Make an animation of the character climbing (with respect to the handle), and it worked fine.
- *GRAPHICS
- **DISPLAY
- **OPENGL
- **TEXTURES
- **SOFTWARE RENDERING
'> instance? Did it need one for the PSX?
No, the psx has a 2d polygon engine, so WF does not currently have a software rasterizer (and with GL available, no need for one). I have written rasterizers in the past (way back, when working at spectrum holobyte, so only flat shaded). It does have a complete 3D pipeline, however, the only thing it relies on external libraries for is the 2D rasterizer (it would not be hard to write one, just haven't needed it). Hmm, maybe that would be a good idea for non-accelerated machines. Currently, we are not using GL correctly, in that we are only using it to draw 2D polygons and using our own 3D pipeline, which causes the lighting to look incorrect, since GL doesn't allow me to make a 2D polygon which is brighter than the texture map (I can only darken, not lighten).
- **LIGHTING
- *CAMERA
'> perspective. Is this correct? Yes, it doesn't even think in those
terms (the camera is a separate object, and follows whatever object you specify (player, bad guy, bullet, etc). So it is free to wander away from the player, or look at something else (we had some great cut-scene style behavior in velocity where you would drop a grenade, run away, and when the grenade went off the camera would jump back to the explosion and watch it, then jump back to the player). Another example would be we had as a weapon a guided missile, when fired it the camera would follow it (and you could steer the missile), when the missile hit something, the camera would back up to get a good shot of the explosion, then glide back to the player. This was all done without touching the engine code, just a few scripts.
- LEGAL
World Foundry? Can I sell games either as shareware or commercially > without needing to pay you any license fees? No fees of any sort (unless of course you WANT to send us money
The code base is all GPL'ed, so you can do anything the GPL
allows. This would include creating a commercial game with it (but any
enhancements you make to the engine you would have to release under
GPL). You would NOT have to release any of your assets (levels,
geometry, scripts, etc), which are what make a game a game.
Let me know if you think this is a problem, we are open to other
licensing arrangements. Edit | Attach | Print version | History: r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r1 - 07 Oct 2002, MrLin;
Main
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback